Reseek
Reseek / Small business / Customer Service playbook
Role playbook · 05 of 07

The customer service playbook for Claude. Cut first response in half, sound like humans, close the learning loop.

Customer service is the role with the clearest ROI from AI and the highest stakes. A bad reply to a real customer is a real problem. Move fast on draft-assist; move slow on autonomous. This page is the careful version — twelve prompts that don't sound like a chatbot, a project that holds your tone and your hardest tickets, a help-desk integration that drafts before you read, and the patient path to a tier-1 agent that won't burn trust.

01 — The ritual

The Service Hour. Every Friday, close the loop the tickets are trying to teach you.

Block 60 minutes every Friday. Twenty minutes reviewing this week's tickets for patterns. Twenty minutes turning the patterns into FAQ updates, case-library entries, or escalations to product/ops. Twenty minutes auditing voice across the team's replies. The point isn't to handle tickets — it's to make sure the volume is teaching you something.

Most service teams drown in volume and never look up. The Service Hour is the look-up. Every recurring complaint is product feedback. Every recurring question is FAQ debt. Every recurring praise is source material for marketing and sales. If you don't make a weekly habit of mining the queue for these, you'll work twice as hard for half the leverage.

Six rotating focus questions for the first 20 minutes of the hour. Pick the one most relevant this week — or rotate through them.

QUESTION 01

The top 3 recurring issues

"What were our top 3 recurring issues this week? Cross-reference 'Issues we keep apologizing for' in the project — is this still a service problem, or should it be escalated to product or ops?"

QUESTION 02

FAQ debt

"What's the FAQ article we should have written last week and didn't? Draft it. Tell me which ticket would have been closed faster if it had existed."

QUESTION 03

Voice drift

"Audit 5 replies our team sent this week. Where did we drift from our voice (in the project)? Quote the lines and give me the version we should have sent."

QUESTION 04

The hard ticket

"The hardest ticket we resolved this week — turn the resolution into a case-library entry. What's the lesson for the next time we see this pattern?"

QUESTION 05

The angry customer

"The customer who escalated this week — what was the actual underlying issue, not just the surface complaint? Should anyone follow up next week, and with what?"

QUESTION 06

The praise

"Any customer praise this week that's source material for marketing or sales — a specific quote, a specific outcome? Pull it out, attribute it, send the right person a draft of how they could use it."

Why this works. Volume gives you signal you'll never get anywhere else. Customers tell support what's actually broken, what's actually missing, what's actually working — in their own words, without a sales conversation in the way. The Service Hour is how that signal stops dying in a ticket queue and starts changing the product, the marketing, and the operations of the business.

02 — The substrate

Build your "Customer Service Playbook" Project. Tone, tier, and the issues you'd rather not write down.

Service is the role where a generic AI voice does the most damage. The project fixes this — but only if you fill in the parts most companies skip: the actual tone with real examples, the "we cannot do this" lines, the hard-ticket case library, and the honest list of issues you've been apologizing for.

What goes in it

How to build it

Download the template. Fill it in honestly — 60 to 90 minutes the first time. Upload your FAQ, product docs, and the 10 hardest tickets from the last quarter as knowledge files. The case library is the section that grows over time — every hard ticket you resolve adds to it.

Open Claude → Projects → New Project → "Customer Service Playbook." Paste the file, upload the docs. Now every reply draft comes back in your tone, every pattern analysis references real cases, every voice audit measures against real examples.

⬇ Download the template (markdown) Preview it in the browser

"Issues we keep apologizing for" is the most important section. Every service team has a list of 4–8 recurring complaints that aren't really service issues — they're product bugs, pricing miscommunications, ops gaps. Most teams absorb them indefinitely because writing them down feels disloyal. It isn't. Writing them down lets Claude flag the pattern when you ask for the 47th apology draft and quietly suggest: maybe stop apologizing, fix the thing.

03 — The library

Twelve prompts every service rep should save.

Used inside your Service Playbook project, so Claude already has the FAQ, the tone, the case library, and the cannot-do list in context. Fill in the [bracketed] specifics and copy-paste.

↓ Reply drafting ↓ Pattern analysis ↓ Quality ↓ Learning loop
Reply drafting (3 prompts)
01Reply draft from a ticket
Every ticket
Customer ticket: [PASTE FULL THREAD]

Draft a reply. Follow our voice and the first-sentence rule (project).

