SOP de atención al cliente: cómo escribir una que sigan tanto los agentes como la IA

Resumen

Una SOP de atención al cliente es un procedimiento paso a paso para un tipo de ticket: cuándo se aplica, qué comprobar, qué hacer en cada caso y cuándo escalar. Las que funcionan son cortas, están escritas como pasos si/entonces, enlazan a la macro y pertenecen a una persona concreta con fecha de revisión. Las que fracasan son documentos largos que nadie abre hasta que el cliente ya está enfadado.

El gran cambio de 2026 es que tu SOP ahora tiene dos lectores: el empleado nuevo y el agente de IA. Zendesk, Gorgias, Freshdesk, Ada y Decagon piden procedimientos escritos como se los explicarías a un agente nuevo. Escribe la SOP una vez en ese formato y habrás formado a ambos.

Si tus SOP están repartidas entre Notion, vídeos de Loom y macros antiguas, eesel lee todo junto con tus tickets anteriores y redacta respuestas que siguen los mismos pasos, de modo que una corrección en la SOP aparece en la siguiente respuesta y no en la siguiente sesión de formación.

¿Qué es una SOP de atención al cliente?

Una SOP de atención al cliente (procedimiento operativo estándar) es un conjunto escrito de pasos para gestionar una situación recurrente siempre de la misma manera. "Cómo gestionamos una solicitud de reembolso" es una SOP. "Los reembolsos están disponibles durante 30 días" es una política. "Hola Sam, he procesado tu reembolso" es una macro.

En eesel construyo agentes de IA, y las instrucciones que siguen esos agentes son, sinceramente, SOP con un formato más estricto. Así que dedico mucho tiempo a mirar los procedimientos de equipos de soporte, y la confusión más común que veo es tener las tres capas mezcladas en un solo documento. La política cambia una vez al año, los pasos cambian cada trimestre y el texto cambia cada semana. Si lo metes todo en un documento, cada edición arriesga romper las otras dos.

Así se reparten las capas en la práctica:

La cuarta fila es nueva. Hace un par de años, la SOP era solo para personas. Ahora los mismos pasos alimentan al agente de IA, por eso el formato importa más que antes.

Por qué la mayoría de las SOP de soporte acaban sin leerse

Escribir SOP es la parte fácil. Lo difícil es que nadie las lee y se pudren. Un comentarista de Hacker News expresó la economía mejor que cualquier libro de operaciones que haya leído:

"The TCO of knowledge is dominated by the maintenance cost, not the creation cost... The org must make it someone's job to grow, weed, and maintain these gardens."

kjellsbells, Hacker News

Veo los mismos tres modos de fallo en casi todas las implantaciones de eesel:

1. La SOP existe, pero nadie lo sabe. Un ingeniero al que metieron en un ticket de RGPD describió que "we already have a canned response to these requests - the person on the support team is a new hire and was unaware" (Hacker News). El procedimiento estaba bien. Nadie lo mostró en el momento en que importaba.
2. El conocimiento está disperso. Una marca DTC de suplementos con la que hablé, que gestiona unos 7.000 tickets de Gorgias al mes, quería que la IA se ocupara de la mitad de su volumen de correo. Sus procedimientos estaban en SOP de ClickUp, vídeos de Loom sin transcribir y una larga cola de macros desactualizadas. Antes de que una IA pudiera seguir el proceso, alguien tenía que encontrarlo.
3. El conocimiento se va con las personas. Una empresa de servicios informáticos del sector público en Freshdesk, que gestiona unos 3.000 tickets complejos de ERP al mes, dijo al equipo de ventas de eesel que ese año perdía a dos agentes sénior y quería capturar su saber hacer antes de que se fueran. Eso es conocimiento tácito en estado puro: procedimientos reales que nunca se escribieron porque dos personas simplemente los sabían.

Y cuando los procedimientos están mal escritos, pueden empeorar las cosas. Un antiguo agente de soporte de eBay recordaba atender "4 concurrent chats, offering pre-programmed macros often pointing to terribly written documentation the person had already read and was confused about" (Hacker News). Una mala SOP no solo no ayuda. Envía al cliente de vuelta a la misma página que lo confundió.

La solución para los tres casos no es más documentación. Son procedimientos más cortos, mostrados dentro del ticket, con una persona responsable de mantener cada uno al día.

¿Qué procesos de soporte necesitan una SOP primero?

No todos los tipos de ticket necesitan un procedimiento escrito. Los restablecimientos de contraseña en un flujo de autoservicio no. Priorizo un proceso para SOP cuando puntúa alto en al menos dos de estos criterios:

