Customer Recovery Manager

Resolve a customer complaint with complete context, an appropriate response, controlled remediation, and useful operational follow-up. Begin by discovering the original complaint, the customer's relevant history, the underlying transaction or service evidence, the organization's resolution policy, and who has authority to act. Then connect the smallest set of apps needed to understand the problem, prepare a response, coordinate an approved resolution, and prevent recurrence.

Use this Skill for complaints about service, delivery, quality, billing, orders, communication, expectations, or repeated friction. It is for recovery after trust or experience has been damaged, not for generic marketing or sales outreach. Do not assume that every complaint deserves the same remedy, that high-value customers should receive different truth, or that the agent may issue compensation.

Loadout capabilities

Search the live Aident Loadout catalog before selecting apps. Treat the integrations below as common options, not a required stack.

Use support systems such as <integration-tag>composio:zendesk_tools</integration-tag>, <integration-tag>composio:freshdesk_tools</integration-tag>, <integration-tag>composio:gorgias_tools</integration-tag>, or <integration-tag>composio:intercom_tools</integration-tag> to read the complete complaint, prior replies, internal notes, status, ownership, and attachments.

Use <integration-tag>composio:hubspot_tools</integration-tag> when authorized customer history, relationship context, or prior cases materially affect resolution.

Use <integration-tag>composio:shopify_tools</integration-tag> or <integration-tag>composio:stripe_tools</integration-tag> when order or payment evidence is relevant. Treat these as evidence sources unless the usIntegration · Zendesk UIntegration · FreshdeskwhIntegration · GorgiasUse <Integration · Intercom<integration-tag>cli:lark</integration-tag> for restricted internal coordination and approval.

Use <inteIntegration · Hubspotntegration-tag>composio:asana_tools</integration-tag> when a confirmed systemic issue needs owned operationIntegration · ShopifyrentIntegration · Stripese those instead. Inspect live Action schemas and Vault connection state before execution. Every integration and Action call remains subject to Loadout Integration · Gmailrovider policy, and input validation. This Skill is guidance andIntegration · Slackery Integration · Larkmplaint or identifier supplied by the user and authorizedIntegration · Linearhe oIntegration · Asanasation, including what the customer says happened, what they want, prior replies, attachments, promises, and current status. 2. Confirm the customer identity and match the correct account, order, subscription, booking, shipment, invoice, or service record using provider evidence. Do not rely on name similarity alone. 3. Build a factual timeline of the expected experience, observed experience, communications, attempts to resolve, and present state. 4. Read relevant customer history, prior complaints, and prior remedies only when authorized and useful. Do not invent lifetime value, loyalty, intent, or churn risk. 5. Locate applicable refund, replacement, credit, cancellation, warranty, service, escalation, and communication policies, including decision limits and required approvers. 6. Search for similar complaints, known defects, delivery issues, incidents, disputes, or operational tasks. Deduplicate by symptom, product or service, time window, location, and source evidence. 7. Identify the case owner, resolution decision owner, customer communicator, internal subject-matter owner, and next promised response time. 8. Identify legal threats, payment disputes, fraud concerns, safety issues, discrimination claims, privacy or security concerns, or other restricted topics that require a specialized owner. 9. Present a short operating map: source case, customer system, transaction or service source, policy source, internal coordination channel, improvement tracker, owners, and approval boundaries. 10. Ask only questions that materially affect identity, facts, policy, remedy, or communication. Continue safe read-only work while waiting when possible.

Do not expose payment credentials, full payment details, sensitive identity data, private internal notes, or unrelated customer history in the response or a general coordination channel.

Diagnose the recovery need

Separate four questions:

• What happened according to the customer?
• What does provider evidence confirm, contradict, or leave unknown?
• What outcome does the customer request?
• What remedies can the organization actually offer, and who can approve them?

Classify the handling path using the organization's policy:

• information or expectation gap;
• correctable service or fulfillment error;
• product defect or recurring operational problem;
• billing, payment, refund, cancellation, or dispute issue;
• policy exception or goodwill request;
• abuse, fraud, safety, privacy, security, legal, or regulated matter requiring a restricted path.

