Qué cubre realmente un flujo de aprobación en soporte
Un flujo de aprobación se activa siempre que alguien del equipo no tiene permiso para actuar solo. En soporte, eso suele significar tres tipos de solicitud:
- Dinero: reembolsos, créditos, gestos de buena voluntad y exención de tarifas por encima de lo que un agente puede conceder.
- Excepciones: todo lo que queda fuera de la política escrita, como una devolución fuera de plazo o una cancelación sin diagnóstico previo. Mi guía sobre gestión de excepciones de soporte explica cómo registrarlas.
- Trabajo de IA: respuestas y acciones redactadas por un agente de IA que una persona revisa antes de que salgan.
El caso del dinero es el más antiguo, y los agentes de primera línea lo describen igual en todos los sectores. Así planteó un trabajador de soporte de una operadora de telecomunicaciones una escalera real de créditos:
"Supervisors can approve up to about $300 in credits, then whatever is left gets rolled up to their managers. Floor support or SME'S have about the same limit as a supervisor, but they do not have access to things like the credit qué and a few other things."
Eso es un flujo de trabajo, aunque nadie lo haya escrito nunca: tiene límites por rol, una cola que solo algunos ven y, encima, un traspaso hacia arriba. Ponerlo por escrito es el primer paso, y debe ir en tus SOP de soporte, junto a la propia política.
La tarjeta de solicitud es donde fallan la mayoría de los flujos, así que empiezo por ahí. Un aprobador debería poder decidir solo con la tarjeta:
Si el gerente tiene que abrir el ticket, recorrer el hilo y además buscar el pedido, la aprobación tarda 15 minutos en lugar de 15 segundos. Desde el lado de la cola veo el coste cada semana: el cliente espera y el agente se convierte en mensajero de una decisión que no tomó.
Decide qué necesita aprobación antes de elegir una herramienta
La pregunta de la herramienta va en segundo lugar. Lo primero es decidir qué solicitudes necesitan una segunda persona, y para eso uso dos pruebas.
Prueba 1: ¿supera el límite del agente? Fija tramos de importe, asigna un aprobador a cada tramo y deja que los agentes resuelvan todo lo que quede por debajo del suyo sin preguntar. Aprobar importes minúsculos es puro desperdicio, como señaló un comentarista tras esperar por un reembolso de 37 centavos:
"This is why for the store it is better to have a smoother process for small price adjustments, it should not be necessary to wait 15 minutes for the store manager's approval on a 37 cent refund, nor should he even have to deal with it at all, that is a waste of his time and salary to be attending to something so minor."
Prueba 2: ¿se puede deshacer? Esta importa más cuando interviene la IA, porque un reembolso se puede revertir o dar de baja, pero una promesa en un correo no se puede retirar. Un hilo reciente sobre qué deberían hacer los agentes de IA sin aprobación llegó justo a esto:
"imo the cutoff isnt really about the action type, its about reversibility. if the agent does something you can undo in 30 seconds, let it run. if undoing it requires an apology email to a customer, that needs approval."
Junta las dos pruebas y obtienes una escalera. Las cifras de abajo son un ejemplo, no una referencia. Elige las tuyas a partir de tu propio historial de reembolsos:
La mayoría de los tickets deberían quedarse en el peldaño más bajo. Si la mitad de tus tickets de reembolso suben la escalera, los límites son demasiado bajos, y cada ascenso añade una espera para el cliente. La guía de la matriz de aprobación de reembolsos profundiza en cómo fijar los tramos. También hay una contrapartida razonable: algunas aprobaciones existen por un motivo, ya que el personal de primera línea no siempre sabe por qué un precio o una política están fijados así. El objetivo son menos aprobaciones y mejor dirigidas, no cero.
Dónde pone cada helpdesk las aprobaciones
Repasé los centros de ayuda de los helpdesks que más veo en los despliegues de eesel. Se dividen en tres grupos: herramientas con un objeto de aprobación real, herramientas pensadas para aprobaciones de TI y herramientas donde "aprobación" significa un borrador compartido más un permiso que se retira. Elige la tuya para ver la configuración, dónde deciden los aprobadores y el requisito de plan:
La versión corta: si necesitas un objeto de aprobación con estado, bloqueo de cierre y registro, Zendesk Professional, Freshservice y Jira Service Management son los únicos tres de esta lista que lo incluyen para tickets. Los demás llegan con proceso.
Zendesk: solicitudes de aprobación reales, desde Suite Professional
Zendesk cita los reembolsos como caso de uso de ejemplo: un agente recibe un ticket de reembolso, crea una solicitud de aprobación y la envía a un aprobador, como su jefe de equipo. Las reglas son estrictas de forma útil, según la documentación de aprobaciones de Zendesk:
- Hasta 5 aprobadores por solicitud. Con más de uno, todos deben aprobar, y un rechazo rechaza todo el bloque.
- El aprobador no puede ser el solicitante del ticket, el asignado ni quien creó la solicitud. La separación de funciones viene integrada.
- Los aprobadores de grupo solo funcionan con grupos de 30 miembros o menos, y cuenta la primera respuesta.
- Una solicitud pendiente impide cerrar el ticket hasta que todos respondan o se retire.
- Las solicitudes no se pueden editar tras crearlas. Se retiran y se vuelven a crear.
Conviene conocer las carencias antes de diseñar en torno a esto. No hay cadena secuencial: si necesitas jefe de equipo y luego gerente, creas una solicitud, esperas y creas la siguiente. Zendesk tampoco documenta ajuste de recordatorios, así que perseguir a un aprobador lento es una tarea manual de compartir el enlace. Un product manager de Zendesk también confirmó en los comentarios que aprobar respondiendo por correo queda descartado por motivos de cumplimiento.
La parte de Slack es el gran cambio de 2026. Desde mayo de 2026, los aprobadores individuales reciben un mensaje directo en Slack, y las aprobaciones de grupo abren un canal privado temporal con todos los miembros del grupo:
En octubre de 2026, Zendesk añadió comentarios de Slack que se sincronizan de vuelta al ticket como registro auditable. Sigues sin poder crear ni retirar una solicitud desde Slack. Para flujos automatizados, la receta de action flows puede pausarse hasta 30 días y ramificarse según Approved, Denied, Withdrawn o Expired, aunque Zendesk dice que las acciones de aprobación avanzadas requieren su programa de acceso anticipado.
Si estás en Suite Team, la alternativa son las side conversations, que son un hilo aparte y no un objeto de aprobar o denegar. Los requisitos de plan están en mi desglose de precios de Zendesk, y la guía de roles y permisos explica quién puede crear solicitudes.
Freshservice y Jira Service Management: cadenas de nivel TI
Ambas herramientas vienen del lado de TI y se nota: las aprobaciones son allí un objeto de primera clase con una lógica de varios pasos que los helpdesks de atención al cliente no tienen.
En Freshservice, los aprobadores se sientan en grupos y los grupos en una cadena. Cada grupo tiene una regla (Everyone, Anyone, Majority o First Responder), y la cadena también tiene una:
Dos funciones que desearía que copiaran las herramientas de atención al cliente. Freshservice puede recordar a los aprobadores cada N horas, y los aprobadores pueden delegar aprobaciones en un compañero con fechas de inicio y fin, lo que resuelve el problema de "el gerente está de vacaciones". Los precios van de 19 a 99 $ por agente al mes facturados anualmente, con los flujos de multiaprobación incluidos en todos los planes. Mi guía de precios de Freshservice tiene el detalle de planes.
Jira Service Management añade la aprobación como un paso en un estado del flujo de trabajo. Eliges el número de aprobadores, de dónde salen y de qué campos se excluyen, como el asignado o el informante. Los aprobadores actúan desde el centro de ayuda, el correo, Slack o Teams, y no necesitan licencia de JSM. El artículo sobre los precios de Jira Service Management explica por qué los 100 correos diarios del plan Free pueden afectar a las notificaciones de aprobación.
Si tu equipo de soporte ya comparte una cuenta de Freshworks o Atlassian con TI, puede valer la pena gestionar allí las aprobaciones de reembolsos. Si no, estas herramientas son mucha configuración para un equipo de soporte que solo quiere el sí de un gerente.
Front, Help Scout y Freshdesk: borradores y permisos
Estos tres no tienen botón de aprobar para tickets. Lo que sí tienen es un borrador que otra persona puede ver, además de una forma de impedir que ciertas personas envíen.
La política que sugiere el propio Front es "compartir siempre el borrador con un gerente para su aprobación en preguntas de precios", según su artículo sobre flujos de soporte. Los borradores compartidos vienen activados por defecto en las bandejas compartidas, pero los compañeros no reciben notificación a menos que los menciones con @:
Para convertirlo en regla firme, quitas el permiso "Send messages" a un grupo como los recién incorporados. Eso requiere Enterprise a 105 $ por puesto al mes y solo cubre los canales compartidos. Front también sugiere una tarea vinculada asignada a un gerente para las solicitudes de aprobación, que funciona en todos los planes y devuelve la conversación arriba cuando se resuelve la tarea. El detalle de planes está en mi artículo de precios de Front.
El enfoque documentado de Help Scout es más simple: los agentes nuevos guardan las respuestas como borradores y un gerente envía en su nombre desde el menú Send options. Los Light Users, que pueden dejar notas pero no responder, requieren Plus o Pro. El problema es que Help Scout afirma que no hay método para restringir conversaciones individuales, así que no puedes decir "este agente necesita aprobación solo en tickets de reembolso". Más en el desglose de precios de Help Scout.
Freshdesk documenta un flujo de aprobación, pero para artículos de la base de conocimiento en Enterprise, no para tickets. La autorización de tickets en Freshdesk es un proceso que construyes con roles y permisos y notas internas. La guía de aprobaciones de Freshdesk recorre esas opciones.
Gorgias y HubSpot: derechos por rol, aprobaciones en otra parte
Gorgias controla los reembolsos por rol y no por aprobación. Los usuarios Basic, Lead y Admin pueden lanzar un reembolso o cancelación de Shopify directamente desde el ticket, los usuarios Observer y Lite no, y no encontré un tope de importe por agente en las tablas de permisos de usuario. Lo más parecido a un paso de revisión es que las acciones de macro aparecen bajo el editor, donde el agente puede previsualizarlas, editarlas o quitarlas antes de enviar. Si necesitas a un gerente en el circuito en Gorgias, es un diseño de roles y una norma de equipo, que puedes respaldar con reglas de Gorgias que etiqueten los tickets de reembolso para que los revise un líder.
HubSpot tiene la interfaz de aprobación más pulida del grupo, con Approve, Reject y Request changes en el registro, pero es para negocios y presupuestos. Los tickets no están en la lista de objetos de aprobación de HubSpot. Las reglas del pipeline de tickets en Service Hub Professional pueden limitar quién edita tickets en ciertas etapas, pero los superadministradores, los flujos de trabajo y la API pueden saltárselas. Mi guía de IA para HubSpot Service Hub cubre lo que puede automatizar el lado de soporte.
Pon también el límite de importe en la capa de pago
Cuando tu helpdesk no puede imponer un límite, a veces sí puede el sistema de pagos. Stripe tiene la aprobación de reembolsos nativa más clara que encontré: una regla de aprobación de dos partes sobre "Refund is created", con un umbral de importe opcional. Un usuario no puede aprobar su propia solicitud, y las solicitudes no aprobadas caducan a los 14 días, según la documentación de aprobaciones de dos partes de Stripe.
El administrador en línea de Shopify tiene permisos de reembolso activados o desactivados sin límite de importe. Shopify POS es distinto: los reembolsos, descuentos y crédito de tienda pueden configurarse como "Approval required", y un gerente aprueba introduciendo su PIN. Los roles personalizados de POS son una función de POS Pro.
Aprobar respuestas y acciones de IA
Todo lo anterior supone que un agente humano pide y un humano aprueba. Con un agente de IA en la cola hay una segunda capa encima: la IA prepara el trabajo y una persona lo aprueba antes de que llegue al cliente o a tus sistemas. Un comentarista de Hacker News describió bien esta configuración mucho antes de que la mayoría de los proveedores la lanzaran:
"Now if AI agents are free to issue refunds or discounts by their own? Great, let's do that and suddenly most people are on board. But get ready for rampant abuse. Best solution would be an AI cyborg system where it readies a recommendation and a human swings by and approves or denies it without wasting time talking to people."
Eso se parece a lo que ahora lanzan los proveedores, cada uno a su manera:
- Zendesk auto assist (parte del complemento Copilot) sugiere acciones que un agente aprueba antes de que se ejecuten. Los administradores pueden marcar una acción como preaprobada, y la propia recomendación de Zendesk es que las acciones de escritura como los reembolsos sigan aprobadas por el agente. Mi guía de acciones de auto assist explica la configuración.
- Front Las reglas de Autopilot tienen un campo "Hold reply for review" que crea un borrador en lugar de enviar, y Front recomienda empezar ahí antes de la automatización completa.
- Help Scout Los AI Drafts están escritos para que los agentes los revisen y corrijan antes de enviar, en Plus y Pro.
- Gorgias AI Agent tiene un ajuste "Customer confirmation", pero fíjate en quién aprueba: confirma el comprador, no un gerente. Se activa automáticamente para acciones irreversibles como cancelar un pedido.
- Stripe aplica reglas de aprobación predeterminadas a los reembolsos creados con claves de API etiquetadas como de agente. Hasta la capa de pagos trata los reembolsos iniciados por IA como un actor aparte.
Este es el flujo al que apuntaría ante una solicitud de reembolso con IA de por medio:
Lo que la gente subestima es qué hacen realmente los revisores con los borradores de IA. En una prueba con tráfico real en una bandeja de Zendesk de comercio electrónico, la clasificación fue 93% precisa, pero los agentes enviaron solo el 12% de los borradores de IA tal cual. El patrón fue echar un vistazo y reescribir: un borrador de 8 a 15 frases recortado a 1 a 3 frases. Cerca del 65% de las reescrituras eran de longitud y tono, el tipo de cosa que se arregla entrenando con las respuestas enviadas del propio equipo, y solo alrededor del 5% eran errores factuales de la IA.
Dos lecciones desde el lado de la cola. Primero, un botón de sí o no no basta. Un cliente de Freshdesk me dijo que necesitaba editar los borradores de IA antes de enviar, porque aprobar tal cual o rechazar lo obligaba a copiar y pegar. Segundo, comprueba que la versión editada es la que se envía. Un compañero señaló una vez a un cliente de Freshdesk cuyos borradores editados salían como la versión original sin editar, lo que inutilizó el flujo hasta que se corrigió. Prueba ese camino antes de confiar en él.
Si estás comparando herramientas de copiloto de IA, estos dos detalles te dicen más que cualquier demo. La visión del propio Freshdesk sobre los borradores está en mi artículo sobre los borradores de respuesta con IA de Freshdesk.
Cómo gestiono la IA con aprobación previa en eesel
El compañero de IA de eesel está diseñado como incorporarías a una persona nueva. No recibe un interruptor de autonomía el primer día. Se gana la autonomía con trabajo revisado. En la práctica, se reduce a un ajuste por acción, elegido por agente, como describe la documentación de Actions and Approvals:
- Auto: se ejecuta solo, a menos que las instrucciones digan que se pregunte antes en una situación concreta.
- Needs approval: el agente prepara la acción, y una persona la aprueba o deniega antes de que ocurra nada.
- Disabled: el agente no puede usarla en absoluto.
Las acciones se agrupan en Read y Write, así que un punto de partida habitual es Read en Auto y la mayor parte de Write en Needs approval, con acciones de bajo riesgo como las notas internas en Auto:
Cuando una acción necesita aprobación, el aprobador ve el texto exacto de la respuesta o el importe del reembolso (o la etiqueta), y elige entre tres botones. Approve la ejecuta ahora. Always allow la ejecuta y pasa esa acción a Auto de ahí en adelante, solo para ese agente. Deny la omite y el agente continúa sin ella. Ese botón "Always allow" es el paso de graduación: apruebas reembolsos en un agente de tienda cinco veces, se ven bien y lo sueltas.
La aprobación llega a donde el aprobador ya trabaja, lo cual importa, porque el administrador de Zendesk que cité al principio no quería una pestaña más que vigilar. Las aprobaciones aparecen en el panel de eesel, como una tarjeta en el hilo de Slack donde empezó la ejecución, como un enlace en un correo o nota del helpdesk, y en el terminal:
Algunas reglas en las que me apoyo al configurar a un cliente nuevo:
- Las políticas de excepción se escriben en palabras sencillas. Puedes dejar las respuestas en Auto y escribir "pregunta antes de responder cualquier cosa sobre reembolsos", y el agente pregunta solo en esos casos. La documentación incluye plantillas para justo esto, como escalar cualquier reembolso de más de 100 $ u omitir la petición de fotos en reclamaciones por daños de menos de 50 $. Así enseñó un administrador de soporte a su agente la regla "diagnostica antes de cancelar": corrigiéndolo como a una persona nueva.
- Solo los Editors pueden aprobar. Deciden Owners y Editors. Los Viewers pueden ver las aprobaciones pero no actuar sobre ellas, y en Slack se asocia a quien hace clic con un Editor por correo electrónico.
- Nada se autoaprueba por tiempo de espera. Una acción pendiente sigue pendiente, y el agente deja una nota de que una persona hará el seguimiento. Cada decisión muestra quién decidió y cuándo en la página Activity.
- Nada se ejecuta hasta que creas una automatización. Conectar Zendesk no hace que el agente responda a nadie.
Para equipos que viven en un terminal, o que quieren que Claude Code, Codex o Cursor gestionen las aprobaciones, la CLI de eesel maneja el mismo agente que el panel. eesel approvals lista lo que está esperando, eesel approvals approve <id> --always aprueba y gradúa la acción de una vez, y eesel integrations zendesk actions imprime cada acción con su ajuste de aprobación. Las escrituras de la CLI siguen los mismos permisos, así que las escrituras de un Viewer siempre quedan retenidas para un Editor.
Antes de que nada de esto toque a un cliente, pido una simulación primero. Con un helpdesk conectado, el agente reproduce tickets pasados reales y compara sus respuestas con lo que envió el equipo. En el ejemplo de la documentación, coincidieron 17 de 20 tickets muestreados, con una puntuación por tema y una lista priorizada de correcciones. Eso te dice qué acciones están listas para Auto y cuáles deben quedarse detrás de una aprobación. Para el panorama general, consulta mis artículos sobre compañeros de IA y el agente de IA para helpdesk.
Errores comunes en los flujos de aprobación
- Aprobarlo todo. Si cada reembolso necesita un gerente, el gerente se convierte en la cola. Sube los límites de los agentes hasta que la mayoría de los tickets se queden en el peldaño más bajo.
- Una solicitud escueta. "¿Puedo reembolsar esto?" obliga al aprobador a reconstruir el ticket. Usa la tarjeta de cinco líneas: pedido, petición, línea de política, recomendación, plazo.
- Sin recordatorio ni aprobador suplente. No encontré un ajuste de recordatorio de aprobaciones en la documentación de Zendesk ni de Jira. Si tu herramienta tampoco lo tiene, fija un SLA interno para las aprobaciones y nombra un suplente.
- Sin registro escrito. Una aprobación en un mensaje directo es invisible para el siguiente agente. Deja la decisión en el ticket para que alimente tu registro de excepciones y los futuros cambios de política.
- Graduar la IA demasiado pronto. Pasa una acción a automática tras trabajo revisado, no tras una buena demo. La entrada sobre guardarraíles de IA cubre otros límites que conviene fijar, y la inyección de prompts es la razón por la que las acciones de reembolso merecen un cuidado extra.
- Olvidar adónde van las escalaciones. Aprobación y escalado son primos. Si se deniega una aprobación, el agente necesita un camino claro, que es lo que cubren la escalación con IA y la escalación entre equipos.
Cuando cambien las políticas, actualiza también las reglas de aprobación el mismo día. Mi guía de gestión de cambios de política explica cómo mantener sincronizados agentes, macros e instrucciones de IA, y el control de acceso de agentes de soporte explica cómo acotar lo que puede tocar cada puesto, incluido el puesto de la IA.
Prueba eesel para IA con aprobación previa en tu cola
Si usas Zendesk, Freshdesk, Gorgias u otro helpdesk al que se conecta eesel, el compañero de IA para helpdesk de eesel puede empezar como empezarías a cualquier persona nueva con los reembolsos: redacta la respuesta o el reembolso, y tú lo apruebas desde Slack, el ticket o el panel. Las acciones que siguen saliendo bien reciben "Always allow", y todo lo que cuesta dinero puede quedarse detrás de tu visto bueno el tiempo que quieras. La vista de informes muestra cuántas acciones se aprobaron, rechazaron o siguen esperando, por herramienta:
Las aprobaciones no cuestan nada extra. Un ticket o chat es 1 crédito sin importar cuántas respuestas y acciones requiera, con puestos ilimitados; el plan gratuito tiene 100 créditos y no pide tarjeta, y los planes de pago empiezan en 299 $ al mes por 500 créditos. Prueba eesel en tu propia cola con cada respuesta en Needs approval y comprueba cuántas habrías enviado tal cual.