1. Open by naming what they said, in their own words. Not "I understand your frustration." Not "thanks for reaching out."
2. Answer the actual question they're asking, in plain English, citing the relevant FAQ or product doc.
3. If there's a related thing they might ask next, address it preemptively — but in one sentence, not a paragraph.
4. Close with what they should do next, specifically, if anything.
5. Length: as short as it can be while still being helpful. Long replies feel like deflection.

If the right answer is "we cannot do that," draft the polite-decline using our cannot-do language. If the answer requires Tier 2 or higher escalation, draft the handoff note instead of the reply, and tell me who it goes to.
02The angry customer reply
When the temperature is high
Angry ticket: [PASTE FULL THREAD]

Draft three reply options, in order of de-escalation strength:

1. **The acknowledgment-first** — leads with naming what they're actually mad about (not the surface issue), takes responsibility on the part that's ours, then resolves.
2. **The action-first** — leads with what we're doing about it, then acknowledges.
3. **The escalate-first** — if the temperature is genuinely too high for me to handle, draft the escalation note instead of a reply.

For each: match their emotional pitch in the first line, then bring it down. Don't open at calm if they wrote in furious.

End with: which of the three would you actually send, and why. And tell me if there's anything in their message that points to "Issues we keep apologizing for" (project) — because the right move might be to fix the underlying issue, not draft a better apology.
03The "no, we can't do that" reply
For every cannot-do
Customer is asking for: [WHAT THEY WANT]. We cannot do this because: [REASON]. The relevant cannot-do line in our project: [CITE].

Draft the reply that:

1. Acknowledges what they want, specifically and warmly
2. Says no clearly — once, in plain English, without hedging
3. Explains why in their interest, not ours — what would actually happen if we did it
4. Offers what we CAN do instead, if anything (don't fake an alternative if there isn't one)
5. Does not quote policy. Does not say "unfortunately." Does not say "as per our terms."

Length: under 100 words. Tone: human refusing a friend's reasonable request — not a corporation defending itself.

If you think we should actually say yes — the policy is wrong for this specific customer, or this is an "Issues we keep apologizing for" pattern — tell me before drafting the no.
Pattern analysis (3 prompts)
04Weekly ticket pattern analysis
Service Hour
Attached: this week's tickets (or a representative sample of 30–50).

Find the patterns:

1. The 3 most recurring issues — by volume. For each: how many tickets, the canonical phrasing customers used, and where in the product/process the issue actually lives.
2. The 1 issue that didn't appear in volume but should worry me — a single ticket that's a leading indicator of something bigger.
3. Which patterns match "Issues we keep apologizing for" in the project? Should any of them be escalated to product/ops this week?
4. Which patterns are new — never seen before? Worth a closer look.
5. What's the one FAQ article we should write this week to deflect future volume?

Output: ranked list, with specifics. Don't summarize the queue — surface the signal.
05Sentiment summary
Monthly
Attached: last month's tickets, support emails, reviews, and any inbound comments from social.

Summarize the sentiment shift:

1. Overall — better, worse, or flat vs. previous month? Cite specific volume + tone signals.
2. By feature/area — which parts of the product or service are customers happier about, and which are degrading?
3. Customer segments — is sentiment splitting (some customers are happy, some are turning)? Who's turning, and why?
4. The 3 specific quotes that best capture the month's mood — one positive, one negative, one revealing.
5. The single thing the team should celebrate, and the single thing the team should be worried about.

Don't be diplomatic. Pattern data this rich is worth the discomfort of an honest read.
06FAQ gap identification
Quarterly
Attached: a quarter of tickets and the current FAQ.

Audit the gap:

1. Top 10 questions customers asked this quarter that are NOT well-covered by the FAQ. For each, the canonical question wording.
2. Top 5 FAQ articles that customers seem to be missing — questions that match articles we already have. Discoverability problem, not content problem.
3. Top 3 FAQ articles that are stale or wrong — the product changed and the article didn't.
4. The one article that, if written, would deflect the most volume next quarter. Draft it.

End with: a priority list for FAQ updates next quarter, ranked by deflection impact, with effort estimates.
Quality & voice (3 prompts)
07Voice audit on a reply
Random sample weekly
Reply sent by our team: [PASTE]
Original ticket: [PASTE]

Audit against our voice (project). Be specific:

