Conteúdo detalhado
🍕 A pizza do Support OS
O Support OS tem estrutura parecida com a do Sales OS: o contexto (a base de tickets e os playbooks) e as skills (triagem e draft de resposta) carregam o peso. O que muda é o objetivo: aqui não é prospectar, é responder bem e rápido sem prometer o que o playbook não cobre.
🌱 Novo aqui?
Um ticket é cada pedido de ajuda de um cliente. Triagem é classificar e priorizar esses pedidos antes de responder. Um playbook é o roteiro de como lidar com cada tipo de caso. Escalonamento é passar o caso para um humano (ou nível mais alto) quando foge do roteiro.
✓ O que carrega o Support OS
- ✓Contexto: tickets agregados + playbooks de política.
- ✓Skills: triagem, draft de resposta, escalonamento.
- ✓Ganchos: citar fonte da política, controle de acesso.
✗ O que dá errado
- ✗Responder sem playbook — promessa fora da política.
- ✗Mandar a resposta direto ao cliente sem revisão.
- ✗Dar acesso de escrita ao "estagiário" no CRM.
Por que aprender
Porque mostra o mesmo formato servindo a um objetivo novo. Você reconhece as camadas que dominam (contexto + skills) e já antecipa onde estarão as cercas: em suporte, uma resposta errada vira risco legal, então as regras e ganchos têm peso especial.
Conceitos-chave
📚 Contexto: agregar tickets, threads longas = casos complexos
O contexto começa puxando todos os tickets de onde eles vivem — Zendesk, HubSpot ou similar — junto dos documentos de ajuda. E há um truque do autor: mandar um agente buscar as threads mais longas, porque o tamanho da conversa é um bom proxy para "caso complexo". São essas threads que mais valem virar playbook.
🔎 De onde vem o contexto
- Help desk — Zendesk, HubSpot ou o que você usar, com todos os tickets num lugar.
- Docs de ajuda — a base de conhecimento que o OS pode referenciar.
- Tickets passados — especialmente os de thread longa (casos difíceis).
- Caminhos de escalonamento — quais clientes/temas pulam direto para humano.
💡 O proxy da thread longa
Em vez de tentar adivinhar quais casos são complexos, ordene por comprimento da conversa. Uma thread de 40 mensagens quase sempre esconde um problema recorrente ou um cliente difícil — exatamente o material que merece um playbook dedicado.
Por que aprender
Porque o contexto bem agregado é o que permite respostas consistentes. Sem juntar os tickets e identificar os casos complexos, cada atendente reinventa a roda — e o OS responde de forma genérica. O proxy da thread longa é um atalho prático para achar o que destilar primeiro.
Conceitos-chave
📓 Playbooks a partir dos casos difíceis
Depois de achar as threads longas, o agente as sintetiza em nuggets e gera playbooks: "como lidar com o cliente que sempre traz X", "qual o caminho de escalonamento para o caso Y". É o padrão raw → sintetizado da Trilha 1, aplicado a atendimento.
Como ler: as conversas mais longas (teal) são destiladas em nuggets e viram um playbook (ciano) reutilizável. Em vez de o atendente reler 40 mensagens, ele consulta o roteiro pronto do caso.
Por que aprender
Porque playbook é o que dá consistência. Quando o caso raro vira roteiro, qualquer atendente (ou a skill de draft) responde da mesma forma correta — e o cliente recebe a mesma qualidade independentemente de quem atende. É como o conhecimento tácito do time vira ativo do OS.
Conceitos-chave
🛠️ Skills: triagem, draft de resposta, escalonamento
As três skills do Support OS formam uma linha: triagem (classifica e prioriza), draft (rascunha a resposta com base no playbook) e escalonamento (decide quando e como passar para humano). Juntas, reduzem o tempo que o atendente gasta com perguntas repetitivas.
A linha de skills do atendimento
Triagem
Classifica o ticket por tema e urgência e decide o caminho: responder, pedir info ou escalar.
Draft de resposta
Rascunha a resposta para os casos com playbook claro, citando a fonte da política.
Escalonamento
Quando o caso foge do playbook, decide para quem e como escalar — sem improvisar resposta.
💡 Onde a IA ganha tempo
A meta não é substituir o atendente, e sim baixar o tempo gasto com o repetitivo. A triagem organiza a fila, o draft adianta o que é óbvio, e o humano foca nos casos que realmente exigem julgamento.
Por que aprender
Porque essas skills são a fatia que mais economiza tempo no atendimento. Mas elas só funcionam bem apoiadas no contexto: triagem precisa do playbook para decidir o caminho, e o draft precisa da política para não prometer demais. Skill sem contexto, aqui, vira risco.
Conceitos-chave
🤖 Agentes: líder de suporte + revisor cético
Dois agentes guardam a saída. O líder de suporte orquestra as skills, sela tickets e faz a primeira checagem. E o revisor cético — o advogado do diabo — confere cada resposta antes de ela chegar ao cliente, caçando promessas indevidas e furos de política.
Líder de suporte
Orquestra triagem, draft e escalonamento; sela os tickets e faz a primeira verificação antes de passar adiante.
Revisor cético
Relê a resposta como advogado do diabo: "isso está no playbook? a fonte foi citada? prometemos algo que não podemos?".
Como ler: a triagem (teal) abre três caminhos; só o caminho "responder" passa pelo revisor cético antes de chegar ao cliente (ciano). Pedir info e escalar seguem rotas próprias. Nada vai ao cliente sem passar pelo portão.
Por que aprender
Porque o review gate é a sua apólice de seguro. Em suporte, uma frase errada pode virar promessa legal; o revisor cético existe para pegar isso antes do cliente. É o mesmo padrão adversarial do Tax OS — e você o reencontra no Consulting OS, na voz do cliente.
Conceitos-chave
🚧 Regras & ganchos: citar fonte, júnior só lê
Em suporte, as cercas protegem você juridicamente. A regra-base é não fazer promessas fora do playbook. E há um gancho elegante: se uma resposta menciona uma política sem referência ou link para a fonte, ela é automaticamente sinalizada. Além disso, o "estagiário júnior" só pode ler o CRM, nunca escrever.
✓ Vira gancho (determinístico)
- ✓Resposta cita política sem link → flag automático.
- ✓Estagiário júnior: read-only no CRM, sem mudar status.
- ✓Ticket sensível pula direto para humano, sem revisão de IA.
✗ Fica só como regra "mole"
- ✗"Mantenha o tom calmo e na voz da marca" (estilo).
- ✗"Prefira respostas curtas" (formato, reversível).
- ✗"Tente resolver no primeiro contato" (meta, não trava).
⚠️ O risco a evitar
Deixar a IA "inventar política" sob pressão. Sem o gancho que exige a fonte, ela pode afirmar com confiança algo que não está no playbook — e isso vira promessa que você não pode cumprir, com consequência legal. A trava de "sem fonte, sinaliza" é o que mantém o atendimento honesto.
Por que aprender
Porque é "determinístico onde dói" aplicado a atendimento. Promessa indevida e acesso de escrita são riscos sérios demais para regras moles; viram ganchos. O controle de acesso do júnior e o flag de fonte são pequenos, mas evitam os erros mais caros do domínio.
Conceitos-chave
⚙️ Prático: triagem de tickets
O prompt abaixo é copy-run: cole no Claude Code com seu arquivo de tickets e o playbook à mão. Ele faz a triagem do tópico 4 — classifica, prioriza e decide o caminho — sem responder ao cliente ainda e sem inventar política. Troque os trechos <...>.
🎯 Objetivo
Receber uma fila de tickets e devolver uma tabela triada (tema, urgência, caminho e a fonte do playbook), ordenada por urgência — pronta para o atendente agir.
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.
✅ Como verificar que funcionou
- 1.Todo ticket tem tema, urgência e caminho — nenhum em branco.
- 2.Todo RESPONDER cita uma seção do playbook; sem fonte, virou ESCALAR.
- 3.Todo PEDIR-INFO diz qual dado específico falta.
- 4.A tabela está ordenada por urgência (alta no topo).
- 5.Nenhuma resposta ao cliente foi escrita — só a triagem.
💡 Próximo passo
Para os tickets marcados RESPONDER, peça o draft de resposta citando a seção do playbook — e mande passar pelo revisor cético antes de qualquer envio. Triagem primeiro, resposta depois, revisão sempre.
Por que aprender
Porque a triagem é o primeiro passo que organiza todo o resto. Rodar este copy-run te dá a fila priorizada e o hábito de exigir a fonte da política — o mesmo "objetivo, bloco copiável e como verificar" que vale para qualquer skill do seu Support OS.
Conceitos-chave
✅ Resumo do módulo
Próximo módulo:
5.4 — Content OS 🎬 (fábrica de títulos e regra no-hype)