Cuando un ticket de soporte es también una transacción
Las preguntas de los comercios casi siempre giran en torno a una transacción, un pago o una factura concretos. En un helpdesk genérico que funciona fuera del panel de pagos, un ticket empieza como una conversación en blanco, y el agente tiene que copiar referencias de transacción, IDs de comercio y fechas entre dos sistemas antes de poder siquiera analizar lo que pregunta el comercio.
Abrir un ticket donde ya está el registro
El comercio puede, en cambio, abrir un ticket directamente desde la transacción, la factura o el wallet que está consultando, de forma que la referencia viaja con la conversación en lugar de tener que pegarse en ella. El operador que responde el ticket está viendo el registro real, no una captura de pantalla ni un identificador copiado.
Una sola cola, los mismos permisos
Los gestores de cada tenant trabajan la cola de soporte dentro de su propio panel, bajo el mismo control de acceso basado en roles que rige el resto de su acceso. El personal de soporte no necesita permisos más amplios solo para responder una pregunta, y no hay un segundo inicio de sesión, ni una configuración SSO separada, ni un segundo lugar donde se almacenen los datos personales del comercio.
Almacenamiento compartido en lugar de un segundo sistema de archivos
Los archivos adjuntos, como recibos y justificantes, utilizan el mismo almacenamiento documental y las mismas rutas de descarga que las pruebas de disputas. No hace falta duplicar nada en un segundo sistema, y no se pierde nada entre un adjunto y el registro que debía respaldar.
Qué cambia esto en el día a día
Como los tickets están acotados por tenant y se encolan dentro de la propia plataforma, el reporte de tiempos de respuesta es una característica de la plataforma y no algo que se recompone después a partir de dos sistemas. Y como los tickets se abren desde el contexto, desaparece toda una categoría de error: la referencia de transacción equivocada copiada en la conversación equivocada.
Una capa opcional, y el lugar de las disputas
Además de la bandeja de soporte, un módulo independiente puede triar los tickets entrantes y redactar respuestas sugeridas basadas en el mismo contexto de transacción y comercio que ya ve el operador: el operador sigue editando y enviando, y nada llega al comercio de forma automática. Esto convive con el propio flujo de disputas de la plataforma, donde un comercio puede abrir una disputa sobre un pago o un pago saliente indicando un motivo y hasta cinco archivos de prueba, y un gestor la resuelve con los saldos revertidos y reaplicados automáticamente, manteniendo la conversación de soporte y la disputa a la que pueda dar lugar en el mismo sitio.
