Contenido detallado
🍕 La pizza del Support OS
El Support OS tiene una estructura parecida a la del Sales OS: el contexto (la base de tickets y los playbooks) y las skills (triaje y borrador de respuesta) llevan el peso. Lo que cambia es el objetivo: aquí no se trata de prospectar, sino de responder bien y rápido sin prometer lo que el playbook no cubre.
🌱 ¿Nuevo aquí?
Un ticket es cada solicitud de ayuda de un cliente. Clasificación es clasificar y priorizar esas solicitudes antes de responder. Un playbook es el guion para manejar cada tipo de caso. Escalamiento es pasarle el caso a una persona (o a un nivel superior) cuando se sale del guion.
✓ Lo que aporta el Support OS
- ✓Contexto: tickets agregados + manuales de políticas.
- ✓Skills: clasificación, borrador de respuesta, escalamiento.
- ✓Ganchos: citar la fuente de la política, control de acceso.
✗ Lo que sale mal
- ✗Responder sin playbook: una promesa fuera de la política.
- ✗Enviar la respuesta directamente al cliente sin revisión.
- ✗Dar acceso de escritura al «pasante» en el CRM.
Por qué aprender
Porque muestra el mismo formato al servicio de un nuevo objetivo. Reconoces las capas dominantes (contexto + skills) y ya anticipas dónde estarán los límites: en soporte, una respuesta errónea se convierte en un riesgo legal, así que las reglas y los hooks tienen un peso especial.
Conceptos clave
📚 Contexto: agrupar tickets, hilos largos = casos complejos
El contexto empieza trayendo todos los tickets de donde se encuentran: — Zendesk, HubSpot o similar, junto con los documentos de ayuda. Y hay un truco del autor: enviar a un agente a buscar las hilos más largos, porque la longitud de la conversación es un buen indicador de "caso complejo". Esos son los hilos que más vale la pena convertir en un playbook.
🔎 De dónde viene el contexto
- Help desk — Zendesk, HubSpot o lo que uses, con todos los tickets en un solo lugar.
- Documentación de ayuda — la base de conocimiento que el OS puede consultar.
- Tickets anteriores — especialmente los de hilos largos (casos difíciles).
- Vías de escalamiento — qué clientes/temas pasan directamente a una persona.
💡 El proxy del hilo largo
En vez de intentar adivinar qué casos son complejos, ordénalos por duración de la conversación. Un hilo de 40 mensajes casi siempre esconde un problema recurrente o un cliente difícil — exactamente el material que merece un playbook dedicado.
Por qué aprender
Porque un contexto bien integrado es lo que permite dar respuestas consistentes. Sin reunir los tickets e identificar los casos complejos, cada agente de atención al cliente reinventa la rueda y el OS responde de forma genérica. El indicador de un hilo largo es un atajo práctico para encontrar qué destilar primero.
Conceptos clave
📓 Playbooks a partir de los casos difíciles
Después de encontrar los hilos largos, el agente los sintetiza en nuggets y genera playbooks: "cómo tratar con el cliente que siempre trae X", "cuál es la ruta de escalamiento para el caso Y". Es el patrón raw → sintetizado de la Ruta 1, aplicado a la atención al cliente.
Cómo leer: las conversaciones más largas (teal) se destilan en nuggets y se convierten en un playbook (cian) reutilizable. En vez de que el agente vuelva a leer 40 mensajes, consulta el guion listo para el caso.
Por qué aprender
Porque el playbook es lo que da coherencia. Cuando el caso raro se convierte en un guion, cualquier agente de atención (o la skill de draft) responde correctamente de la misma manera, y el cliente recibe la misma calidad sin importar quién lo atienda. Así es como el conocimiento tácito del equipo se convierte en un activo del OS.
Conceptos clave
🛠️ Skills: clasificación, borrador de respuesta, escalamiento
Las tres skills del Support OS forman una línea: clasificación (clasifica y prioriza), borrador (redacta la respuesta con base en el playbook) y escalamiento (decide cuándo y cómo pasar a una persona). Juntas, reducen el tiempo que el agente de atención dedica a preguntas repetitivas.
La secuencia de skills de atención al cliente
Clasificación
Clasifica el ticket por tema y urgencia y decide qué hacer: responder, pedir información o escalar.
Borrador de respuesta
Redacta la respuesta para los casos con un playbook claro y cita la fuente de la política.
Escalamiento
Cuando el caso se sale del playbook, decide a quién escalarlo y cómo, sin improvisar una respuesta.
💡 Dónde la IA ahorra tiempo
La meta no es reemplazar al agente de atención, sino reducir el tiempo dedicado a lo repetitivo. El triaje organiza la fila, el borrador adelanta lo obvio y la persona se enfoca en los casos que realmente requieren criterio.
Por qué aprender
Porque estas skills son la parte que más tiempo ahorra en la atención al cliente. Pero solo funcionan bien con el contexto adecuado: el triaje necesita el playbook para decidir el camino, y el draft necesita la política para no prometer de más. Una skill sin contexto aquí se convierte en un riesgo.
Conceptos clave
🤖 Agentes: líder de soporte + revisor escéptico
Dos agentes guardan el resultado. El líder de soporte orquesta las skills, sella tickets y hace la primera verificación. Y el revisor escéptico — el abogado del diablo: verifica cada respuesta antes de que llegue al cliente, buscando promesas indebidas y vacíos en la política.
Líder de soporte
Orquesta la clasificación, el borrador y el escalamiento; cierra los tickets y hace la primera verificación antes de pasarlos.
Revisor escéptico
Vuelve a leer la respuesta como abogado del diablo: «¿esto está en el playbook? ¿Se citó la fuente? ¿Prometimos algo que no podemos cumplir?»
Cómo leer: el triaje (teal) abre tres caminos; solo el camino "responder" pasa por el revisor escéptico antes de llegar al cliente (cian). Pedir información y escalar siguen rutas propias. Nada llega al cliente sin pasar por la puerta de control.
Por qué aprender
Porque el punto de revisión es tu póliza de seguro. En soporte, una frase equivocada puede convertirse en una promesa legal; el revisor escéptico existe para detectarla antes de que llegue al cliente. Es el mismo patrón adversarial del Tax OS, y lo vuelves a encontrar en el Consulting OS, en la voz del cliente.
Conceptos clave
🚧 Reglas y ganchos: citar la fuente, los júnior solo leen
En soporte, las barreras te protegen legalmente. La regla básica es no hacer promesas fuera del playbook. Y hay un gancho elegante: si una respuesta menciona una política sin referencia ni enlace a la fuente, se marca automáticamente. Además, el "pasante júnior" solo puede leer el CRM, nunca escribir.
✓ Se convierte en gancho (determinístico)
- ✓Respuesta que cita una política sin enlace → alerta automática.
- ✓Pasante junior: acceso de solo lectura al CRM, sin cambiar el estado.
- ✓El ticket sensible pasa directamente a una persona, sin revisión de IA.
✗ Queda solo como regla «blanda»
- ✗"Mantén un tono sereno y usa la voz de la marca" (estilo).
- ✗"Prefiere respuestas breves" (formato, reversible).
- ✗"Intenta resolverlo en el primer contacto" (meta, no bloqueo).
⚠️ El riesgo que hay que evitar
Dejar que la IA «invente políticas» bajo presión. Sin el gancho que exige la fuente, puede afirmar con seguridad algo que no está en el playbook — y eso se convierte en una promesa que no puedes cumplir, con consecuencias legales. La regla de «si no hay fuente, avisa» es lo que mantiene honesta la atención.
Por qué aprender
Porque es el principio de "determinístico donde duele" aplicado a la atención al cliente. Las promesas indebidas y el acceso de escritura son riesgos demasiado serios para reglas flexibles; se convierten en ganchos. El control de acceso del junior y el flag de fuente son pequeños, pero evitan los errores más costosos del dominio.
Conceptos clave
⚙️ Práctico: clasificación de tickets
El prompt de abajo es copy-run: pégalo en Claude Code con tu archivo de tickets y el playbook a mano. Hace la clasificación del tema 4 — clasifica, prioriza y decide el camino — sin responderle todavía al cliente y sin inventar políticas. Cambia los fragmentos <...>.
🎯 Objetivo
Recibir una cola de tickets y devolver una tabla clasificada (tema, urgencia, camino y la fuente del playbook), ordenada por urgencia, lista para que el agente actúe.
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.
✅ Cómo verificar que funcionó
- 1.Todo ticket tiene tema, urgencia y camino — ninguno en blanco.
- 2.Todo RESPONDER menciona una sección del playbook; sin fuente, se convirtió en ESCALAR.
- 3.Todo PEDIR-INFO dice qué dato específico falta.
- 4.La tabla está ordenada por urgencia (alta en la parte superior).
- 5.No se escribió ninguna respuesta al cliente: solo la clasificación inicial.
💡 Siguiente paso
Para los tickets marcados RESPONDER, pide el borrador de respuesta citando la sección del playbook —y haz que pase por el revisor escéptico antes de cualquier envío. Primero, clasifica; luego, responde; revisa siempre.
Por qué aprender
Porque la clasificación inicial es el primer paso que organiza todo lo demás. Ejecutar este copy-run te da la fila priorizada y el hábito de exigir la fuente de la política: el mismo «objetivo, bloque copiable y cómo verificar» que se aplica a cualquier skill de tu Support OS.
Conceptos clave
✅ Resumen del módulo
Siguiente módulo:
5.4 — Content OS 🎬 (fábrica de títulos y regla de no exagerar)