1. Did the opening follow the first-sentence rule? Quote it. Score 1–10.
2. Any phrases we never use that snuck in? ("I understand your frustration," "unfortunately," "per our policy," "great question.") Quote each.
3. Did the reply answer the actual question, or a nearby one?
4. Was it the right length? If too long, where would you cut.
5. Tone match — did the rep meet the customer's emotional pitch, or open at the wrong temperature?

End with the version of the reply we should have sent — same content, in our voice. No more than 30% different from the original; this is an audit, not a rewrite.
08Tone-check before sending
Before any hard reply
Draft reply I'm about to send: [PASTE]
Original ticket: [PASTE]

Be the honest mirror. Specifically check:

1. Does this match the customer's emotional pitch in the opening? If they wrote in furious and the reply opens "Thanks for reaching out!" you've failed.
2. Any defensive moves? ("Just to clarify," "as I mentioned," "to be fair.") Quote them.
3. Any AI-tells? Mechanical empathy, bulleted lists where prose would feel warmer, hedge phrases ("might be able to," "could potentially").
4. Anything that could read as condescending to a smart adult under stress?
5. The one edit that would most improve this reply.

Don't rewrite. Flag and quote. End with a 1–10 score for "sounds like a real human who cares" — and the single edit.
09Translation
When a customer writes in another language
Customer wrote in [LANGUAGE]: [PASTE]

1. Translate to English, preserving emotional pitch — if they wrote in frustrated, translate as frustrated, not neutral.
2. Tell me what they're actually asking, in plain terms — sometimes the literal translation hides the real question.
3. Flag any cultural context I should know — phrases that carry weight I might miss.

Then draft my reply in English (in our voice), and translate the reply back to [LANGUAGE]. For the translated version, prioritize warmth and clarity over literal fidelity — and flag any line that loses important nuance in translation.

If the language is one where I should explicitly mention "translated by AI" for transparency, tell me.
Learning loop (3 prompts)
10"This complaint, every week" — escalate?
When a pattern is undeniable
Complaint we've been seeing every week: [DESCRIPTION]. Approximate volume per week: [N]. How long it's been recurring: [DURATION].

Help me decide what to do with it:

1. Is this still a service issue (we keep replying) or is it really a product/ops/marketing issue (somebody else should fix it)?
2. If it should escalate — to whom, with what evidence? Draft the brief: 3 specific tickets, the volume estimate, the cost to support per week, what good would look like.
3. If it should stay with service — why? And what's the FAQ article / canned response / training that would make it less painful?
4. What's the cost of doing nothing for another quarter? Be specific — hours, customer churn risk, NPS impact.

End with the recommendation, named. "Escalate to product, by Friday, with this brief" — or — "Stays with service; here's the canned response to write."
11Case library entry from a hard ticket
After every hard ticket
Hard ticket we resolved this week: [PASTE THREAD + WHAT WE ENDED UP DOING]

Generate a case-library entry for the project:

1. **Title** — anonymized, descriptive, searchable. ("Customer demanded refund outside policy after migration data loss" — not "Acme Inc issue.")
2. **Situation** — what happened, in 3–4 lines.
3. **What they wanted** — their stated ask, and their actual underlying need if different.
4. **What we did** — the actual resolution, including what we offered, what we did not, who was involved, how long it took.
5. **Lesson** — what we'd do differently next time, OR what we'd do again. Be specific.

End with: should we proactively reach out to any other customer who might hit this same scenario? If yes, draft the proactive note.
12De-escalation playbook for a specific situation
Before a tough conversation
Situation: [DESCRIBE — customer at risk, anger level, history, what they're threatening, what we did or didn't do]

Walk me through the de-escalation:

1. What's the actual emotional driver here? (Disrespect, lost time, lost money, broken promise, fear of looking foolish, all of the above?) Diagnose.
2. The first thing I should acknowledge — specifically, in their words.
3. What NOT to say first — phrases that will make this worse.
4. The smallest concession that meets the emotional need without setting a bad precedent.
5. The largest concession I'm authorized to make per our policy in the project. The line beyond that.
6. The "if they keep escalating" path — when does this go to Tier 2, when does it go to Tier 3 / leadership?

End with the opening line of what I should say or write. Just the opener. The rest is a conversation.

Prompt 08 is the one to use most. Every reply draft you don't run through the tone-check is a reply you're hoping is in your voice. Make Prompt 08 a non-negotiable step before sending any hard reply. It's the difference between "AI helped me draft this" (invisible to the customer) and "this was clearly drafted by a chatbot" (a brand incident waiting to happen).

