Customer Escalation Manager

# Customer Escalation Manager

Turn a customer problem into a complete, evidence-backed escalation in the user's real support environment. Begin by discovering how the organization receives customer issues, stores account context, assigns internal work, communicates with customers, and decides when an issue must leave normal support. Then assemble the smallest connected-app workflow that gets the right context to the right owner without creating duplicate records or unsupported urgency.

Use this Skill when a customer issue is unresolved, repeated, technically complex, commercially sensitive, beyond the current team's authority, or likely to require engineering, product, security, operations, or leadership attention. Do not assume a particular support tier, severity model, service-level agreement, account hierarchy, or escalation route.

## 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>, or <integration-tag>composio:intercom_tools</integration-tag> to read the original conversation, status, ownership, attachments, promises, and prior troubleshooting.

Use <integration-tag>composio:hubspot_tools</integration-tag> when account, relationship, or customer-history context is relevant and authorized.

Use <integration-tag>composio:slack_tools</integration-tag> or <integration-tag>cli:lark</integration-tag> for internal coordination and reviewed updates.

Use <integration-tag>composio:linear_tools</integration-tag> or <integration-tag>composio:jira_tools</integration-tag> when the receiving team manages bugs, investigations, decisions, or follow-up work in an issue tracker.

Use <integration-tag>composio:notion_tools</integration-tag> or <integration-tag>composio:googledocs_tools</integration-tag> when the organization needs a durable escalation brief, troubleshooting record, or decision log.

If the user's systems are different, search for their native Integrations and Actions and use those instead. Inspect live Action schemas and Vault connection state before execution. Every integration and Action call remains subject to Loadout authentication, authorization, confirmation, billing, provider policy, and input validation. This Skill is guidance and never grants tool access.

## Preflight context discovery

Start with read-only discovery. Use context already supplied by the user and connected sources that can be read safely before asking questions.

1. Identify the customer problem, the outcome requested now, and why ordinary support may no longer be sufficient.
2. Locate the original conversation or case and read the complete relevant thread, including internal notes, attachments, ownership changes, promised dates, and prior attempts.
3. Determine who is affected, what workflow is blocked or degraded, when it began, how often it occurs, and whether the impact is growing.
4. Read authorized customer and account context that materially affects handling. Do not infer importance from brand recognition or invent revenue, tier, churn, contract, or renewal facts.
5. Search for related tickets, known issues, workarounds, bugs, feature requests, incidents, security reports, and prior escalations. Deduplicate by symptom, affected function, environment, time window, and evidence.
6. Discover the organization's escalation policy, severity definitions, support boundaries, service commitments, receiving teams, required evidence, communication rules, and approval requirements.
7. Identify the current support owner, intended escalation owner, decision maker, customer communicator, and next promised update.
8. Check whether the issue contains security, privacy, legal, safety, regulated, or highly sensitive information that requires a restricted path or specialized owner.
9. Present a short operating map: source case, customer system, evidence sources, destination team and tracker, coordination channel, durable document if needed, owners, and approval boundaries.
10. Ask only the focused questions whose answers would materially change the escalation. Continue safe read-only work while waiting when possible.

Do not create an engineering issue, escalation channel, executive alert, or second support ticket until the existing records and routing policy have been checked.

## Decide whether and where to escalate

Use the organization's policy first. If no clear policy exists, reason from the work required rather than from a universal severity table.

- Keep the issue in support when an authorized support owner can resolve it with documented guidance, configuration, education, or an established workaround.
- Route technical defects and unexplained system behavior to the team that owns diagnosis or remediation.
- Route product tradeoffs, missing behavior, or prioritization questions to the product decision owner without presenting them as confirmed bugs.
- Route security, privacy, safety, legal, or regulatory concerns through the organization's restricted path. Do not investigate beyond the available authorization.
- Route policy exceptions, compensation, contractual commitments, or commercial concessions to the person with authority to approve them.
- Escalate to leadership only when the organization's rules or the required decision genuinely call for it. Leadership visibility is not a substitute for a clear owner and request.

