Detailed content
🍕 The Support OS pizza
The Support OS has a structure similar to the Sales OS: the context (the ticket database and playbooks) and the skills (triage and reply drafting) carry the weight. What changes is the goal: here, it’s not prospecting, it’s respond well and fast without promising what the playbook doesn't cover.
🌱 New here?
One ticket is each request for help from a client. Triage is classifying and prioritizing those requests before responding. A playbook is the playbook for handling each type of case. Scaling is handing the case off to a human (or a higher level) when it falls outside the playbook.
✓ What carries the Support OS
- ✓Context: aggregated tickets + policy playbooks.
- ✓Skills: triage, response draft, escalation.
- ✓Hooks: cite policy source, access control.
✗ What goes wrong
- ✗Answer without a playbook — a promise outside policy.
- ✗Send the response directly to the client without review.
- ✗Give the "intern" write access in the CRM.
Why learn
Because it shows the same format serving a new goal. You recognize the layers that dominate (context + skills) and can already anticipate where the guardrails will be: in support, a wrong answer becomes a legal risk, so rules and hooks carry special weight.
Key concepts
📚 Context: combining tickets, long threads = complex cases
Context starts by pulling all the tickets from where they live — Zendesk, HubSpot or similar—alongside the help documents. And there’s an author’s trick: have an agent look for the longer threads, because conversation length is a good proxy for a "complex case." These are the threads most worth turning into a playbook.
🔎 Where the context comes from
- Help desk — Zendesk, HubSpot, or whatever you use, with all tickets in one place.
- Help docs — the knowledge base that the OS can reference.
- Past tickets — especially long-thread cases (hard cases).
- Escalation paths — which clients/topics go straight to a human.
💡 The long-thread proxy
Instead of trying to guess which cases are complex, sort by conversation length. A 40-message thread almost always hides a recurring problem or a difficult client — exactly the material that deserves a dedicated playbook.
Why learn
Because well-aggregated context is what enables consistent answers. Without bringing the tickets together and identifying complex cases, every support rep reinvents the wheel—and the OS gives generic answers. The long-thread proxy is a practical shortcut for finding what to distill first.
Key concepts
📓 Playbooks from tough cases
After finding the long threads, the agent synthesizes into nuggets and generates playbooks: "how to handle a customer who always brings X," "what’s the escalation path for case Y." That’s the pattern raw → synthesized from Track 1, applied to customer service.
How to read: the longer conversations (teal) are distilled into nuggets and become a reusable playbook (cyan). Instead of the agent rereading 40 messages, it consults the ready-made case guide.
Why learn
Because the playbook is what gives consistency. When a rare case becomes a playbook, any support rep (or the draft skill) responds the same correct way—and the customer gets the same quality no matter who handles the request. That’s how a team’s tacit knowledge becomes an OS asset.
Key concepts
🛠️ Skills: Triage, Response Draft, Escalation
The three Support OS skills form a pipeline: triage (classifies and prioritizes), draft (drafts the reply based on the playbook) and escalation (decides when and how to hand off to a human). Together, they reduce the time the support rep spends on repetitive questions.
The customer service skills pipeline
Triage
Classify the ticket by topic and urgency, then decide what to do: respond, ask for information, or escalate.
Response draft
Drafts a response for cases with a clear playbook, citing the policy source.
Scaling
When a case falls outside the playbook, it decides who to escalate to and how—without improvising a response.
💡 Where AI saves time
The goal isn’t to replace the customer service representative, but to reduce the time spent on repetitive tasks. Triage organizes the queue, the draft gets the obvious work done ahead of time, and the human focuses on cases that truly require judgment.
Why learn
Because these skills are the part that saves the most time in customer service. But they work well only when supported by context: triage needs the playbook to choose a path, and the draft needs the policy to avoid overpromising. A skill without context is a risk here.
Key concepts
🤖 Agents: Support Lead + Skeptical Reviewer
Two agents guard the output. The support lead orchestrates skills, seals tickets, and does the first check. And the skeptical reviewer — the devil’s advocate — checks every response before it reaches the client, hunting for overpromises and policy gaps.
Support lead
Orchestrates triage, drafting, and escalation; closes tickets and does the first check before handing them off.
Skeptical reviewer
Reread the response as a devil’s advocate: “Is this in the playbook? Was the source cited? Did we promise something we can’t deliver?”
How to read: triage (teal) opens three paths; only the "respond" path goes through the skeptical reviewer before reaching the client (cyan). Asking for info and escalating follow their own routes. Nothing reaches the client without passing through the gate.
Why learn
Because the review gate is your insurance policy. In support, one wrong sentence can become a legal promise; the skeptical reviewer is there to catch it before it reaches the customer. It’s the same adversarial pattern as the Tax OS—and you’ll encounter it again in the Consulting OS, in the client’s voice.
Key concepts
🚧 Rules & Hooks: Cite Sources, Juniors Read Only
In support, the guardrails protect you legally. The baseline rule is don’t make promises outside the playbook. And there's a clever hook: if an answer mentions a policy without a reference or link to the source, it's automatically flagged. Also, the "junior intern" can only read the CRM, never write.
✓ Becomes a hook (deterministic)
- ✓Response cites policy without a link → automatic flag.
- ✓Junior intern: read-only access to the CRM, no status changes.
- ✓Sensitive ticket goes straight to a human, without AI review.
✗ Remains only a “soft” rule
- ✗"Keep the tone calm and in the brand voice" (style).
- ✗"Prefer short answers" (format, reversible).
- ✗"Try to resolve it on the first contact" (goal, not a hard stop).
⚠️ The risk to avoid
Let the AI "make up policy" under pressure. Without the hook that requires a source, it may confidently state something that isn't in the playbook—and that becomes a promise you can't keep, with legal consequences. The "no source, flag it" safeguard is what keeps support honest.
Why learn
Because it’s “deterministic where it hurts” applied to customer service. Improper promises and write access are too serious a risk for soft rules; they become hooks. Junior access control and the source flag are small, but they prevent the domain’s costliest mistakes.
Key concepts
⚙️ Practical: ticket triage
The prompt below is copy-run: paste it into Claude Code with your tickets file and playbook ready. It triages Topic 4 — classifies, prioritizes, and decides the path — without replying to the customer yet without making up policy. Replace the sections <...>.
🎯 Objective
Receive a queue of tickets and return a triage table (topic, urgency, route, and playbook source), sorted by urgency—ready for the support agent to act.
Você é o triador do meu Support OS. Classifique cada ticket e decida o caminho, SEM responder ao cliente ainda. Nunca invente política fora do playbook. Arquivos: - Tickets: <./tickets/abertos.csv> (colunas: id, cliente, assunto, mensagem) - Playbook de políticas: <./substrate/playbook-politicas.md> Para CADA ticket, faça: 1. TEMA: classifique (ex.: cobrança, bug, dúvida de uso, cancelamento). 2. URGÊNCIA: alta / média / baixa, pelo impacto e pelo tom da mensagem. 3. CAMINHO: - RESPONDER: há resposta clara no playbook (cite a SEÇÃO que embasa). - PEDIR-INFO: falta dado do cliente para resolver (diga qual). - ESCALAR: fora do playbook, tema jurídico, ou cliente pediu humano. 4. Se for RESPONDER mas você NÃO achar a seção do playbook, vire ESCALAR. 5. Saída: tabela | id | tema | urgência | caminho | fonte-playbook |. Ordene por urgência (alta primeiro). No fim, conte quantos por caminho.
✅ How to verify that it worked
- 1.Every ticket has topic, urgency, and path — none left blank.
- 2.Every RESPOND cites a section of the playbook; without a source, it became SCALE.
- 3.Every ASK-FOR-INFO says exactly which data is missing.
- 4.The table is sorted by urgency (high at the top).
- 5.No customer response was written — only the triage.
💡 Next step
For the tagged tickets RESPOND, ask for the reply draft citing the playbook section — and have it go through the skeptical reviewer before anything is sent. Triage first, response second, review always.
Why learn
Because triage is the first step that organizes everything else. Running this copy-run gives you the prioritized queue and the habit of asking for the policy source—the same “objective, copyable block, and how to verify” that applies to any skill in your Support OS.
Key concepts
✅ Module summary
Next module:
5.4 — Content OS 🎬 (title factory and no-hype rule)