Is it safe to put customer tickets into Claude?

Working from ticket text in a workspace your company has approved is fine — drop the export into the Desktop file pane and approve the read in the 'Ask permissions' prompt. The line is the customer's identity — full names, emails, card and account numbers stay out of a general chat. The habit that makes it safe is scrubbing to `[placeholders]` and only dropping in what the task actually needs. Claude drafts the reply; it never becomes the system of record for customer data.

Does this replace my support agents?

No. It removes the slow, repetitive part — clustering a backed-up queue, drafting the first version of a reply, surfacing the one bug behind fifty complaints — so your agents spend their time on the hard cases, the angry customer, and the human touch that keeps people loyal. An agent fact-checks and personalizes; a person presses send and owns the relationship. Claude is the fastest junior on the desk, not a replacement for the people who run it.

How do we keep replies on-voice and on-policy?

Two source-of-truth files. A `support-voice.md` governs how you sound — warm, plain, no jargon; a `support-policy.md` governs what you can promise — refund limits, exception rules, escalation thresholds. Every drafting task starts by feeding those in, so 'our voice' and 'our policy' point at real documents instead of each agent's guess. Build them once (they're the Stage 1 playbooks) and every later reply gets sharper.

How do we roll this out without it fizzling?

Start small and staged. Two or three willing agents, the two foundation docs, and a one-page rule about data, promises, and who sends in the first month; the repeatable systems — triage, escalation, CSAT, the voice-of-customer loop — in the second; the weekly operating system and a rehearsed incident plan in the third. Capture the prompts that work into a shared file so wins compound instead of evaporating. The 30/60/90 plan at the end of this guide is the whole arc.

Customer Support with Claude: the operating guide

Your team has the Support playbooks — the worked systems for triaging a queue, drafting human replies, escalating the bug behind fifty tickets, building a help center from the questions you actually get. Those tell people what to do. This guide is the layer underneath: the operating model that keeps the work safe, on-voice, and on-policy while they do it. It’s written for a support leader rolling Claude out across a team, not for a solo agent experimenting between tickets.

The single mistake that turns a support-AI rollout into an incident isn’t a clumsy prompt — it’s the absence of a rule about customer data, about what your team is allowed to promise, and about who actually sends. None of what follows is heavy process. It’s the handful of guardrails that let your team move fast because the boundaries are clear.

The operating model: Claude drafts, a human sends

Start with the one principle everything else hangs off: Claude drafts; a human sends. A person owns every word that reaches a customer. Claude is the fastest junior agent you’ve ever had — tireless at clustering a queue, drafting a first reply, summarizing a long thread for a hand-off, spotting the bug behind fifty complaints — and it has no judgment, no accountability, and a habit of stating wrong details with total confidence.

So the division of labour is fixed:

Claude does the zero-to-draft work: group the weekend’s tickets by root issue, draft the warm first reply, write the help-center article, summarize the back-and-forth so the next agent picks it up cold, surface the one issue that’s a bug to escalate rather than a reply to repeat.
A person does the deciding: fact-check the details, fill in the private specifics only your systems hold, make it sound human, confirm the offer is one you can make — and press send.

A team that internalizes this gets the speed without the risk. A team that forgets it sends a customer a confident, invented order number — which is worse than a slow reply, because it breaks trust at the exact moment you were trying to rebuild it. The playbooks are all built around this line: they take you to a strong draft fast and then hand the judgment, and the send, back to a person on purpose.

On Desktop, the folder is the boundary — Claude only sees what you open — and the “Ask permissions” prompt asks before each read. That makes the data rule simple to state and easy to follow:

Safe to share: ticket text scrubbed to [customer], your voice and policy and help-center docs, public product information, and aggregate metrics (CSAT distributions, ticket volumes, response-time trends, top-issue counts).
Keep in an approved workspace: full names, email addresses, phone numbers, card and account numbers, order-level records — anything that identifies a specific customer or could be used to reach or charge them.

Two habits make this automatic. First, scrub to [placeholders] and only drop in what the task needs — a ticket export for a triage pass can have names and emails stripped to [customer] before it ever reaches the chat, because clustering by issue doesn’t need to know who complained. Second, when an export genuinely carries personal data, keep the whole task inside the workspace your company has approved for it, rather than a general chat. The ticket-triage and CSAT analysis playbooks both flag this at the exact step it matters — because those are the two places a raw customer export is most tempting to paste whole.

The refund-and-policy gate

The fastest way to turn a helpful reply into a liability is to let Claude promise something on your behalf. So put one explicit gate between draft and send, and make it specific to support:

Claude never invents an order number, a refund amount, a ship date, a credit, or a policy. It will state any of these confidently whether or not it’s true; tell it not to, leave [placeholders], and have the agent fill them from your real systems.
Anything Claude drafts that promises something — a refund, a credit, an exception to policy, a delivery ETA, a goodwill gesture — clears whoever owns that authority before it’s sent. A warm apology needs no sign-off; a $400 refund or a policy exception does.
The thresholds are written down, not remembered. What an agent can approve alone, what needs a lead, what needs a manager, and what a customer is never told — all of it lives in support-policy.md, built once in the tone-and-policy playbook and fed into every drafting task.