• Volumen. Aparece a diario, así que las pequeñas incoherencias se acumulan.
• Coste de un error. Se mueve dinero, se exponen datos o hay un plazo legal.
• Decisiones de criterio. Los agentes tienen que decidir algo y dos agentes decidirían distinto.
• Traspasos entre equipos. Necesita ingeniería, facturación o legal, así que la vía de escalación tiene que ser explícita.

En la mayoría de los equipos eso da los mismos cinco primeros: reembolsos y devoluciones, acceso a la cuenta y verificación de identidad, caídas e incidentes, solicitudes de eliminación o exportación de datos y quejas que necesitan a un responsable. Empieza por ahí. Un equipo con cinco SOP sólidas supera a uno con cincuenta obsoletas.

Tampoco todos los procesos necesitan el mismo formato. Esta es la guía que uso para decidir:

Cómo escribir una SOP de atención al cliente

Este es el proceso que sigo, sea el lector un agente nuevo o un agente de IA. Calcula una hora por SOP en las primeras cinco.

1. Empieza con 20 tickets reales, no de memoria

Reúne 20 tickets recientes de un tipo y lee cómo los resolvieron realmente tus mejores agentes. Encontrarás pasos que nadie habría recordado escribir ("comprobar primero si pagaron con tarjeta regalo") y excepciones que ocurren cada semana. Escribir de memoria te da el proceso que crees que sigues. Los tickets te dan el que realmente sigues. Si ya tienes el hábito del análisis de tickets, es un trabajo de 20 minutos.

2. Escribe el desencadenante con las palabras del cliente

La primera línea responde a "¿cuándo se aplica esta SOP?". Escríbela como la formulan los clientes, no con tu etiqueta interna: "el cliente pide que le devuelvan el dinero, dice que le cobraron dos veces o quiere cancelar y que le reembolsen". Esto importa el doble para la IA. La propia documentación de Zendesk señala que un procedimiento que coincide de forma fiable en inglés puede fallar en francés, y la solución es ampliar el caso de uso con las frases que usan los clientes.

3. Una acción por paso y cada si/entonces detallado

Este es el mayor salto de calidad. Zendesk publica reglas de redacción para procedimientos que daría también a cualquier redactor humano: una acción por paso, condiciones "si... entonces..." explícitas, lenguaje concreto ("Pide al cliente su número de cuenta de 10 dígitos", no "Solicita datos de la cuenta") y el mismo término siempre ("Plan Premium", nunca a veces "Plan Gold"). La guía de Ada añade que cada rama necesita un "si no" y cada flujo una salida explícita (documentación de Ada).

Si un paso contiene la palabra "y", probablemente son dos pasos.

4. Escribe las excepciones y quién puede aprobarlas

La mayoría de las SOP describen el camino feliz y se detienen. Los tickets que duelen son las excepciones. Un comentarista de Hacker News describió a un agente que reconoció que le habían cobrado mal pero "could not refund me on the spot because of protocol" (Hacker News). La solución no es abandonar el protocolo. Es escribir la vía de excepción en la SOP: quién puede aprobarla, hasta qué importe y con qué rapidez. Usa números. "Más de 500 $ va al líder de equipo" se puede seguir. "Los reembolsos grandes necesitan aprobación" no.

5. Enlaza la macro, no pegues el texto

Pon la respuesta en una macro y enlázala desde el paso que la usa. Cuando marketing cambia el tono o legal cambia una frase, editas una macro y todas las SOP que apuntan a ella siguen siendo correctas. Zendesk limita las cuentas a 5.000 macros compartidas y Gorgias a 5.000 macros, así que no te quedarás sin espacio, pero te ahogarás si cada SOP genera sus propias copias. Mi guía sobre macros personales vs. compartidas cubre el lado de Zendesk.

6. Nombra a un responsable y una fecha de revisión

Cada SOP lleva el nombre de una persona y una fecha de "revisar antes de" arriba. No un equipo. Una persona. Sin eso, la SOP se convierte en lo que un comentarista llamó "backwaters of slowly rotting stuff" (Hacker News).

7. Pruébala con alguien sin contexto

Entrega la SOP a la persona más nueva del equipo, o a alguien de otro departamento, y observa cómo gestiona un ticket real con ella. Ada recomienda lo mismo para los procedimientos de IA: que alguien "with limited context" la revise (documentación de Ada). Cada pregunta que haga es una línea que falta. También es la mejora más barata del tiempo de adaptación que conozco.