If the issue does not yet meet an escalation threshold, explain what support can do next and what new evidence or deadline would trigger escalation.

## Build one escalation state

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

- source case ID, customer identity, and authorized account context;
- concise problem statement and requested outcome;
- affected users, workflows, environment, timing, frequency, and current impact;
- verified facts, open questions, and unsupported claims to avoid;
- troubleshooting performed, results, workarounds, and remaining diagnostic gaps;
- related records, known issues, duplicates, and evidence links;
- support owner, escalation target, decision owner, and customer communicator;
- specific request to the receiving team and the reason it needs that team;
- customer commitments, last update, next update, and applicable service deadline;
- current status, provider record IDs, and actions awaiting approval.

Preserve source timestamps and identifiers. Separate customer statements, observed provider evidence, and internal interpretation.

## Prepare the escalation package

The package should be concise enough to act on and complete enough to avoid repeating discovery.

Include:

1. A one-line summary that states the observed problem and affected scope.
2. The customer or user impact using verified facts and the organization's terminology.
3. A short timeline from first report through the latest confirmed state.
4. Reproduction steps when relevant, including environment, expected behavior, actual behavior, frequency, and evidence.
5. Troubleshooting already performed, results, and any safe workaround.
6. Links or IDs for the source case, related cases, existing internal work, logs, screenshots, and documentation.
7. The exact decision or action needed from the receiving owner.
8. The applicable deadline or next promised update, with its source.
9. Customer communication status and a reviewed interim-response draft when useful.
10. Unknowns and evidence still needed.

Do not turn assumptions into severity, root cause, customer promises, or delivery dates. If the receiving system uses required fields, map the verified state into its schema rather than manufacturing values.

## Coordinate handoff and follow-through

After the package is reviewed:

1. Create or update the selected destination record.
2. Link the source support case and any existing related work in both directions when the systems allow it.
3. Notify only the required internal owners through the chosen coordination channel.
4. Update the support owner with the destination ID, current owner, request, and next checkpoint.
5. Prepare a customer-facing update that acknowledges the issue, states supported facts, explains the next step, and gives only an authorized expectation.
6. Read every changed record back and preserve its provider ID and observed status.
7. At the next checkpoint, read the source and destination systems before sending another update or changing status.

Keep one canonical internal work item. Do not create new records at every follow-up.

## Mutations and approval

Read-only discovery, evidence gathering, deduplication, package preparation, and message drafting may proceed before approval.

Creating or changing tickets, issues, documents, channels, assignments, priorities, severities, deadlines, customer promises, or messages 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 changes, and exact message when one will be sent.
2. Ask for one confirmation covering that manifest.
3. Execute only the confirmed actions.
4. Read every changed provider record back before reporting success.

Require exact text and audience confirmation for customer-facing, executive, public, legal, security, privacy, safety, or regulatory communication. Never offer refunds, credits, contract changes, delivery commitments, or priority guarantees without an authorized decision.

## Resolution, fallback, and safe resume

Do not close the source case merely because an internal issue was created. Confirm the customer's requested outcome, the support policy, and evidence that the affected workflow is restored or an accepted resolution has been delivered.

When a provider operation fails or its outcome is uncertain:

1. Stop the affected write path.
2. Preserve every confirmed provider ID and timestamp.
3. Re-read the source and destination systems before retrying.
4. Reconcile intended and observed state.
5. Continue only actions that are still unambiguously needed and authorized.

If a required integration is unavailable, identify the smallest blocker and produce a portable escalation package for manual use. Do not claim that a handoff, notification, or customer update occurred without provider evidence.

## Final read-back

End with a concise handoff containing:

- source case and customer context used;
- verified impact, timing, and current status;
- escalation decision, destination, owner, and exact request;
- related records and evidence IDs;
- troubleshooting and workaround state;
- mutations completed with provider confirmation;
- customer communication status and next promised update;
- unresolved questions, blockers, or approvals;
- next checkpoint and responsible owner.