customer-service-excellence

name: customer-service-excellence description: Use when handling a customer service interaction (especially recovery, escalation, or public complaint), drafting service language (apology, empathy, ownership, escalation, confirmation), measuring service quality, aligning frontline empowerment with escalation paths, or designing a service-failure prevention loop. Encodes the recovery-and-retention loop, difficult-interaction frameworks, and CX-EX alignment rules. metadata: portable: true compatible_with: - Codex - codex

Customer Service Excellence

Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.

Use When

• Handling a live service issue (complaint, error, delay, escalation, public-channel post).
• Drafting service language: apology, empathy, ownership, timeline, confirmation, escalation, refusal.
• Designing or auditing the service recovery and retention loop.
• Measuring service quality across response, resolution, recovery, retention.
• Aligning frontline empowerment with escalation paths and knowledge management (CX-EX alignment).
• Building a prevention loop so the same failure does not recur.

Do Not Use When

• The work is pre-sale conversation; use premium-client-sales.
• The work is product feature evaluation; use product-discovery.
• The work is internal team conflict unrelated to a customer; use a coaching framework.
• The work is marketing copy at the top of the funnel; use the marketing/positioning skill.

Required Inputs

• The customer's words (verbatim where possible) and the channel they used.
• Account context: tenure, value, prior issues, contract terms.
• The actual failure: what happened, what was promised, what gap.
• Authority limits of the agent handling the interaction (refund cap, credit cap, escalation triggers).

Workflow

1. Run the recovery-and-retention loop: listen, acknowledge, diagnose, explain, options, act, confirm, document, prevent, follow up. Do not skip steps; the order matters.
2. Match the interaction type to a difficult-interaction framework (angry, anxious, technical-novice, executive, public-channel) and adapt language accordingly.
3. Use service language patterns for apology, empathy, ownership, timeline, confirmation, escalation. Each pattern has a structure and a prohibited phrase list.
4. Honour the frontline empowerment ceiling: if the resolution exceeds the agent's authority, escalate immediately rather than negotiating beyond authority.
5. Close with explicit confirmation: name what was done, what comes next, and the date the customer can hold you to.
6. Document the interaction with structured tags so it feeds the service quality measurement dashboard and the prevention loop.
7. Run a follow-up after resolution. Without follow-up, recovery is half-done.

Quality Standards

• The customer's words are mirrored before any explanation begins.
• Apology is specific and ownership-bearing, not "we apologize for any inconvenience".
• Every commitment has a date, an owner, and a confirmation channel.
• Escalation is a service tool, not a defeat. Escalate before negotiating beyond authority.
• Public-channel responses move to private channel for resolution but acknowledge publicly first.
• Every documented failure produces either a knowledge-base entry, a process change, or a known-acceptable-loss decision.

Anti-Patterns

• Apologising in passive voice ("mistakes were made"). Specific ownership outperforms generic regret.
• Explaining policy before acknowledging impact.
• Promising a callback "soon" instead of a specific time window.
• Treating the angry customer's tone as the issue. The tone is data; the issue is the failure.
• Closing the ticket because the customer went silent. Silence is not resolution.
• Making the customer repeat the story to a second agent. Hand-off discipline is part of service.
• Using empathy phrases as filler. Empathy without diagnosis is theatre.

Outputs

• A resolved or escalated case with named owner and date.
• A written confirmation to the customer (channel of their choice).
• A structured tag set for measurement (response time, resolution path, recovery used, retention outcome).
• A prevention entry: knowledge-base update, process change, or accepted-loss note.
• A follow-up scheduled at an explicit date.

Evidence Produced

References

• references/recovery-and-retention-loop.md for the ten-step loop and exit criteria per step.
• references/service-language-patterns.md for apology, empathy, ownership, timeline, confirmation, escalation, refusal patterns with prohibited phrases.
• references/difficult-interaction-frameworks.md for angry, anxious, technical-novice, executive, public-channel handling.
• references/service-quality-measurement.md for the four-metric dashboard (response, resolution, recovery success, retention impact).
• references/cx-ex-alignment.md for frontline empowerment, escalation paths, and knowledge management.
• Use continuous-improvement-system to feed prevention entries into operating cadence reviews.
• Use premium-client-sales for the inverse direction (pre-sale conversations).

Recovery and Retention Loop (the order, every time)

Listen -> Acknowledge -> Diagnose -> Explain -> Options -> Act -> Confirm -> Document -> Prevent -> Follow up.

Skipping listen produces explanation theatre. Skipping diagnose produces apology theatre. Skipping prevent produces the same failure next month. Skipping follow up produces silent churn.

Authority Ceiling Rule

Frontline agents must have a published refund cap, credit cap, and escalation trigger. Negotiating beyond authority destroys two relationships at once: the customer's trust (they sense the discomfort) and the agent's relationship with their manager (escalating after a promise burns capital both ways).

The Public-Channel Move

Public complaint -> public acknowledgement (under one hour, no defence, no detail) -> private channel handover -> resolution in private -> public closing note (only if the customer agrees). Resolving in public is theatre and invites pile-on.

Service Failure Prevention Loop

Every documented failure produces one of three outcomes:

• A knowledge-base entry (the agent could have answered with the right information).
• A process change (the system allowed the failure; fix it or it recurs).
• An accepted-loss note (the failure cost is below the prevention cost; document and move on).

Without the third option, prevention loops accumulate well-meaning policy that no one follows.