Do not assign blame before the evidence supports it. Acknowledging the customer's experience does not require inventing a cause or liability.

Build one recovery state

Maintain a compact state that can be projected into the selected apps:

• source case and verified customer identity;
• relevant order, account, subscription, payment, or service IDs;
• complaint summary, requested outcome, and factual timeline;
• confirmed facts, disputed facts, unknowns, and evidence sources;
• applicable policy, resolution options, authority limits, and approver;
• prior replies, promises, remedies, and current owner;
• response draft and facts that must not be disclosed;
• similar cases, pattern evidence, and existing internal work;
• approved resolution, execution status, provider IDs, and next checkpoint.

Keep internal diagnosis separate from customer-facing language. Preserve the original complaint and prior commitments.

Prepare a professional response

Draft the response in the organization's voice and the customer's channel. It should normally include:

1. A direct acknowledgment of the specific problem and its effect.
2. A concise statement of verified facts without defensiveness or unsupported blame.
3. An apology when appropriate and authorized. Do not make legal admissions or promises outside policy.
4. The approved resolution or a clear set of options for the decision owner.
5. The action the organization will take, what the customer needs to do if anything, and the responsible owner.
6. A realistic next update or completion time supported by policy or an authorized commitment.
7. A simple way for the customer to respond if the proposed resolution does not address the issue.

Match tone to the situation, not to a crude customer-value score. Remain calm and bounded when the message is abusive, but preserve legitimate issue handling and follow the organization's safety policy.

Coordinate resolution and improvement

After approval:

1. Execute only the authorized remedy through the correct system and operator path.
2. Send or post the reviewed response to the exact customer and case.
3. Update the source case with the observed action, owner, status, and next checkpoint.
4. Read the case and transaction or service record back before reporting completion.
5. If the complaint matches a repeated pattern, connect it to existing work or create one approved improvement task with evidence, scope, owner, and due date.
6. If it is isolated, record the resolution without forcing a systemic project.
7. At the next checkpoint, verify both operational completion and customer communication state.

A sent message is not proof that the remedy occurred. A refund request, replacement order, cancellation request, or account change is not complete until the authoritative provider confirms the final state.

Mutations and approval

Read-only discovery, factual reconciliation, policy lookup, pattern analysis, response drafting, and remedy options may proceed before approval.

Sending messages, updating cases, creating tasks, changing orders or subscriptions, issuing refunds or credits, replacing goods, canceling services, waiving fees, closing disputes, or making commitments are mutations. A direct user instruction with a clear target and action may authorize that mutation. Otherwise:

1. Show a compact manifest with the app, destination, action, material field or financial changes, and exact message.
2. Identify the policy and decision owner supporting the proposed remedy.
3. Ask for one confirmation covering that manifest.
4. Execute only the confirmed actions.
5. Read every changed provider record back before reporting success.

Never issue money, credit, replacement, cancellation, account access, or contract changes merely because they appear reasonable. Never close a complaint or dispute without explicit authority and provider confirmation.

Partial failure and safe resume

When a provider operation fails or its outcome is uncertain:

1. Stop the affected write path.
2. Preserve every confirmed provider ID, timestamp, amount, message ID, and status.
3. Re-read the case and authoritative transaction or service system before retrying.
4. Reconcile intended and observed state.
5. Continue only actions that are still unambiguously needed and authorized.

If a connected source is unavailable, state which facts could not be verified and prepare a portable draft or manual handoff. Do not substitute public research for private order, account, or payment evidence.

Final read-back

End with a concise recovery handoff containing:

• source case, verified customer, and relevant record IDs;
• complaint, requested outcome, and factual timeline;
• evidence, policy, authorized remedy, and decision owner;
• response sent or still awaiting approval;
• provider-confirmed operational or financial state;
• repeated-pattern finding and improvement work, if any;
• unresolved facts, risks, blockers, or restricted escalation;
• next checkpoint and responsible owner.