04 — The first integration

The help-desk draft-assist workflow. Every reply pre-drafted before you open the ticket.

The integration with the clearest payback for service: when a ticket lands in Zendesk / HubSpot Service / Intercom / Freshdesk, Claude reads it, checks the FAQ and the case library, and pre-drafts the reply — attached to the ticket as an internal note. You open the ticket and the draft is already there. Setup: ~45 minutes. The first week, first-response time drops by 40–60%.

~10 MINUTES

Connect your help desk to Claude

In your Service Playbook project → Connect apps → pick your help desk. Read access on tickets + customer profiles; write access on internal notes (so Claude attaches the draft where only the team sees it, not the customer). HubSpot Service, Zendesk, and Intercom all have direct integrations; Freshdesk and others work via Zapier or a webhook.

Critically: no write access on outbound replies. Claude proposes drafts; humans send. That's the rule.

~15 MINUTES

Save the master draft-assist prompt

Save this as "Ticket draft-assist" inside the project. The trigger pattern: every new ticket fires this prompt, which posts the draft as an internal note. Most help-desk integrations support this via a simple automation.

Ticket draft-assist
New ticket: [TICKET ID / CONTENT — pulled from the help desk integration]

Customer: [PROFILE — pull from help desk]

Produce the assist in this exact structure, posted as an internal note on the ticket:

**1. Read of the ticket**
- What they're actually asking (one line — not a restatement of the email)
- Emotional pitch (calm / frustrated / angry / fearful / confused)
- Tier (1 / 2 / 3 — using the breakdown in the project)

**2. Relevant context from the project**
- FAQ article(s) that apply (cite by title)
- Case library entries that match (cite by title)
- Cannot-do lines that apply (cite if relevant)
- Issues-we-keep-apologizing-for match? (Flag if yes — this might point to a bigger issue)

**3. Draft reply**
Follows the first-sentence rule. In our voice. As short as it can be while being helpful. If this is a "no, we can't" — the polite-decline version. If this needs escalation — the handoff note instead, with who it should go to.

**4. Confidence**
- 1–10 on how confident you are this draft is right. Below a 7, flag specifically what you're uncertain about — the policy edge case, the missing context, the emotional read.
- If confidence is below 5, recommend the human reads the ticket from scratch rather than starting from the draft.

**5. Pattern flag (if any)**
If this is a recurring issue we've seen before, name it and reference the relevant case-library entry or pattern in "Issues we keep apologizing for."
~15 MINUTES

Test it on the last 20 tickets

Don't roll out live yet. Run the prompt against the last 20 resolved tickets — including the easy ones, the angry ones, and the tier-2 escalations. Three checks:

  • Did Claude pick up the right tier? Anything Claude tagged Tier 1 that should have been Tier 2 is a calibration miss — usually a sign that "what we cannot do" or "escalation tree" needs more detail.
  • Did the drafts sound like you? If 5+ of 20 drafts read as "obviously AI," your voice section is too thin. Add 3–5 example reply pairs (ticket + ideal reply) to the project as knowledge files.
  • Did Claude flag the right "Issues we keep apologizing for" matches? If it flagged 8 of 20 as pattern-matched and you'd have flagged 3, the project's issues list is too broad. Tighten it.
What the internal note should look like

Read of the ticket. Customer is asking why their export to CSV is missing the last 2 weeks of records. Emotional pitch: frustrated (third email this week from them, this one in all caps). Tier: 2 — touches the known iOS sync issue.

Relevant context. FAQ: "Why is my data missing from exports?" (FAQ-114, last updated 9 months ago — possibly stale). Case library: "Acme Corp data-recency complaint, resolved by force-resync — Mar 2026." Cannot-do: none relevant. Issues-we-keep-apologizing-for: MATCH — "iOS 18.x sync delay (6 weeks, engineering knows, sprint away)." This is the 11th ticket on this pattern this month.

Draft reply. "Hi Maria — the missing 2 weeks in your CSV is the iOS sync delay we've been wrestling with on 18.x. I'm sorry — I can see in your account this is the third time you've hit it, which is way past where it should have been resolved. Two things I can do right now: (1) trigger a force-resync on your account today, which should pull the missing 14 days into the next export, and (2) put your account on a flag for the engineering fix that's shipping next sprint, so you'll be in the first batch. The CSV will be regenerated within an hour — I'll email you when it's ready. — [rep]"

