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 hace una pregunta en lenguaje sencillo y obtiene una respuesta con la fuente citada en una sola consulta. sin bot de cara al cliente. el agente permanece en el ticket y envía la respuesta.
entregamos una para un equipo de atención al cliente de una empresa de e-commerce mid-market. el tiempo de primera respuesta en tickets complejos cayó un 40 %. este post es la prueba: qué construimos, qué cambió y qué no.
el cliente está anonimizado. el 40 % es el resultado entregado en el proyecto, respaldado por el trabajo de atención al cliente que describimos en /ai-for/customer-support. una cosa más por adelantado: esto fue únicamente asistencia al agente. ningún chatbot habló con un cliente en ningún momento.
#¿qué estaba frenando a los agentes?
las respuestas existían. encontrarlas no escalaba. un ticket complejo significaba que un agente abría el historial de zendesk, un documento de producto y un pdf de política de envíos, y luego construía la respuesta a mano. cuatro años de tickets pasados contenían el precedente. nadie podía buscar en cuatro años de tickets en el tiempo que un cliente espera.
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 atención al cliente sin un chatbot?
sí. 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 obtener una única respuesta con la fuente citada. el agente sigue redactando y enviando la respuesta. para un equipo de atención al cliente de una empresa de e-commerce mid-market, esto redujo el tiempo de primera respuesta en tickets complejos un 40 %, sin bot de cara al cliente.
#¿qué entregamos realmente?
una herramienta interna de recuperación de información sobre tres fuentes: 4 años de 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 4 años de 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 fue parte del proyecto, no una entrega al final. el kpi que acordamos mover fue el tiempo de primera respuesta en tickets complejos. lo medimos antes y después. cayó un 40 %.
#¿no es esto lo mismo que un bot de desvío de tickets?
no, y la diferencia es todo el punto. una estrategia de desvío intenta reducir el volumen de tickets respondiendo directamente a los clientes. esto movió un número distinto. la métrica fue el tiempo de primera respuesta, conseguido al colocar la recuperación de información detrás del agente. el cliente siguió 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 gorgias suggestions funcionan dentro de sus propios límites: tus macros, tus artículos de ayuda, tus respuestas guardadas. nosotros construimos 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í es donde 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? cuatro 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 minuto que la recuperación de información devuelve.
este proyecto forma parte de nuestro trabajo de consultoría, con la formación del equipo de soporte integrada desde nuestro lado de formación. si quieres ver cómo encajan las piezas, el blog tiene más pruebas como esta.
si tus agentes buscan respuestas antes de cada respuesta compleja, ese es el 40 % que perseguimos aquí. cuéntanos qué estás construyendo y te diremos si la recuperación de información es la palanca, o si no lo es.