This isn’t bureaucracy bolted on — it’s a single named step in the workflow. The reply-drafting and macro-library playbooks keep promises behind placeholders by design, and the escalation and incident-comms playbooks put the approver on the runbook, because at any scale what creates a support incident is a promise that went out the door without the authority behind it.

Who owns what (a light RACI)

Speed dies in ambiguity about who can promise what. You don’t need a formal RACI matrix — you need four roles named for any reply that carries a commitment:

Drafts — the agent running the playbook with Claude.
Reviews — a senior agent or QA, who owns voice and factual accuracy: does this sound like us, and is every detail real?
Approves — whoever can authorize the promise: a lead for a routine refund, a manager for an exception, comms or leadership for an external incident statement.
Sends — a person presses send, owns the outcome, and can answer for it.

The point is that Claude is never any of these four. It’s the tool the Drafts role uses. For everyday replies the same person may draft, review, and send — the roles collapse — but the moment a reply makes a promise or a statement goes to more than one customer, the four pull apart and you want them named. Write them down once for refunds, for exceptions, and for incident comms, and most “who said we’d do that?” fire drills disappear.

Working in two languages: Arabic and English

For a MENA team, bilingual support isn’t a translation step bolted on at the end — it’s a parallel track. The rule that matters: adapt, don’t translate.

An Arabic-speaking customer gets a reply written in Arabic. Not a machine-translated English one — a reply in Arabic-native register, with the warmth, formality, and rhythm a native speaker expects. A translated apology reads as a translated apology, and customers feel the distance.
The voice doc gets an Arabic twin. Build a support-voice-ar.md from Arabic replies you’re proud of, the same way the tone-and-policy playbook builds the English one — don’t translate the English voice rules and hope they carry.
Same gate, both languages. An Arabic reply clears the same refund-and-policy gate as the English one. If the approver doesn’t read Arabic, that’s not a reason to skip the review — it’s a reason to find someone who does. A promise is a promise in any language.

Treated this way, Arabic is a first-class peer of English on your desk, not an afterthought — which, in this region, is the difference between a customer who feels looked after and one who feels processed.

The capability path: from first reply to incident comms

The playbooks are arranged as a staged path, not a flat menu, because the later ones genuinely depend on the earlier ones. Run a team through it in order:

Stage 1 — Foundations. Build the reusable assets every reply inherits: your support voice & policy, the craft of drafting human replies, and the macro library of templates an agent can grab and personalize in seconds. Skip these and every later reply starts from a guess about how you sound and what you can promise.
Stage 2 — Repeatable systems. Turn the foundations into the weekly engines that run the desk: triage, bug escalation, the help center, QA & coaching, CSAT analysis, new-hire ramp, and the monthly voice-of-customer report that turns the queue into something leadership can act on.
Stage 3 — Orchestration. Pull it all together: the weekly support operating system that runs the whole loop, and incident comms for the day something breaks and a hundred customers need to hear from you at once.

On the Support team hub the path is laid out stage by stage with a progress bar, and your team can mark each playbook done as they go — so “we’re upskilling the desk” becomes a number you can actually see, not a hope. (Progress is tracked on each person’s device; a shared, manager-level team view is the natural next step once you’ve run the path.)

Rolling it out: a 30/60/90 plan

Don’t roll everything out to everyone on day one — that’s how rollouts fizzle. Stage it the same way the path is staged. Here’s the whole arc as a checklist you can copy into your own doc:

30/60/90 — rolling Claude out across a support team

First 30 days — Foundations
- Pick 2–3 willing agents who answer real tickets every day.
- Build the two source-of-truth docs: support-voice.md and support-policy.md.
- Agree the one-page rule: what data is safe to share, what Claude may never
  promise, and who presses send.
- Each agent runs their first real Stage 1 playbook end to end on a live queue.

Days 30–60 — Repeatable systems
- Put the weekly engines on Claude: triage, bug escalation, the help center,
  QA & coaching, CSAT analysis, and the voice-of-customer loop.
- Capture the prompts that work into a shared CLAUDE.md so wins compound.
- Name the four roles for any reply that carries a promise:
  drafts / reviews / approves / sends.

Days 60–90 — Orchestration
- Run the weekly support operating system that ties the loop together.
- Rehearse incident comms once before you need it — draft, approve, and "send"
  a mock outage statement so the path is muscle memory, not improvised at 2am.
- Review the capability path: who's completed which stage, where the gaps are,
  and which seats to add next.

The urge to mandate it for the whole desk at once is the urge to resist. Adoption is a habit that spreads, not a switch you flip. Start a few agents on the foundations, give them the two source docs and a one-page rule, let them capture what works — and by day 90 you have a desk that’s run a real queue through the system, rehearsed the incident it hopes never comes, and the proof you need to widen it. The general team rollout playbook goes deeper on the cross-role mechanics when you’re ready to scale it past support.