Es común medir un chat automático por cuántas conversaciones no llegan al equipo. Esa cuenta mezcla dos cosas distintas: la consulta que se cerró porque el cliente obtuvo lo que buscaba y la que se cerró porque el cliente dejó de preguntar.
Ray parte de otra meta: cerrar la consulta en la misma conversación, con el conocimiento que publique la empresa, y pasarla a una persona solo cuando corresponda. Este artículo repasa qué significará eso en la práctica.
Derivar no es resolver
Una derivación no termina el trabajo: lo mueve. La conversación pasa a la bandeja, alguien la retoma desde el principio y el cliente espera. Por eso, en Ray, pasar a una persona será la excepción y no la salida por defecto.
Tampoco se trata de retener al cliente con respuestas vagas. Una respuesta solo contará si está respaldada por un artículo publicado y vigente, o por datos de la cuenta en solo lectura. Sin fuente, no hay respuesta.
Los tres casos en que entrará una persona
La regla es corta a propósito, para que el equipo sepa siempre por qué una conversación llegó a la bandeja:
- 1Un tema sensible de la lista. Datos personales, reclamos legales, pagos en disputa, cierre de cuenta, salud o seguridad, y los temas que agregue cada empresa.
- 2Un pedido explícito del cliente. Si el cliente pide hablar con alguien, el pedido se respetará siempre.
- 3Una pregunta sin fuente después de aclararla. Si Ray pidió el dato que faltaba y aun así no hay información publicada, lo dirá y ofrecerá pasar la consulta al equipo.
Fuera de esos tres casos, Ray intentará resolver.
Cómo se verá una respuesta que resuelve
Resolver no es enviar un enlace. El cliente recibirá la respuesta redactada, con los pasos numerados y los nombres exactos de menús y botones, tal como figuren en el artículo publicado:
Ejemplo ilustrativo: el cliente pregunta cómo pedir un reembolso por un producto dañado y Ray contesta con el plazo y tres pasos numerados; debajo, la pregunta de si la duda se resolvió.
Ejemplo ilustrativo con datos de muestra. Lumora es una marca ficticia.
La respuesta no mostrará la fuente al cliente. Terminará con una pregunta simple, “¿Esto resolvió la duda?”, y la conversación contará como resuelta solo si el cliente no indica que la duda continúa abierta.
Aclarar antes de derivar
Muchas consultas llegan incompletas: “no me llegó el pedido” no dice de qué pedido se trata. En lugar de pasar la conversación al equipo, Ray pedirá el dato que falta y seguirá con la consulta.
Lo que verá el equipo
El cliente recibirá una respuesta limpia; el equipo verá de dónde salió. En la consola, cada resolución quedará registrada con el artículo citado, su versión y los controles que pasó la respuesta. Si una persona entra al chat, verá ese mismo registro.
Ejemplo ilustrativo del registro en la consola: artículo citado y su versión, verificación y controles.
Ejemplo ilustrativo con datos de muestra.
Medir lo que se resuelve
Si la meta es resolver, la medida también. Convray define una resolución así:
Una conversación que Ray cerró con una respuesta respaldada por el conocimiento publicado, sin pasar a una persona, y en la que el cliente no indicó que la duda siguiera abierta.
Y cobrará solo por esas conversaciones: no por las que Ray intente, ni por las que pasen a una persona. Los planes de acceso anticipado están en la página de precios.
Por dónde empezar
Tres pasos que preparan el terreno antes de salir en vivo:
- Revisar los artículos más consultados y escribirlos paso a paso, con los nombres exactos de menús y botones.
- Definir los temas sensibles propios, además de los predeterminados.
- Armar los primeros casos de prueba con preguntas reales y lo que se espera de Ray.
Contenido de ejemplo. Este artículo ilustra el formato del blog. Autor, cargo, fecha y tiempo de lectura se completarán al publicar.
Ver a Ray con el conocimiento de la empresa
Una conversación corta con el equipo que construye Ray para revisar el caso de la empresa: las consultas frecuentes, el conocimiento existente, los temas sensibles y el plan de migración.