Plantilla de SOP de atención al cliente

Esta es la plantilla que uso. Cópiala en tu base de conocimiento y rellena una por proceso.

SOP: [Process name]
Owner: [One person]          Review by: [Date, 90 days out]
Applies to: [Channels, regions, plans]

WHEN (trigger, in the customer's words)
- [How customers phrase it, 2 to 4 examples]

DON'T USE WHEN
- [Look-alike requests that need a different SOP]

CHECK FIRST
- [Field or system to look at, e.g. order date, plan, payment method]

STEPS
1. [One action]
2. IF [condition] THEN [action + macro link]
3. ELSE [action + macro link]

EXCEPTIONS AND APPROVALS
- [Situation] -> [Who approves] up to [$ / limit], within [time]

ESCALATE TO
- [Team or person], via [tag / group / channel], when [trigger]

TAGS / FIELDS TO SET
- [Tag names, custom fields, status]

LINKED MACROS
- [Macro name], [Macro name]

CHANGE LOG
- [Date] [What changed] [Who]

El bloque "No usar cuando" está tomado de cómo Decagon estructura los procedimientos de sus agentes, que dividen cada uno en una descripción, "When to use" y "When to not use".

Un ejemplo relleno: solicitud de reembolso

Así queda la plantilla rellena para una tienda de ecommerce típica. Sustituye por tus propias cifras.

Esa tabla responde todas las preguntas que un agente nuevo haría por Slack. Y es casi exactamente lo que también necesita un agente de IA, lo que me lleva a la parte a la que la mayoría de las guías de SOP aún no ha llegado. Para el lado de IA de los reembolsos, mi artículo sobre IA para solicitudes de reembolso profundiza más.

Tu SOP ahora también son las instrucciones de un agente de IA

Todas las grandes plataformas de soporte con IA que revisé piden ahora procedimientos escritos como escribirías una SOP para una persona. Ese es el cambio: una SOP bien escrita son los datos de entrenamiento de tu agente de IA, y una vaga es la razón de que los bots acaben seguros de sí mismos y equivocados.

Zendesk es el ejemplo más claro. Describes las políticas de tu negocio y genera un mapa de procedimiento que sigue el agente de IA, y desde mayo de 2026 los procedimientos de varios pasos están incluidos en los planes Suite y Support. El editor literalmente te pide describir los pasos "as you would with a human agent". Si ya escribiste tu SOP en el formato del paso 3, puedes pegarla. Cubrí la configuración más amplia en mi análisis de los agentes de IA de Zendesk.

Gorgias lo divide en dos. Guidance contiene tus políticas, hasta 100 entradas por tienda de 30.000 caracteres cada una, y Gorgias dice "among knowledge types, guidance carries the most weight" (documentación de Gorgias). Skills contiene la parte paso a paso, y acciones como cancelar un pedido solo se ejecutan desde dentro de un skill o una guidance (documentación de Skills de Gorgias). Gorgias también advierte de que un artículo de devolución de 30 días y una guidance de 14 días producirán respuestas incoherentes, que es el problema de las capas de antes en versión IA.

Freshdesk lo dice abiertamente: para sus Natural Language Workflows, "existing SOPs, playbooks, or support guides can often serve as a starting point." También recomienda el constructor visual para "deterministic, strictly sequenced, or compliance-driven processes", que es un buen consejo. Más sobre el lado de IA en mi artículo sobre los agentes de IA Freddy.

Hay dos consejos de fuera de los helpdesks que vale la pena copiar. La guía de OpenAI para crear agentes dice que hay que "use existing operating procedures, support scripts, or policy documents" y señala que en atención al cliente las rutinas "can roughly map to individual articles in your knowledge base" (OpenAI). Y Salesforce plantea lo que más querría que oyeran los equipos: las instrucciones no son deterministas y "don't replace the need for coded business rules." Su ejemplo es una regla de reembolso a 30 días, que pondrían en una acción que comprueba los criterios, no en una frase.

Ese es el límite honesto de la SOP como instrucciones. Un procedimiento escrito guía a la IA. No lo garantiza. El caso de Air Canada es la historia con moraleja a la que la gente sigue volviendo:

"Air Canada's chatbot returned sources along with its answer. ... Air Canada's argument was that because the chatbot response included a link to a page on the site outlining the policy correctly, Moffat should've known better."

Sayrus, Hacker News

La política correcta existía y el bot dijo otra cosa igualmente. Así que, para todo lo que implique mover dinero o exponer datos, escribo la SOP para el criterio de la IA y pongo el límite duro en la propia acción. Es la misma lógica que dar a un empleado nuevo un límite de reembolso en la herramienta de facturación en lugar de confiar en que lo recuerde. También es la razón de que las barreras de seguridad de IA y un traspaso a una persona limpio pertenezcan a la SOP y no se añadan después.

Dónde guardar las SOP de soporte

El mejor lugar para una SOP de atención al cliente es donde tus agentes ya están cuando el ticket está abierto. En la práctica, eso significa primero tu helpdesk y después una herramienta aparte. Esto es lo que ofrece cada helpdesk, según su propia documentación:

Varias cosas de esa tabla han afectado a equipos con los que he trabajado:

• Los artículos solo para agentes de Zendesk requieren Suite Growth o superior; en Suite Team no puedes restringir un artículo a los agentes. Y los procedimientos de auto assist de Zendesk, orientados al agente, solo pueden insertar artículos públicos y publicados, así que las SOP solo internas no se pueden enlazar en ellos. Mi artículo sobre los segmentos de usuarios de Zendesk recorre la configuración.
• Gorgias no tiene ningún ajuste de artículos solo para agentes. Los artículos Unlisted existen públicamente y son accesibles por URL, y la propia sugerencia de Gorgias para un sitio interno de procedimientos es un centro de ayuda aparte oculto a los buscadores (documentación de Gorgias). Vale para la mayoría de las tiendas, pero no pongas nada sensible ahí.
• Front muestra bases de conocimiento internas en el plugin de la barra lateral, pero la herramienta de insertar en la respuesta necesita una pública. Las SOP internas quedan junto a la conversación, no en el compositor.
• Freshdesk puede alimentar carpetas solo para agentes en su Solution Article Suggester, que requiere Freddy AI Copilot y al menos 25 artículos publicados (documentación de Freshdesk). Copilot cuesta 29 $ por agente al mes en Pro y Enterprise (precios de Freshdesk).

Cuándo tiene sentido una herramienta de SOP aparte

Una herramienta dedicada se justifica en tres casos: el procedimiento consiste sobre todo en clics en otros sistemas (las capturas ayudan), necesitas constancia de que cada agente lo leyó, o varios departamentos comparten los mismos procedimientos. Esto es lo que cuestan las opciones habituales, según sus páginas de precios:

Scribe es el más interesante ahora mismo. Su herramienta de captura convierte un procedimiento que recorres con clics en una guía, y ha empezado a presentar esas guías como entrada para agentes de IA, diciendo que puedes pasarlas "directly to your AI agents" mediante MCP o API (Scribe).

Una advertencia que vale para toda herramienta independiente: una SOP que vive fuera del helpdesk solo funciona si los agentes pueden llegar a ella desde el ticket. Si tienen que abrir una segunda aplicación y buscar, no lo harán, sobre todo con cuatro chats simultáneos. Comprueba si hay una app de barra lateral o una extensión de navegador antes de comprometerte. Y conserva una vía de exportación. Un revisor de Trainual en G2 señaló que "the moment you stop paying you lose all your hard work making the SOP" (G2). Tus procedimientos son de tu empresa, sea cual sea la herramienta que los guarde. Para una comparación más amplia, consulta mi resumen de software de base de conocimiento para atención al cliente.

Cómo evitar que las SOP se queden obsoletas

Una SOP obsoleta es peor que ninguna, porque un agente que confía en ella envía una respuesta equivocada con seguridad. El sistema que me funciona es un pequeño ciclo en lugar de una gran auditoría anual.

1. Da a los agentes una forma de señalar una laguna con un clic. Basta una etiqueta como "sop-gap" en el ticket. El panel de conocimiento de Zendesk permite a los agentes marcar un artículo, lo que crea un ticket para el responsable (documentación de Zendesk).
2. Dirige el aviso al responsable, no al equipo. Para eso sirve el nombre que aparece arriba de la SOP.
3. Corrige la SOP, luego la macro, luego las instrucciones de IA. El mismo día si puedes. Si te saltas lo último, tu IA seguirá citando la regla del mes pasado.
4. Revisa por calendario de todos modos. Uso 90 días para reembolsos, acceso y seguridad, y seis meses para el resto.
5. Mira las etiquetas de lagunas cada mes. Tres avisos sobre la misma SOP significan que necesita una reescritura, no un parche. Un análisis de lagunas de conocimiento lo hace a escala.

Algunas herramientas automatizan el recordatorio. La verificación de artículos de Zendesk permite a los administradores definir hasta 20 reglas de verificación y envía correos a los responsables de los artículos hasta que verifican, pero es solo Enterprise.

Document360 cambia un artículo a "Stale" cuando pasa su fecha de revisión, y Guru marca las tarjetas caducadas como sin verificar en la cola de tareas del verificador (Guru). Un especialista en conocimiento que reseñó Guru en G2 describió por qué importa para soporte:

"Instead of the content becoming obsolete, the platform enforces ownership by prompting subject matter experts to re-verify knowledge on a set schedule. This maintains a highly trustworthy repository for our support specialists directly inside our communications tools."

Dairon P., G2

Las herramientas ayudan, pero no sustituyen el hábito. Otro revisor de Guru señaló que editar una tarjeta por formato la verifica automáticamente, aunque quien edita no sea el experto (G2). Una marca verde solo significa que alguien hizo clic. No significa que los pasos sean correctos.

Errores que hacen fracasar las SOP de atención al cliente

Estos son los patrones que más veo cuando un equipo dice "tenemos SOP, nadie las usa":

• Escribir un ensayo. Si pasa de una pantalla, los agentes la ojean en pleno ticket y se pierden el paso que importaba. El contexto largo pertenece al documento de política.
• Mezclar la política, los pasos y el texto. Cada edición se vuelve arriesgada, así que nadie edita. Mantén las tres capas separadas.
• Sin números en las excepciones. "Escalar los reembolsos grandes" significa algo distinto para cada agente y cada IA.
• Una SOP copiada por canal o región. Un hilo de Reddit sobre la estructura de las SOP lo explicó bien: "Once you start duplicate SOPs, keeping them all current becomes its own job" (Reddit). Ramifica dentro de una sola SOP.
• Tratar la SOP como un guion. Los guiones de nivel 1 ayudan a que los agentes no se salten un paso, pero las mejores SOP dan un límite de autoridad y una razón, para que los agentes puedan resolver el caso que la SOP no previó. Mi artículo sobre el feedback a agentes de soporte cubre el lado del coaching.
• Dejar que la IA escriba y reescriba SOP sin control. Un comentarista describió a un agente "doing massive updates on Confluence constantly" y lo encontró "full of hallucinations and nonsense" (Hacker News). La IA puede redactar a partir de tickets. Una persona con contexto sigue dando el visto bueno.

Si estás incorporando a un grupo de agentes nuevos, las SOP son la mitad de la formación. Si trabajas en varias zonas horarias, también son lo que mantiene coherente un traspaso de turno a las 3 de la madrugada.

eesel para SOP de atención al cliente

Si tus procedimientos están repartidos entre un helpdesk, un wiki, algunos vídeos de Loom y un montón de macros, el compañero de helpdesk con IA de eesel está hecho para ese desorden. Se conecta con Zendesk, Freshdesk, Gorgias, Front, Help Scout y los documentos donde viven tus SOP, como Confluence, Notion y Google Docs, y también aprende de tus tickets anteriores, así que recoge los pasos que realmente siguen tus mejores agentes, incluidos los que nadie escribió. Redacta respuestas o responde directamente, y antes de activar nada puedes simularlo con cientos de tus tickets anteriores para ver dónde seguiría la SOP y dónde fallaría.

Lo más importante para las SOP es la página de instrucciones. Es un documento sencillo con tus pautas de respuesta y pasos de flujo de trabajo, escrito en el mismo formato que la plantilla de arriba. Cuando un responsable corrige una respuesta en el chat, eesel escribe la corrección en esas instrucciones, de modo que el arreglo se aplica a todas las respuestas futuras en lugar de quedarse en la cabeza de una persona.

Tampoco necesitas una biblioteca enorme para empezar. Un equipo de soporte del Reino Unido que estudié hizo que eesel resolviera 56 tareas con solo nueve macros de Zendesk sincronizadas. Cinco SOP claras y un puñado de macros llegan más lejos de lo que crees.

Para ser claros sobre el ámbito: eesel no es una herramienta de formación ni de aprobación, así que si necesitas firmas electrónicas de que cada agente leyó la SOP de reembolsos, conserva Trainual o similar para eso. Lo que hace es asegurar que la SOP se siga en cada ticket, por la IA y por el agente que revisa su borrador. Puedes probar eesel gratis con 100 créditos, sin tarjeta, y ver cómo gestiona tus propios tickets.