Qué es una matriz de aprobación de reembolsos en soporte (y por qué un solo límite no basta)
La mayoría de los equipos empieza con una sola regla: "los agentes pueden reembolsar hasta X $, lo que supere eso va a un gerente". Funciona hasta el primer reembolso de 20 $ para un cliente que ya ha pedido seis reembolsos este trimestre, o el primer reembolso de 400 $ que obviamente es culpa del almacén y debería salir en un minuto.
Una matriz lo arregla añadiendo un segundo eje. El importe fija el aprobador de partida, y las señales de riesgo lo suben o lo bajan. Estas son las dimensiones que incluiría, en el orden en que importan:
| Dimensión | Por qué importa | Mueve al aprobador |
|---|---|---|
| Importe del reembolso | El coste de un sí equivocado | Fija el tramo de partida |
| Dentro o fuera de la política | Plazo de devolución, venta final, prueba de daño | Fuera de la política sube un nivel |
| Historial de reembolsos del cliente | Los clientes que reembolsan con frecuencia son donde se esconde el abuso | Un cliente que reembolsa con frecuencia sube un nivel |
| Método de reembolso | El crédito de tienda y las sustituciones mantienen el dinero en el negocio | El crédito o la sustitución pueden bajar un nivel |
| Disputa o contracargo abierto | Reembolsar ahora puede pagar dos veces | Siempre va al responsable de disputas |
Esa última fila no es teórica. Stripe cobra una comisión por disputa de 15,00 $ por cada disputa que recibes, más otros 15,00 $ si la contestas, y la comisión por contracargo de PayPal es de 20,00 $ en EE. UU. Además, ninguno de los dos procesadores devuelve las comisiones de la transacción original cuando reembolsas: Stripe dice que las "comisiones de procesamiento de la transacción original no se devuelven" en su documentación de reembolsos.
Los dueños de tiendas Shopify aprenden la regla del contracargo a las malas:
"También conozco a dueños de tiendas que se han quemado al reembolsar y luego recibir un contracargo. Pierden 3 veces (el pedido, el reembolso y el contracargo). Un reembolso no garantiza cerrar ni evitar un contracargo. Si hay un contracargo en curso, no reembolses bajo ningún concepto."
Así se ve una matriz rellenada con umbrales de ejemplo. Los números son un punto de partida, no una recomendación para todos los negocios; una marca de joyería y una tienda de fundas de móvil de 12 $ necesitan tramos muy distintos.
Crea tu propia matriz de aprobación de reembolsos
Introduce tus propios límites y prueba un reembolso que hayas gestionado esta semana. La matriz se redibuja mientras escribes, y el panel de la derecha te dice quién debería aprobar el caso de prueba y por qué.
Cómo fijar los umbrales en dólares
El objetivo de un umbral no es detener los malos reembolsos. Es asegurarte de que el coste de comprobar sea menor que el coste de equivocarse. Cuando un gerente dedica diez minutos a un reembolso de 12 $, esa comprobación cuesta más que el reembolso, y el cliente esperó en línea por ello.
Los clientes lo notan. Un comentarista de Hacker News describió una empresa donde los representantes solo podían autorizar cantidades minúsculas:
"Los representantes de atención al cliente literalmente me decían que solo podían autorizar un reembolso de 1 $. 2 $ era "demasiado" y requería todo tipo de aprobación del gerente, y nunca había un gerente disponible..."
En el otro extremo está la regla de empoderamiento más citada en soporte, que sale cada vez que surge este debate:
"[...] Ritz Carlton ofrece, como es famoso, a cada empleado 2.000 $ de gasto discrecional para arreglar las cosas con un huésped sin burocracia. Contrata a buena gente, confía en la buena gente, empodera a la buena gente."
La mayoría de los equipos acaba en un punto intermedio, y los grandes centros de contacto tienden a apilar los niveles. Un comentarista de r/verizon describió sus límites así: "Los supervisores pueden aprobar hasta unos 300 $ en créditos, y lo que sobre se escala a sus gerentes" (Reddit).
Por escrito, una matriz puede ser sorprendentemente corta. Un comentarista de Hacker News esbozó una política de reembolsos completa en tres condiciones:
"Por ejemplo, cualquier cliente puede hacer sus primeras 2 devoluciones sin preguntas siempre que el valor sea inferior a 200 $, 1 reembolso completo si el valor es inferior a 50 $, y se aceptan todas las devoluciones inferiores a 200 $ siempre que la tasa global de devoluciones de su cuenta sea inferior al 15 %. Si no se cumple ninguna de estas condiciones, escalar."
Así elegiría yo los números de cada tramo:
- Tramo automático. Empieza en el importe de reembolso en el que ya apruebas casi todo. Extrae los reembolsos del último trimestre, busca el importe por debajo del cual los gerentes dijeron que sí más del 95 % de las veces y fija la línea automática justo por debajo. Mantén este tramo estrictamente dentro de la política.
- Tramo del agente. De uno a tres pedidos medios es un punto de llegada habitual. Los agentes deberían poder arreglar un pedido normal con problemas sin poner a nadie en espera.
- Tramo del líder de equipo. Aquí viven las decisiones "fuera de la política pero razonables". Los líderes conocen la política de devoluciones lo bastante bien como para flexibilizarla una vez.
- Tramos de gerente y finanzas. Reembolsos grandes, créditos B2B y todo lo que toque un contrato. Nombra a una persona por tramo, no a un grupo, para que nunca se quede en "alguien se ocupará".
Una comprobación más: asegúrate de que tus umbrales aguantan una semana movida. Si tu líder es el único aprobador de 250 a 1.000 $ y está ausente, todos esos reembolsos se atascan. Añade un suplente con nombre para cada tramo, igual que planificarías el desbordamiento de soporte.
Dónde puede (y dónde no puede) tu helpdesk aplicar la matriz
Aquí es donde se detienen la mayoría de las plantillas de matriz de reembolsos, y donde empieza el trabajo de verdad. Revisé la documentación de reembolsos y permisos de los helpdesks que más veo en la cola de eesel. Ninguno documenta un tope en dólares por agente. Lo que ofrecen es un interruptor:
| Helpdesk | Reembolso desde el ticket | Quién puede reembolsar | Tope en dólares por agente | Paso de aprobación |
|---|---|---|---|---|
| Zendesk | Total o parcial mediante la app de Shopify (todos los planes Suite) | No se configura por agente en la documentación | No documentado | Solicitudes de aprobación desde Suite Professional |
| Freshdesk | Total o parcial desde el widget de Shopify (Growth y superiores) | Un ajuste de administrador para todos los agentes | No documentado | El flujo de aprobación es solo para artículos de la base de conocimiento |
| Gorgias | Reembolsos y cancelaciones de Shopify desde macros y la barra lateral | Roles Basic, Lead y Admin; Observer y Lite no pueden | No documentado | Ninguno para personas |
| Gladly | Acción de reembolso en la tarjeta del pedido, solo el importe completo | "All Agents can perform all Actions" | No | Ninguno para personas |
| Kustomer | Importe completo, parcial o manual | Acciones de Shopify en el conjunto de permisos | No documentado | La IA pasa a una persona los reembolsos de alto valor |
| eDesk | Reembolsos por artículo, sin superar el original | Permiso de rol "Shopify Refunds" | No documentado | Los procedimientos de IA escalan por defecto |
Algunos detalles de esa tabla importan más de lo que parece.
El permiso de Shopify no sigue a los reembolsos hasta tu helpdesk. Shopify separa los reembolsos en permisos de personal distintos para el método de pago original y para el crédito de tienda, lo cual es estupendo. Pero su registro de cambios dice que el permiso de reembolso "se aplica en el panel de administración de Shopify y en la app móvil, pero no en otras apps de Shopify o de terceros que permiten a los usuarios reembolsar pedidos". Si un agente puede reembolsar desde Gorgias o Zendesk, el ajuste de roles del propio helpdesk es la única barrera.
Gladly da el botón a todos los agentes. Su documentación de acciones de Shopify dice "All Agents can perform all Actions" y el reembolso de la tarjeta del pedido siempre reembolsa el importe completo, envío incluido (Gladly). Si usas Gladly, tu matriz vive en la formación y el control de calidad, no en los ajustes.
eDesk añade un freno útil. Los reembolsos "no pueden ser superiores al importe original", y si el importe difiere del original, el agente debe elegir un motivo de discrepancia (Discrepancy Reason) (eDesk). Ese campo de motivo es el tipo de pista de auditoría que querría en todas partes.
Zendesk es lo más parecido a un verdadero objeto de aprobación. En Customer Service Suite Professional y superiores, un agente puede crear una solicitud de aprobación en un ticket, y el propio ejemplo de Zendesk es un reembolso que va al líder de equipo del agente. Los detalles son buenos para una matriz de reembolsos: hasta 5 aprobadores por solicitud, el aprobador no puede ser quien solicita ni quien tiene asignado el ticket, y una aprobación pendiente impide cerrar el ticket (Zendesk). Lo que no hace es elegir el aprobador por ti según el importe. El agente sigue leyendo la matriz y eligiendo.
Así que, en la práctica, la parte del helpdesk de la matriz se reduce a tres ajustes: quién tiene siquiera el permiso de reembolso (mira mis notas sobre el control de acceso de los agentes de soporte), una macro o formulario que obligue a los agentes a registrar el motivo, y una etiqueta de ticket sobre la que puedas informar.
Zendesk añade automáticamente una etiqueta shopify_refund cuando un agente reembolsa desde la app de Shopify (Zendesk), lo que facilita la revisión trimestral.
Aplica el límite en dólares en la capa de pagos
Si necesitas un límite duro que una persona no pueda saltarse con un clic, tiene que vivir donde se mueve el dinero. Esto es lo que cada herramienta de pagos o comercio puede aplicar realmente:
| Herramienta | Quién puede reembolsar | ¿Se aplica un umbral de importe? | Aprobación integrada | Plazo de reembolso |
|---|---|---|---|---|
| Stripe | Roles como Refund Analyst, Support Associate, Support Specialist | Sí, una condición de importe en "Refund is created" (vista previa pública) | Exigir aprobación o bloquear; las solicitudes caducan a los 14 días | Límite de tarjeta no indicado en la documentación de reembolsos |
| PayPal | Hasta 200 usuarios secundarios con permisos fijados por el titular | No documentado | No documentado | 180 días, total o parcial |
| Administración de Shopify | Permisos separados para el pago original y el crédito de tienda | No, solo activado o desactivado | El personal aprueba o rechaza solicitudes de devolución; POS Pro puede exigir un PIN de gerente | El comerciante fija 14, 30, 90 o días personalizados |
| Loop Returns | Equipo del comerciante | Sí, reglas por valor de la devolución o del pedido | Acción Manual Review | Fijado por el comerciante |
Stripe es el que destaca. Sus aprobaciones de dos partes permiten a un administrador añadir una regla sobre "Refund is created" con una condición de importe, de modo que la aprobación se activa "solo si el importe supera un umbral". El control es o bien Require approval, que pausa el reembolso hasta que un revisor lo apruebe, o bien Block. "A user can't approve their own request", las solicitudes que llevan 14 días sin resolverse caducan, y solo puede aplicarse una regla activa a una acción dada, por lo que expresas los niveles mediante condiciones combinadas en lugar de una escalera de reglas. Stripe también incluye reglas de aprobación por defecto para reembolsos creados con claves de API etiquetadas como de agente, lo que te dice cómo piensan las empresas de pagos sobre la IA y el dinero.
Shopify es un interruptor, no un dial. Los permisos de la tienda listan "Refund to original payment method" y "Refund to store credit" como permisos separados, sin límite de importe en ninguna de las dos descripciones. Esa separación sigue siendo útil: puedes dejar que los agentes nuevos reembolsen solo como crédito de tienda. Ten en cuenta también que "you can't cancel or reverse a refund after you initiate a refund" en Shopify (Shopify), así que un sí equivocado es permanente.
Las apps de devoluciones pueden encargarse del enrutamiento por valor. Los flujos de trabajo de Loop pueden enrutar por total de la devolución, total del pedido, etiqueta del cliente o motivo de la devolución, y enviar una solicitud a Manual Review. El propio ejemplo de Loop envía las devoluciones de más de 300 $ a revisión manual para que el almacén inspeccione primero los artículos de alto valor.
Si las devoluciones generan la mayoría de tus reembolsos, aquí es donde debe ir la parte alta de tu matriz, y combina bien con las herramientas de devoluciones que ya he comentado. Mi guía de automatización de devoluciones cubre el resto de ese flujo.
Evita que las aprobaciones se conviertan en el cuello de botella
Una matriz de aprobación falla en silencio cuando las aprobaciones se quedan paradas. El cliente no ve tu organigrama, ve una espera:
"Tuve que consultar con mi supervisor para obtener la aprobación del reembolso, porque su pedido completo estaba un poco por encima de lo que puedo aprobar yo mismo. Dije que lo pondría en espera un momento. El supervisor necesitó un minuto, así que estuve esperando."
Y cuando el umbral está demasiado bajo, los aprobadores también se resienten:
"[...] no debería ser necesario esperar 15 minutos la aprobación del gerente de la tienda para un reembolso de 37 centavos, ni siquiera debería tener que ocuparse de ello, es una pérdida de su tiempo y su salario atender algo tan menor."
Esto es lo que mantiene la matriz ágil:
- Pon la aprobación donde el aprobador ya trabaja. Zendesk añadió las aprobaciones en Slack en mayo de 2026, y ahora los aprobadores también pueden dejar comentarios allí. Una aprobación que vive en una bandeja que nadie abre es un reembolso que nunca sale.
- Da a cada tramo un objetivo de tiempo de aprobación. Zendesk no documenta ningún recordatorio nativo para las solicitudes de aprobación, así que configura una vista o automatización que marque las aprobaciones pendientes pasadas unas horas.
- Escribe el contexto una sola vez. El aprobador debería ver el pedido, el importe, la línea de política que se incumple y la recomendación del agente. Zendesk limita la descripción de la solicitud a 2.500 caracteres, que es más que suficiente si usas una plantilla.
- Nunca dejes que quien solicita apruebe. Zendesk impide que el asignado apruebe, Stripe impide la autoaprobación y HubSpot hace lo mismo con las cotizaciones. Si tu herramienta no lo hace, conviértelo en una regla.
- Decide qué significa la caducidad. Stripe caduca las solicitudes a los 14 días. Decide de antemano si una aprobación caducada es un no o sube un nivel, y dile al cliente cuál de las dos fue.
Dale a tu agente de IA una fila en la matriz
Esta es la parte a la que la mayoría de las políticas de reembolso aún no ha llegado, incluso en equipos que ya usan IA para solicitudes de reembolso. Si un agente de IA puede tocar pedidos, necesita su propio tramo en la matriz, y ese tramo debería ser más estrecho que el de un empleado nuevo.
El mejor planteamiento que he leído sobre esto salió de un hilo sobre qué dejan hacer las personas a los agentes de IA sin aprobación:
"la línea que acabé trazando no era lo arriesgada que fuera la acción, sino si puedo deshacerla. el dinero resultó fácil, lo reembolsas. [...] un mal reembolso es una mala tarde. un mal mensaje se queda en la bandeja de alguien para siempre y no hay botón de deshacer para eso."
Estoy de acuerdo con la prueba de reversibilidad, con una salvedad: en Shopify y PayPal, un reembolso enviado no se puede cancelar. Así que, para los reembolsos, "deshacer" significa "asumir el coste", y para eso sirven precisamente los tramos en dólares. Otro comentarista de Hacker News describió la configuración que acaban queriendo la mayoría de los equipos: una IA que "prepara una recomendación y una persona pasa a aprobarla o rechazarla" (lubujackson, Hacker News).
Cada decisión de reembolso de la IA debería terminar en uno de tres lugares. Es un diseño de human-in-the-loop aplicado al dinero, y es la salvaguarda de IA que fijaría antes que cualquier otra:
Los proveedores han convergido en este patrón, con palancas distintas:
| Herramienta de IA | Cómo se ejecutan los reembolsos | Dónde está la salvaguarda |
|---|---|---|
| Zendesk Copilot auto assist | Cancela y reembolsa pedidos de Shopify después de que un agente lo acepte | Zendesk dice que las acciones de reembolso "should be marked as agent-approved" |
| Gorgias AI Agent | Reembolsos como parte de cancelar, eliminar un artículo o sustituir un artículo | Condiciones de acción sobre el total del pedido; confirmación del cliente activada por defecto en acciones irreversibles |
| Richpanel | Una herramienta Refund Order | "Require approval" por herramienta; reembolsos limitados por el total del pedido y la política |
| Kustomer AI Agent | Reembolsos y devoluciones | Por encima de un valor definido, una persona aprueba y luego la IA termina la conversación |
| Gladly AI | Reembolsos totales o parciales | El importe se muestra y se confirma antes con el cliente |
| eDesk AI Agent | Resultado "Approve Refund" en los procedimientos | El resultado por defecto es escalar a una persona |
Dos de ellos merecen una mirada más de cerca. La documentación de acciones de Zendesk advierte de que las acciones preaprobadas "may be executed in a different order than specified", que es la razón documentada para no preaprobar reembolsos. Y la confirmación del cliente de Gorgias es una confirmación del comprador, no de un gerente. Evita cancelaciones accidentales, pero no es una aprobación interna. Además, las acciones de Gorgias AI Agent no están incluidas en el plan Starter, según la página de precios de Gorgias, y cada interacción automatizada cuesta de 0,85 a 1,00 $ según el plan. Mi desglose de los precios de Gorgias AI Agent tiene la tabla completa.
La versión de Kustomer es la que copiaría para el traspaso de vuelta: la persona aprueba el reembolso, deja una nota para la IA, y la IA informa al cliente y cierra la conversación.
Cómo escribiría el tramo de IA con eesel
En eesel, cada acción que puede realizar el compañero de IA tiene una de tres configuraciones por agente: Auto, Needs approval o Disabled (documentación de eesel). La conexión con Shopify incluye Refund Order y Cancel Order como acciones de escritura, y nada cambia en una tienda hasta que creas una automatización y las activas (integración con Shopify).
La propia matriz va en las instrucciones del agente, en lenguaje sencillo. La documentación incluye una plantilla de escalado que contiene "The conversation involves a refund over $100", y una plantilla de excepciones con líneas como "Damage claims under $50: skip the photo request, approve the refund" (documentación de instrucciones). Un administrador de soporte con el que he trabajado enseñó a su agente una regla que está por encima de cualquier tramo en dólares:
"Tengo una regla en CS por la que no atendemos una solicitud de cancelación o reembolso cuando tiene una incidencia asociada."
Un administrador de soporte que codifica en el agente una política de "resolver el problema antes de cancelar"
Cuando un reembolso necesita un sí, el aprobador recibe una tarjeta con la acción exacta y el importe, con Approve, Always allow o Deny. Las aprobaciones nunca se ejecutan solas tras un tiempo de espera, y la página Activity registra quién decidió y cuándo.
Si prefieres aprobar desde Slack, la misma solicitud aparece en el hilo con los botones Approve, Deny y Review, lo que mantiene la aprobación dentro del día del aprobador. Más sobre esto en mi guía de escalado con IA.
Errores comunes de la matriz de reembolsos
Estos son los que más veo en la cola, aproximadamente ordenados por lo que cuestan:
- Una sola línea en dólares, sin columna de riesgo. Un único límite aprueba el reembolso de 20 $ de tu cliente que más reembolsa y bloquea el de 300 $ que obviamente es culpa tuya. Ambos duelen: uno hace perder dinero, el otro empuja a un buen cliente hacia la fuga de clientes. Añade al menos las columnas de fuera de la política y de cliente que reembolsa con frecuencia.
- Dar por hecho que el helpdesk lo aplica. A menos que hayas configurado las aprobaciones de Stripe o un ajuste de acción de la IA, tus límites son una política, no un control. Audita los reembolsos por agente cada mes con la etiqueta o el informe de reembolsos.
- Aprobadores que son grupos. "El canal de líderes" no es un aprobador. Nombra a una persona y a un suplente para cada tramo, y déjalo escrito en tu proceso de escalado.
- Tratar el crédito de tienda como efectivo. El crédito de tienda mantiene el dinero en el negocio. Dale un tramo más laxo y los agentes lo ofrecerán más, que a menudo es lo que el cliente quería de todos modos. Mis macros de reembolso muestran cómo redactar esa oferta.
- Sin responsable de contracargos. Un reembolso emitido después de que se abra una disputa puede pagar dos veces y aun así cuesta la comisión por disputa. Dirige los contracargos a una persona, siempre.
- No revisar nunca los tramos. Si tu líder de equipo aprobó el 98 % de su tramo el trimestre pasado, el tramo es demasiado bajo. Trata la matriz como una política de soporte viva y actualiza a los agentes y a la IA el mismo día.
Ejecuta tu matriz de reembolsos con eesel
Si tus reembolsos llegan a través de Zendesk, Freshdesk o Gorgias con una tienda Shopify detrás, el compañero de IA para helpdesk de eesel es la forma más fácil de hacer real la matriz. Se incorpora a tu cola existente, aprende de tus tickets anteriores, tu centro de ayuda y tus macros, y ejecuta los reembolsos de tu tramo automático. Todo lo que supere un umbral que escribas en lenguaje sencillo espera la aprobación de la persona adecuada, en el panel o en Slack, y todo lo que quede fuera de la política va a tu equipo con una nota que explica lo que encontró.
Antes de tocar un reembolso real, puedes ejecutar una simulación sobre tus tickets pasados y ver cómo habría gestionado tus solicitudes de reembolso en comparación con lo que hizo realmente tu equipo. El precio es por ticket gestionado con puestos ilimitados, así que cada aprobador de tu matriz puede tener acceso sin coste adicional.
Empieza con 100 créditos gratis, conecta tu tienda Shopify y tu helpdesk, y pon Refund Order en Needs approval desde el primer día. Prueba eesel.