Confidence: 8/10. Uncertain on one thing: I don't know if "next sprint" is still the right timing. Recommend you check with engineering before sending.

Pattern flag. 11th iOS-18-sync ticket this month. Per Prompt 10 in the project, this is past the escalation threshold. Recommend the Service Hour this Friday includes a brief to engineering with the volume + customer-list.

~30 SECONDS, PER TICKET

Roll out live, one channel at a time

Start with one channel — usually email — and one rep. Both the rep and you review the drafts for the first 100 tickets. Two weeks in, expand to the rest of the team. Four weeks in, add the next channel. Don't roll this out across email + chat + in-app + phone on day one.

The rep's job changes slightly: they're now reviewing and editing a draft, not writing from scratch. The skill they develop is fast judgment on "is this draft right?" — which is a different muscle than "what should I write?" Train it deliberately. After two weeks, run Prompt 07 (voice audit) on 5 sent replies per rep, and surface the patterns at the Service Hour.

What this isn't. It isn't a tier-1 agent. It's draft-assist — every reply still passes through a human. The reason: voice drift, policy edge cases, and the "Issues we keep apologizing for" patterns all need a human to catch, especially in the first quarter. Autonomous handling is L4 — and only after this draft-assist workflow has been running cleanly for at least one full quarter.

05 — The horizon

What Level 4 looks like — including the famous tier-1 agent.

L4 for customer service is where the gravity is strongest and the failure mode is loudest. The famous "AI handles support" build — done right, it cuts service costs in half. Done wrong, it churns 2% of your customers in a quarter and you don't know why until it's too late.

The Sentiment Watch

Every Friday at 4pm, Claude scans the week's tickets, reviews, social comments, and inbound replies. Posts one Slack message: sentiment shift vs. last week, the three most revealing quotes (one positive, one negative, one surprising), and the one customer segment where sentiment is degrading fastest. Lowest-risk L4 in this section — the agent only reads and reports.

EXAMPLE — Friday Sentiment Watch

Overall: Stable, slight downward edge driven by volume of iOS-18 sync complaints (47 this week vs. 31 last week). Excluding that one issue, sentiment is up week-over-week.

Segment to watch: 14-day trial users on iOS specifically — sentiment has degraded 22% over 3 weeks. They're hitting the sync bug during evaluation and not converting. Likely material to trial-to-paid conversion rate next month.

Three quotes:

  • Positive (Maria, paid customer, 2 years): "The way the team handled my account migration last month is why I'm renewing on the multi-year."
  • Negative (Devin, trial, day 8): "I want to like this. But three days in a row of missing data isn't 'a bug,' it's a product decision."
  • Surprising (Casey, paid, 6 months): "Honestly I keep waiting for the part of your product I'll hate. It hasn't shown up yet."

The Knowledge Base Auto-Maintainer

Every resolved ticket gets scanned for FAQ gaps. Once a week, the agent proposes 3–5 new FAQ articles to write, ranked by deflection potential, with drafts already started. It also flags FAQ articles that are now stale because the product changed. The KB stops decaying.

This is the most under-appreciated L4 in service — because the failure mode is invisible (stale FAQ articles silently increasing ticket volume) and the win is gradual (deflection compounding over months). Build it second, after draft-assist is solid.

The Tier-1 Agent

The full version: an autonomous agent that handles common tier-1 queries end-to-end — password resets, order status, hours, return policy, basic how-tos. Reads the ticket, drafts the reply, sends it, closes the ticket. Escalates anything ambiguous to humans with full context attached.

The components are stable in 2026. Anthropic's small-business integrations support this directly. The architecture is well-understood: project context + FAQ + case library + clear escalation rules + a confidence threshold below which the agent always escalates.

The failure modes are also well-understood, and they're brutal:

  1. Voice drift. The agent's voice drifts away from your team's voice over a quarter — slow enough that nobody notices, fast enough that customers do.
  2. Policy edge cases. The agent applies the wrong policy to the wrong customer (the loyal customer who deserves an exception gets the same canned reply as the bad-faith one).
  3. The pattern miss. The agent fields 200 tickets about the same issue, closes them all "correctly," and nobody internally ever sees the pattern because the humans aren't in the loop anymore.
  4. The escalation rot. The escalation threshold drifts. The agent gradually handles cases it shouldn't, because confidence calibration drifts and nobody is checking it weekly.

