Ejemplo práctico. Este es un ejemplo práctico ilustrativo, no un resultado de cliente: el equipo de soporte y sus cifras son supuestos. Muestra la recuperación de información del lado del agente, una herramienta que se sitúa detrás del agente de soporte, no de cara al cliente. El agente pregunta en lenguaje sencillo, recibe una respuesta con fuente citada, permanece en el ticket y envía la respuesta.
Imagina un equipo de atención al cliente de e-commerce mid-market que quiere mover el tiempo de primera respuesta en tickets complejos. Este post cuenta en qué consiste el diseño, qué medir y qué no hace. No informa de ningún resultado, porque no hay un cliente detrás.
El equipo es hipotético, y también cualquier cifra que cabría esperar aquí. El diseño se apoya en el trabajo de atención al cliente que describimos en /ai-for/customer-support. Una cosa más de entrada: es solo asistencia al agente. Ningún chatbot habla con un cliente en ningún momento.
#¿qué estaba frenando a los agentes?
Las respuestas existen. Encontrarlas no escala. Un ticket complejo significa que un agente abre el historial de Zendesk, un documento de producto y un PDF de política de envíos, y luego arma la respuesta a mano. Años de tickets pasados guardan el precedente, y nadie puede buscar en ese archivo en el tiempo que espera un cliente.
Así que la primera respuesta se quedaba en una cola mientras el agente buscaba. Esa espera es el número por el que le preguntan al responsable de soporte. El tiempo de primera respuesta, no el volumen de tickets.
¿puede la ia reducir el tiempo de primera respuesta en soporte sin un chatbot?
Sí, ese es el objetivo. Una herramienta interna de recuperación de información permite a los agentes hacer preguntas en lenguaje sencillo sobre tickets históricos, documentos de producto y PDF de políticas y recibir una respuesta con fuente citada. El agente sigue escribiendo y enviando la respuesta. Un equipo mediría el tiempo de primera respuesta en tickets complejos antes y después, sin bot de cara al cliente.
#¿en qué consiste el diseño?
Una herramienta interna de recuperación de información sobre tres fuentes: tickets históricos, los documentos de producto y los PDF de política de envíos. Un agente escribe una pregunta tal como se la haría a un compañero con experiencia. La respuesta vuelve con la fuente citada, para que el agente pueda comprobarla antes de que llegue a un cliente.
- Busca en todos los tickets pasados en una sola consulta, no pestaña por pestaña.
- Respuestas con fuente citada, para que el agente verifique el origen en lugar de confiar en una caja negra.
- Respuestas respaldadas en los PDF de política de envíos, donde realmente viven las reglas de los casos límite.
- El agente permanece en el ticket. La herramienta nunca responde a un cliente por su cuenta.
Formar al equipo de soporte es parte del diseño, no un traspaso al final. El KPI que hay que acordar es el tiempo de primera respuesta en tickets complejos, medido antes y después. Lo que mueva lo dirán tus propios datos, no este post.
#¿no es esto lo mismo que un bot de desvío de tickets?
No, y la diferencia es justo el punto. Una jugada de deflexión intenta bajar el volumen de tickets respondiendo directamente a los clientes. Este diseño apunta a otro número: el tiempo de primera respuesta, poniendo la recuperación de información detrás del agente. El cliente sigue hablando con una persona.
We are
Stennir construye ia que se sitúa detrás de tus agentes de soporte: recuperación de información, triaje, borrador y revisión, medida frente al tiempo de primera respuesta y la calidad de resolución.
We aren't
Stennir no es un proveedor de chatbots de cara al cliente y no vende el desvío de tickets como objetivo; el agente permanece en el ticket y tus clientes siguen hablando con personas.
Herramientas como Zendesk AI, intercom fin o las sugerencias de gorgias funcionan dentro de sus propios muros: tus macros, tus artículos de ayuda, tus respuestas guardadas. Este diseño añade recuperación de información sobre el resto. Los tickets históricos, los documentos de producto, los PDF de política de envíos, los runbooks. Ahí se esconden las respuestas de los tickets complejos.
Los KPI que movemos son el tiempo de primera respuesta y la calidad de resolución en tickets complejos, no la plantilla. Lo decimos el primer día y lo medimos.
#¿esto funcionaría para nuestro equipo de soporte?
La prueba de encaje es sencilla. ¿tus respuestas ya viven en lugares lentos de buscar? Años de tickets, una pila de PDF de políticas, documentos de producto que cambian. Si los agentes pierden minutos buscando antes de cada respuesta compleja, ese es el tiempo que la recuperación de información pretende devolver.
Este diseño forma parte de nuestro trabajo de consultoría de ia, con la formación del equipo de soporte integrada desde nuestro lado de formación en ia. Si quieres ver cómo encajan las piezas, el blog tiene más ejemplos prácticos como este.
Si tus agentes pierden tiempo buscando respuestas antes de cada respuesta compleja, esa es la demora a la que apunta este diseño. cuéntanos qué estás construyendo y te diremos si la recuperación de información es la palanca, o si no lo es.
