Resumen
La gestión de excepciones en soporte son tres tareas: decidir quién puede flexibilizar qué política, registrar cada excepción de la misma manera y revisar el registro para que las excepciones repetidas se conviertan en reglas. La mayoría de los equipos hace la primera con poco rigor y se salta las otras dos, por eso el mismo cliente recibe un sí de un agente y un no del siguiente.
El cambio que defiendo: una excepción que concedes casi siempre ya es tu política, solo que no está escrita. Y el lugar para detectarla no es una nota interna, sino un campo desplegable obligatorio sobre el que tu helpdesk pueda generar informes. Ojo con las trampas: el «obligatorio para resolver» de Zendesk puede saltarse con disparadores, automatizaciones y fusiones, y el informe de campos de ticket de Gorgias solo cuenta los campos desplegables.
Trabajo la cola de soporte de eesel todos los días, y en las excepciones tanto los agentes como la IA necesitan las reglas más claras. En una prueba con tráfico real en una bandeja de Zendesk de ecommerce, el 96,4 % de los borradores de eesel sobre reclamaciones de garantía fueron útiles para el agente. Para eso está hecho el compañero de IA de eesel: aplica las excepciones que has dejado por escrito, retiene para la persona adecuada todo lo que cuesta dinero y pasa el resto a tu equipo con una nota.
Qué cuenta como excepción de soporte
Una excepción es cualquier momento en que un agente da a un cliente algo que la política escrita no contempla. Algunas son diminutas y otras cuestan dinero real, pero comparten una propiedad: dependen de un juicio, así que dos agentes pueden decidir distinto en el mismo ticket.
Estas son las que más veo en la cola, con la política que flexibilizan:
| Tipo de excepción | Ejemplo | La política que flexibiliza | Responsable habitual |
|---|---|---|---|
| Reembolso o devolución fuera de plazo | Reembolso el día 41 de un plazo de 30 días | Plazo de devolución | Líder de equipo |
| Exención de tarifa | Omitir una vez la tarifa de reposición o de demora | Tabla de tarifas | Agente, dentro de un presupuesto |
| Crédito de cortesía | Crédito de 10 $ tras una entrega tardía | Ninguna, es discrecional | Agente, dentro de un presupuesto |
| Excepción de garantía | Reemplazar un artículo recién fuera de garantía | Términos de garantía | Líder de equipo o responsable de producto |
| Excepción de venta final | Aceptar la devolución de un artículo en liquidación | Regla de venta final | Gerente |
| Crédito de servicio o SLA | Crédito por caída del servicio en un plan B2B | Términos del contrato | Account manager o finanzas |
Esa última columna importa más de lo que parece. La mayoría de los equipos tiene una matriz de aprobación de reembolsos o al menos un límite en dólares para reembolsos. Muy pocos tienen la misma claridad para el resto de la tabla, así que las exenciones de tarifas y los créditos de cortesía acaban decidiéndose por el estado de ánimo.
Por qué las excepciones sin gestionar cuestan más que las propias excepciones
El coste de una excepción no es solo el crédito de 10 $. Es lo que pasa cuando las excepciones son incoherentes, invisibles e imposibles de revisar.
Los clientes aprenden a buscar otro agente. Si la respuesta depende de quién contesta, lo inteligente es volver a preguntar. La gente lo dice abiertamente:
"I've learned to play customer service roulette.
Don't get the answer I'm looking for?
Hang up and call back."
Las excepciones se esconden dentro de otras categorías. Cuando los agentes no tienen una vía autorizada para conceder algo, encuentran una no autorizada. Un comentarista describió cómo funciona en bancos y emisores de tarjetas:
"If you're not yelling at them, you can often get what you want via some other method (which only they know) - like them reclassifying the problem to something else they have leeway for."
Ese ticket reclasificado aparece ahora en tus informes como algo que no era. Tu etiquetado de tickets es incorrecto y la excepción es invisible.
Las excepciones prometidas desaparecen. La peor versión es una excepción acordada pero nunca registrada. Un cliente en r/Comcast_Xfinity describió cómo acordó una solución por teléfono con soporte: "they said they would note this on my account. I reached back out after a week to confirm the notes on the account an there is no record of the solution offered" (cali1302, Reddit). Ahora el siguiente agente tiene que elegir entre cumplir una promesa que no puede ver o llamar mentiroso al cliente.
Las negativas pequeñas se convierten en grandes precedentes. El ejemplo más conocido es el caso del chatbot de Air Canada, en el que un reembolso por duelo rechazado acabó ante un tribunal. Un comentarista de Hacker News lo resumió: debería "should've been well within some second-tier customer service manager's discretionary refund budget. Instead they've got a precedent-setting ruling that makes the chatbot a huge liability" (ceejayoz, Hacker News).
El ciclo de gestión de excepciones en soporte
Toda excepción debería pasar por los mismos cinco pasos. El que la mayoría de los equipos se salta es la última flecha, de la revisión mensual de vuelta a la política escrita. Sin ella, concedes la misma excepción 40 veces al mes para siempre y nunca notas que debería haber sido una regla.
El resto de esta guía recorre el ciclo en orden: quién decide, cómo registrarlo, qué herramientas ya gestionan las excepciones puntuales, cómo revisar y cómo dar a tu agente de IA las mismas reglas que siguen tus personas.
Paso 1: Decide quién puede conceder qué
Empieza clasificando las excepciones con dos preguntas: de quién es la culpa y cuánto cuestan. Esas dos respuestas te dicen quién debe decidir mucho mejor que un único límite en dólares.
El recuadro inferior izquierdo es el que la gente hace mal. Si un envío llegó tarde por tu culpa y la solución cuesta menos que el tiempo de aprobarla, no debería ser una excepción. Un empleado de tienda defendió bien el argumento de la nómina:
"Especially on clothes that have a ridiculously high margin, it's costs more money in payroll wasting that time than just giving them a BOGO."
Para todo lo demás, da a cada rol un presupuesto de discrecionalidad por escrito. Los bancos ya funcionan así. Como dijo un comentarista, "most banks/credit cards let the first-level hit the 'refund one fee' button, and the higher up you get, the more discretion they have" (bombcar, Hacker News). El presupuesto debe decir tres cosas:
- Qué puede conceder el rol por sí solo. Por ejemplo: una exención de tarifa por cliente al año, créditos de cortesía de hasta 15 $, devoluciones hasta 7 días después del plazo.
- Qué no puede conceder en absoluto. Excepciones de venta final, créditos contractuales, cualquier cosa que implique una contracarga abierta.
- A quién pedir el resto. Una persona con nombre y una suplente, no «el canal de líderes». Si necesitas un repaso sobre el enrutamiento, mi guía del proceso de escalado de tickets lo cubre.
Una cosa más que dejar por escrito: para qué sirve la excepción. Sin eso, la discrecionalidad se inclina hacia quien más insiste. Un agente en r/talesfromcallcenters describió supervisores que "pick to be nice to rude people and give hard stops to really nice people" (Asha990, Reddit). Una línea como «los créditos de cortesía son para fallos de servicio de nuestra parte, no para premiar la insistencia» zanja muchas discusiones antes de que empiecen.
Paso 2: Registra cada excepción en un campo, no en una nota
Esta es la parte que casi toda guía de excepciones se salta. Una nota en el ticket («se concedió un reembolso de cortesía único») es mejor que nada, pero las notas no se pueden contar. Para revisar excepciones necesitas datos estructurados, y en un helpdesk eso significa campos de ticket personalizados.
El patrón que configuraría son cuatro campos, con tres de ellos visibles solo cuando el primero es Sí:
- Excepción concedida: un desplegable con No y Sí. Hazlo obligatorio al cerrar el ticket.
- Tipo de excepción: un desplegable con los tipos de la tabla anterior.
- Motivo de la excepción: un desplegable de motivos (retraso del transportista, artículo dañado, error nuestro, circunstancia del cliente), más una opción «otro».
- Valor y aprobador: un campo numérico para el coste y un desplegable con los nombres de los aprobadores.
Los desplegables ganan al texto libre por una razón sencilla. La propia documentación de Zendesk dice que los valores de los campos de texto "pueden ser inconsistentes o contener errores ortográficos", lo que los hace "menos útiles para informes" (Zendesk). El consejo de Freshdesk es el mismo: "favor dropdowns over text fields where possible" (Freshdesk).
Qué admite cada helpdesk
Todos los helpdesks principales pueden hacer alguna versión de esto, pero las restricciones por plan y los límites difieren mucho. Esto dice hoy la documentación:
| Helpdesk | Campos desplegables personalizados | Mostrar campos solo con «Sí» | Obligatorio al cerrar | Informe sobre el campo |
|---|---|---|---|---|
| Zendesk | Todos los planes, hasta 2.000 valores | Suite Growth y superiores | «Required to solve», todos los planes | Explore, Suite Professional y superiores |
| Freshdesk | Growth y superiores (no Free) | Campos dependientes Growth+, secciones dinámicas Pro+ | «Required when closing», Growth+ | Informes personalizados, Pro y superiores |
| Gorgias | Todos los planes, 25 campos activos | Todos los planes, hasta 70 condiciones | Todos los planes | Informe de campos de ticket, todos los planes, solo desplegables |
| HubSpot Service Hub | Todos los planes, hasta 5.000 opciones | Professional y superiores | Propiedades de etapa obligatorias en el pipeline | Informes personalizados, Professional y superiores |
| Help Scout | Plus y Pro, 10 campos por bandeja | No documentado | Obligatorio al responder, no al cerrar | Plus y Pro |
En Zendesk, la parte de «mostrar solo con Sí» es un campo condicional. El editor de condiciones también permite hacer obligatorios los campos dependientes según el estado, de modo que el Tipo de excepción solo es obligatorio cuando el ticket se resuelve:
Gorgias hace lo mismo con condiciones de campo, en todos los planes de Helpdesk:
Cuatro trampas en la letra pequeña
Son los detalles que rompen en silencio un registro de excepciones seis semanas después de configurarlo:
- El campo obligatorio de Zendesk tiene agujeros. El ajuste está en cada campo, pero la documentación de Zendesk dice que los campos obligatorios "pueden saltarse con disparadores y automatizaciones" y "también se saltan cuando un agente fusiona un ticket" (Zendesk). Su solución sugerida es una etiqueta
okay_to_closeque tu automatización de cierre espera. - Gorgias solo informa sobre desplegables. Su informe de campos de ticket "solo rastrea campos de ticket personalizados de tipo desplegable", así que los campos Número, Texto y Sí/No no aparecerán (Gorgias). Haz de Excepción concedida un desplegable, no un campo Sí/No. Gorgias también señala que su AI Agent "puede cerrar un ticket sin haber rellenado un campo de ticket obligatorio" (Gorgias).
- Help Scout comprueba al responder, no al cerrar. Los campos personalizados obligatorios deben rellenarse "al enviar una respuesta", y los datos del campo no se trasladan si la conversación pasa a otra bandeja (Help Scout).
- Borrar un campo borra tu historial. Freshdesk dice que eliminar un campo "lo oculta en Analytics", y Help Scout dice que borrar uno elimina sus datos "para siempre". Archiva los tipos de excepción antiguos en lugar de borrarlos.
Un extra para los equipos de Zendesk con Suite Professional o superior: el conjunto de datos Updates history de Explore puede seguir los cambios en los valores de los campos a lo largo del tiempo (Zendesk), lo que responde a «quién cambió esto a Sí y cuándo». Mi receta de Explore para campos personalizados recorre el informe.
Paso 3: Usa las herramientas que ya gestionan excepciones puntuales
Tu helpdesk registra la excepción. Pero la acción en sí suele ocurrir en otra herramienta: la app de devoluciones, el administrador de la tienda, el sistema de facturación. Varias de ellas tienen un mecanismo de excepción propio, y usarlo es mejor que un agente sorteando las reglas.
| Herramienta | Mecanismo de excepción puntual | Qué registra |
|---|---|---|
| Loop Returns | Añadir un pedido o email a la lista de permitidos para anular el plazo de devolución, la venta final o la lista de bloqueo | Entrada en la lista, exportable como CSV |
| Redo | Restablecer una devolución rechazada en el paso Policy Window o Final Sale Check | El historial de procesamiento de la devolución |
| Shopify | El personal crea la devolución en el administrador y edita tarifas por devolución | Los motivos de rechazo son solo internos |
| AfterShip Returns | Lista de permitidos por pedido, tipo de producto, email o etiqueta | Hasta 20 motivos de rechazo predefinidos |
| Stripe Billing | Ajuste del saldo de crédito con nota interna | Una «lista inmutable» de transacciones |
Loop es el modelo más claro. Su función Listings existe "para gestionar excepciones y restricciones de devolución", y añadir un pedido a la lista de permitidos "anula cualquier entrada de la lista de bloqueo, los productos etiquetados como Final Sale o el plazo de devolución del pedido" (Loop). Me gusta aún más la mejor práctica de Loop: permitir el pedido, enviar la devolución por el cliente y eliminar enseguida la entrada de la lista. Una excepción temporal que se limpia sola es justo lo que quieres. Loop también indica a los compradores fuera de plazo que "contact your support team directly for any exceptions" (Loop), así que estos tickets llegarán a tu cola lo planees o no.
Loop Workflows convierte las excepciones repetidas en reglas. Cuando la revisión del Paso 4 dice que una excepción debería ser política, Workflows puede aplicarla automáticamente, con acciones como Bypass final sale, Set return window y Set handling fee para "anular, añadir o eximir tarifas existentes" (Loop Workflows). He tratado más de esto en mi guía de automatización de devoluciones.
Las reglas de Shopify pueden recoger las excepciones que ya conoces. Las anulaciones del plazo de devolución te permiten dar 14 días a los artículos en liquidación y 90 a los muebles, y los artículos de venta final se describen como "excepciones a tus reglas de devolución predeterminadas" (Shopify). Lo que no pude encontrar en la documentación de Shopify es un interruptor para hacer elegible un pedido concreto cuando las reglas dicen que no. La vía documentada es una devolución creada por el personal en el administrador, donde las tarifas se pueden editar por devolución.
El saldo de crédito de Stripe es un crédito de cortesía con pista de auditoría integrada. Cada saldo de cliente "se calcula a partir de un libro mayor, una lista inmutable de transacciones de débito y crédito" (Stripe). Cada ajuste puede llevar una nota interna que el cliente nunca ve, y las entradas no se pueden borrar, solo revertir. Si los créditos de cortesía de tu producto SaaS viven en cualquier otro sitio, son más difíciles de auditar de lo necesario.
Paso 4: Revisa el registro y asciende las excepciones repetidas
Aquí es donde la gestión de excepciones se paga sola. Una vez al mes, extrae todos los tickets con Excepción concedida en Sí y agrúpalos por tipo y motivo. Para cada grupo te haces una sola pregunta: ¿es una excepción real o una regla no escrita?
Desde el lado del cliente, las excepciones sin revisar parecen aleatorias. Un comentarista, tras recibir alivio de un supervisor, escribió: "There's no particular rhyme or reason for why extraordinary relief is sometimes granted though, it seems completely random!" (gnicholas, Hacker News). Desde el lado del equipo es peor: gastas tiempo de aprobadores en decisiones que tomas igual cada vez.
Elige un tipo de excepción del mes pasado e introduce sus números aquí:
Los umbrales del widget (10 solicitudes al mes, 80 % concedidas) son mi punto de partida, no un estándar del sector. Ajústalos a tu volumen. Lo que importa es que la revisión termine en una de cuatro decisiones, y que cada decisión cambie algo:
- Convertirla en política. Actualiza la política escrita y el centro de ayuda, actualiza tus macros e informa a los agentes y a tu agente de IA el mismo día. Mi guía de gestión de cambios de políticas de soporte cubre el despliegue.
- Mantenerla como discrecionalidad del agente. Déjala dentro del presupuesto, pero sigue registrándola.
- Enviarla a un aprobador designado. Coste alto, o un patrón en el que quieres una segunda opinión.
- Redactar el no. Si rechazas una solicitud el 80 % de las veces, el 20 % de síes enseña a los clientes a seguir pidiendo. Como dijo un empleado de tienda, "They are getting something out of it, so it continues" (Cheshire1871, Reddit).
La revisión también alimenta otros dos ciclos. Los agentes cuya tasa de excepciones se aleja mucho de la media del equipo son una conversación de coaching, y ahí entran la calibración de QA de soporte y el feedback a agentes. Y un pico en un motivo, como los retrasos del transportista, es un problema de operaciones que el equipo de soporte paga en silencio. Señálalo junto con el resto de tu análisis de tickets de soporte.
Paso 5: Da a tu agente de IA reglas de excepción por escrito
Los agentes de IA hacen más urgente la gestión de excepciones, no menos. Una persona puede leer el ambiente y flexibilizar una regla en silencio. Un agente de IA seguirá las reglas que escribiste o improvisará, y ambos fallos acaban a la vista del público.
La primera preocupación es que los clientes convenzan a la IA de hacer excepciones:
"People will find out how to convince the LLM you do meet the requirements for a refund.
And if you check the requirements using something deterministic (last order was within last 2 weeks, customer has a high loyalty points score, they're subscribed to some premium service) then why do you need an agent at all?"
El fallo opuesto es igual de malo: un bot que no puede conceder una excepción y no deja que el cliente llegue a alguien que sí pueda. Un cliente describió un chat de soporte con IA que no dejaba de ofrecer cancelar al final del periodo de facturación: "I ask for human. It repeats. I ask for human again. It repeats. I disconnect" (kldg, Hacker News).
La respuesta a ambos es la misma que para las personas. Escribe las excepciones que la IA puede aplicar como reglas sencillas, ponle un límite firme en todo lo que mueva dinero y asegúrate de que cualquier otra solicitud de excepción llegue a una persona con contexto. Eso son guardarraíles de IA aplicados a la política, y la vía de escalado de IA es la mitad.
Las principales herramientas de IA para helpdesk ya admiten este enfoque:
| Herramienta de IA | Cómo escribes las reglas de excepción | Qué pasa con el resto |
|---|---|---|
| Zendesk AI agents | Generative procedures con contexto de política, como «Sin reembolsos en liquidación», y segmentos por tipo de cliente | Un paso «Escalate to» pasa a una persona o equipo y la IA se detiene |
| Gorgias AI Agent | Skills con límites, como «no te comprometas a un reembolso antes de que llegue el artículo devuelto» | Temas de traspaso que escribes en lenguaje natural, más disparadores integrados que "no se pueden desactivar" |
| eesel | Instrucciones en lenguaje natural con una plantilla de «excepciones y casos límite» | Escala con una nota interna; las acciones de dinero esperan aprobación |
El constructor de procedimientos de Zendesk es una buena imagen de lo que significa «dejar la excepción por escrito» para una IA. Describes la política en lenguaje natural y construye un mapa ramificado con una comprobación antes de que ocurra algo irreversible (Zendesk):
La documentación de Zendesk también es honesta sobre el límite: el contexto en un procedimiento no puede "garantizar el comportamiento exacto de la IA", y todo lo que deba ramificarse debería usar un bloque Check condition (Zendesk). Es el instinto correcto. La redacción guía a la IA, pero los límites firmes sobre dinero pertenecen a los ajustes de acciones.
Cómo escribiría las reglas de excepción con eesel
En eesel, las excepciones van a las instrucciones del agente en lenguaje natural, igual que informarías a alguien nuevo en el equipo. La documentación incluye una plantilla «Cover exceptions and edge cases» con líneas como «Reclamaciones por daños de menos de 50 $: omite la solicitud de fotos y aprueba el reembolso» y «Pedidos realizados en la última hora: las cancelaciones no necesitan aprobación», además de una regla de que los clientes con etiqueta VIP siempre se escalan (documentación de eesel). La plantilla de escalado cubre la otra mitad: dejar una nota interna que diga «qué quiere el cliente, qué has encontrado y qué habrías respondido», y asignarla a una persona.
También puedes corregir al agente como corregirías a una persona. Un administrador de soporte con quien he trabajado enseñó a su agente una regla que en realidad es una política de excepciones: que una solicitud de cancelación o reembolso con un problema sin resolver recibe primero resolución de problemas:
"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."
Un administrador de soporte que codifica una política de «resuelve antes de cancelar» en el agente
Para todo lo que cuesta dinero, los ajustes de acciones lo hacen cumplir. Cada acción tiene uno de tres ajustes por agente: Auto, Needs approval o Disabled (documentación de eesel). Puedes dejar una acción en Auto y aun así decirle al agente que pregunte primero en situaciones concretas, que es como una política de excepciones escrita se convierte en una barrera real. Cuando hace falta una aprobación, el aprobador ve la acción exacta y el importe, y las aprobaciones nunca se ejecutan solas tras un tiempo de espera.
La página Activity registra quién aprobó qué y cuándo, lo que sirve de registro de excepciones para todo lo que tocó la IA.
Errores comunes en la gestión de excepciones
Estos son los que arreglaría primero, más o menos en orden de lo que cuestan:
- Registrar excepciones en notas. Las notas no se pueden contar. Usa un desplegable obligatorio y, en Gorgias, asegúrate de que sea un desplegable y no un campo Sí/No.
- No tener presupuesto de discrecionalidad. Sin uno, cada agente inventa el suyo y los clientes aprenden a preguntar a un segundo agente. Escribe lo que cada rol puede conceder.
- Tratar las excepciones por culpa nuestra como favores. Un crédito por entrega tardía que concedes siempre debería ser una regla. Hacer que los clientes lo pidan solo genera tickets y perjudica el CSAT.
- No cerrar nunca el ciclo. Si la revisión mensual no cambia la política, el centro de ayuda o las macros, es solo un informe. Cada tipo de excepción debería terminar la revisión con una decisión.
- Dejar que la IA improvise. Un agente de IA sin reglas de excepción escritas dice que no a todo o que sí a lo equivocado. Dale reglas, un límite de dinero y una vía de escalado limpia.
- Borrar campos antiguos. Archiva los tipos de excepción retirados para que los datos del año pasado sigan apareciendo en los informes.
Gestiona las excepciones de soporte con eesel
Si tu equipo trabaja con Zendesk, Gorgias o Freshdesk, el compañero de IA para helpdesk de eesel es la vía más directa para que tus reglas de excepción se cumplan. Se une a tu cola existente, aprende de tus tickets anteriores, tu centro de ayuda y tus macros, y sigue las excepciones que escribes en lenguaje natural. Todo lo que cuesta dinero espera la aprobación de la persona adecuada, en el panel o en Slack, y todo lo que queda fuera de tus reglas va a tu equipo con una nota que explica qué quiere el cliente y qué ha encontrado.
Antes de que gestione una excepción real, puedes ejecutar una simulación con tus tickets pasados y comparar sus respuestas con lo que tu equipo envió de verdad. El precio es por ticket con puestos ilimitados, así que cada aprobador puede tener acceso, y puedes empezar con 100 créditos gratis y sin tarjeta. Prueba eesel.