The single most important control on a Tier-1 Agent isn't the threshold or the FAQ. It's the mandatory weekly transcript review: every Friday, a human reads a random sample of 20 closed-by-agent tickets, scores them, and updates the project. Skip the review and you don't have a tier-1 agent — you have a slow-motion incident.

EXAMPLE — a tier-1 ticket the agent should handle vs. escalate

Ticket A (agent handles): "Hi, can you tell me your business hours? Also I forgot my password." — Clean tier-1, two known FAQ patterns, no emotional pitch, no account history flags. Agent answers both questions and triggers the password-reset email. Closes ticket. Logs for review.

Ticket B (agent escalates): "I've been a customer for 3 years. This is the second outage in a month. Tell me why I shouldn't move to [competitor]." — Surface looks like a complaint about outages. Multiple flags: long-tenured customer (account history), churn threat (escalation trigger), pattern signal (second outage in a month is "Issues we keep apologizing for" territory). Agent does not reply. Escalates to Tier 2 with full context, customer's account history, and the relevant case-library entries attached.

The 80/20 of tier-1 agents is that they handle Ticket A perfectly and have to escalate Ticket B reliably. Most failed deployments fail because the agent tried to handle Ticket B.

If you're imagining the Tier-1 Agent right now — pause. The honest path: spend two full quarters at L3 with the draft-assist workflow. By the end of Q2 you'll know exactly which 4–6 ticket categories your agent can safely handle, what your real escalation rules are, and whether your voice section is strong enough to hold up under autonomous use. The build is then weeks of work. When you're at that point, a 30-minute call is the right next step — this is the L4 build where outside help most reliably pays for itself.

06 — How service stalls

Six ways this fizzles. Avoid them.

Service is the role where the failure modes are loudest because they're public — a bad AI reply is a screenshot away from going around. Here are the patterns to catch in yourself, before customers do.

Failure 01

Auto-sending without review

The fastest way to burn trust. Voice drift, wrong information, missed emotional cues — all of these slip through autonomous send. The screenshots circulate. The brand pays for months.

Draft-assist is the right L3. Tier-1 agent is the right L4 — and only after a full quarter of draft-assist running cleanly, and only with a mandatory weekly transcript review.

Failure 02

Treating every ticket the same

A 3-year customer asking about a billing edge case gets the same canned response as a new trial user asking about hours. The first customer notices. The second doesn't. The first one leaves.

Tier breakdown matters. Customer profile context in the project matters. "Score this ticket against our tiers" should fire before any draft.

Failure 03

Letting Claude make policy decisions

Refund exceptions, policy waivers, comp credits beyond your discount latitude — these are not draftable. The moment you let Claude draft these unsupervised, you've handed authority to something that has no relationship with the customer.

Define the policy in the project. Define the "who can approve an exception" in the project. Then route every exception request through a human, every time.

Failure 04

Not closing the learning loop

Replies get drafted and sent. Volume goes down. Nobody runs the Service Hour. Three months later, the same complaint has been answered 187 times — and engineering still doesn't know it's the top driver of tickets.

Volume is signal. If the signal dies in the queue, AI has made you faster at processing the same problem forever. The Service Hour exists to make that impossible.

Failure 05

Hiding behind AI

"Our AI helped me draft this reply…" Don't. Customers don't care about your tooling. They care about whether you helped them. Use AI invisibly. Be human in the conversation.

The exception: translation. If the reply was translated by AI and the language has nuance risk, a one-line disclosure builds trust. That's the only place this rule reverses.

Failure 06

Tier-1 agent without weekly review

Specifically called out separately from Failure 01 because it's the failure mode of the next 12 months for small businesses. The agent runs. The dashboards look fine. Volume drops. Then a churn cohort report lands and you can't explain it — because no human read the transcripts.

The mandatory weekly transcript review is the control loop. Skip the review and you don't have a tier-1 agent. You have an automated brand incident that hasn't fired yet.

The service team that wins with AI moves fast on drafts, slow on autonomy, and never skips the Friday review.

Download the template. Build the project, including the issues you'd rather not write down. Save the prompts. Wire the draft-assist. Run the Service Hour. In 90 days first-response time will be half what it is now — and you'll have a clear-eyed view of which complaints aren't really service problems at all.

⬇ Download the Project template Book a 30-min call