Cuando la IA da un precio equivocado

La respuesta corta

Una respuesta errónea en una llamada con IA rara vez es un misterio. Se cuela por una de estas cinco puertas: Fuente desactualizada, Fuente ausente, Pregunta mal oída, Error de consulta o Extralimitación. Cuatro de ellas tienen su origen fuera del modelo: Fuente desactualizada y Fuente ausente, en la fuente; Pregunta mal oída, en el reconocimiento de voz; y Error de consulta, en una consulta al sistema. Solo la Extralimitación nace en el propio agente, cuando ofrece más de lo que tiene permitido.

Por eso, prevenir es sobre todo un trabajo de fuentes y de atribuciones. Toda respuesta pasa por el mismo filtro: sale de una fuente aprobada, la fuente está al día, la respuesta queda dentro del límite de atribuciones y cada número, fecha o importe pasa por una confirmación, en la que el agente lo repite y el cliente lo confirma. Si una respuesta no supera alguna comprobación, la llamada va a la salida segura: el agente la pasa a una persona o deja programada una llamada de vuelta.

Aun así, algunas respuestas erróneas se colarán. Para esos casos hay un protocolo fijo: Contener, Identificar, Corregir, Registrar y Volver a probar. El alcance de una incidencia lo marca su ventana de exposición: desde el momento en que la respuesta errónea pasó a ser posible hasta el momento en que se corrigió. Esa ventana no depende del modelo, sino de la rapidez con la que su fuente recoge un cambio en el negocio, con la que se detecta un problema y con la que se contiene.

Todas las cifras de ejemplo de esta guía se han creado para ella: no son datos de DRING ni del sector.

Las cinco puertas por las que se cuela una respuesta errónea

Cada puerta tiene su propio control.

Solo la Extralimitación se cierra con el límite de atribuciones. Las otras cuatro se cierran trabajando en las fuentes, la confirmación y las consultas. Un error de Fuente ausente termina en una suposición del agente, pero empieza con un hueco en la fuente, y la primera comprobación del filtro de respuestas frena esa suposición. Para fallos de consulta como los tiempos de espera agotados, lea nuestro artículo sobre por qué la llamada a herramientas no es automatización.

Prevención: el filtro de respuestas

El filtro de respuestas es una secuencia fija de pasos que se aplica a cada respuesta. Antes de que el cliente la oiga, hay tres comprobaciones. ¿Está la respuesta en una fuente aprobada? ¿Está al día la fuente? ¿Queda la respuesta dentro del límite de atribuciones? Después, el agente repite cada número, fecha o importe para que el cliente lo confirme, antes de prometer o reservar nada. Un no en cualquiera de las tres comprobaciones lleva la llamada a la salida segura.

Fuentes aprobadas, cada una con su responsable y su fecha de efecto

Enumere todas las fuentes de las que el agente puede sacar sus respuestas: la lista de precios, la política de devoluciones, la base de conocimiento, la consulta de pedidos. Cada una es una fuente aprobada. Asigne a cada una un responsable de la fuente, la persona que la actualiza cuando cambia el negocio. Dé a cada versión una fecha de efecto: la fecha y la hora a partir de las cuales es válida.

Mantenga una sola fuente aprobada por tema. En la incidencia de ejemplo que se describe más abajo, la lista de precios de la web y la fuente del agente eran documentos distintos, y solo uno cambió a tiempo.

Comprobación 1: ¿está la respuesta en una fuente aprobada?

Si la respuesta no está en una fuente aprobada, el agente va a la salida segura. Una suposición con buena intención sigue siendo un error de Fuente ausente.

Comprobación 2: ¿está al día la fuente?

Introduzca cada nueva versión con su fecha de efecto antes de que llegue el cambio. Así, la fuente ya está al día cuando cambia el precio, no cuando alguien se acuerda de editarla. Si se acerca un cambio y la nueva versión no está lista, pase el tema a la salida segura hasta que lo esté.

Comprobación 3: ¿queda la respuesta dentro del límite de atribuciones?

El límite de atribuciones fija qué puede decir o hacer el agente sin una persona. Defínalo por tema, en tres niveles:

«Debe pasar a una persona» significa ir a la salida segura: una persona atiende la llamada en ese momento o confirma más tarde con una llamada de vuelta. Nuestra guía sobre cómo diseñar el traspaso a una persona explica qué debe recibir esa persona junto con la llamada.

Después, la confirmación: cada número, fecha e importe

Si la línea se oye mal, «sesenta» y «setenta» se confunden con facilidad. Por eso, el agente repite cada número, fecha o importe que dice o con el que actúa, y el cliente lo confirma antes de que se prometa o se reserve nada. La confirmación también detecta una Pregunta mal oída, porque el cliente oye a qué plan se refiere el agente. Un ejemplo, tras corregir la incidencia que se describe más abajo:

• Cliente: «¿Cuánto cuesta ahora el plan de protección?»
• Agente: «El plan de protección cuesta 14 € al mes. Le repito: catorce euros al mes. ¿Es ese el plan al que se refería?»
• Cliente: «Sí, catorce. Ese mismo».

Y el mismo agente, en su límite de atribuciones:

• Cliente: «La semana pasada en su web ponía doce. ¿Me lo puede dejar en doce?»
• Agente: «Desde esta llamada no puedo cambiar el precio, pero un compañero puede revisarlo. ¿Le paso con él ahora o prefiere que le devolvamos la llamada?»

Pruebe el filtro antes de publicar cada versión

Antes de publicar una versión, pruebe al menos un caso por puerta:

• Fuente desactualizada: un precio nuevo con su fecha de efecto. Las llamadas anteriores reciben el precio antiguo, y las posteriores, el precio vigente.
• Fuente ausente: preguntas que no cubre ninguna fuente aprobada. El agente llega a la salida segura.
• Pregunta mal oída: nombres de producto que suenan parecido, con ruido de fondo. La confirmación detecta el nombre equivocado.
• Error de consulta: una consulta que falla, no devuelve nada o devuelve otro pedido. El agente no se inventa un resultado y llega a la salida segura.
• Extralimitación: una petición de descuento o de reembolso. El agente pasa la llamada a una persona.

Nuestra guía para probar un agente de IA de voz antes de pasar a producción explica cómo montar la batería de pruebas completa.

Una incidencia de ejemplo: un cambio de precio que el agente no recogió

Ejemplo, no datos reales. Un comercio subió el precio de su plan de protección de 12 € a 14 € al mes, con fecha de efecto el lunes a las 09:00. La lista de precios de la web cambió a tiempo. La fuente aprobada del agente era un documento aparte, y nadie lo actualizó cuando cambió el precio. El miércoles a las 10:30 llegó la primera reclamación: a un cliente le habían dicho 12 € y le habían cobrado 14 €. El documento se corrigió el miércoles a las 14:00, y ese fue el paso Contener. La ventana de exposición fue del lunes a las 09:00 al miércoles a las 14:00: 53 horas.

El paso Contener llegó 3 horas y 30 minutos después de la primera reclamación, y durante esas horas los clientes podían seguir oyendo 12 €. Si las preguntas sobre el precio del plan hubieran pasado a una persona a los pocos minutos de la reclamación, eso se habría evitado mientras se corregía el documento.

Pasadas las 14:00, el equipo aplicó el paso Identificar. Buscó el plan en las transcripciones de la ventana y después leyó cada llamada que lo mencionaba:

Las tres últimas filas suman las 120 llamadas que mencionaron el plan: 46 más 61 más 13. Así que los clientes afectados son 46, no 900. Llamar a los 900 habría confundido a 854 clientes que nunca oyeron 12 €. Llamar solo al cliente que reclamó habría dejado a 45 clientes afectados con un precio erróneo. El jueves, el equipo llamó a los 46 clientes afectados para avisarles del precio vigente.

Dos cambios habrían reducido la ventana. Con el nuevo precio y su fecha de efecto introducidos en la fuente aprobada antes del lunes, la ventana habría sido de 0 horas. Con un control diario que comparara el precio dado en cada llamada con la lista de precios vigente, el primer control, el martes a las 08:00, habría señalado las llamadas en las que se dijo 12 €. Si la fuente se hubiera corregido entonces, la ventana habría sido de 23 horas en lugar de 53.

El protocolo de respuesta: cinco pasos

Cuando una respuesta errónea llega a los clientes, siga los mismos cinco pasos en el mismo orden. Contener va antes que Identificar: mientras se buscan las llamadas, los nuevos clientes pueden seguir oyendo la respuesta errónea.

Identificar significa encontrar a los clientes afectados, no a todos los que llamaron. Parta de la ventana de exposición, acote al tema y después lea las llamadas. Si su equipo responde con la misma fuente, revise también sus llamadas.

Corregir exige una política fijada antes de la primera incidencia. ¿Respeta el precio erróneo que se dio o explica cuál es el precio vigente? Es una decisión de política comercial. Tómela de antemano, déjela por escrito y entréguela a quienes hacen las llamadas de corrección. Determinar si un precio comunicado le obliga es una cuestión para sus asesores legales, y esta guía no la responde.

Registrar usa siempre los mismos campos del registro de incidencias, para que las incidencias se puedan comparar. La entrada de la incidencia de ejemplo:

Qué medir

Tres cifras muestran si el filtro y el protocolo funcionan:

• Tasa de respuestas erróneas en llamadas revisadas: llamadas revisadas con información incorrecta, divididas entre las llamadas revisadas. Corresponde a la parte de información incorrecta de la tasa de acciones erróneas que define nuestro artículo sobre criterios de éxito de un piloto de IA de voz, así que las dos siguen siendo comparables. Asigne a cada respuesta errónea su puerta: el recuento por puerta muestra dónde trabajar a continuación.
• Duración de la ventana de exposición: en horas, para cada incidencia. En el ejemplo, 53 horas: 49 horas y 30 minutos hasta la primera reclamación y, después, 3 horas y 30 minutos hasta la corrección.
• Tiempo desde la primera señal hasta Contener: desde la primera reclamación, el hallazgo de una revisión o la alerta de un control hasta el paso Contener. En el ejemplo, 3 horas y 30 minutos.

Ningún filtro puede garantizar una tasa de respuestas erróneas de cero, y un mes tranquilo no demuestra que el filtro funcione. Como explica el artículo sobre el piloto, no encontrar ninguna acción errónea en 300 llamadas revisadas sigue siendo compatible con una tasa real de hasta un 1 %, aproximadamente.

La revisión aleatoria también puede pasar por alto un tema muy acotado, o encontrarlo tarde. En el ejemplo, 46 de las 900 llamadas de la ventana se vieron afectadas, unas 5 de cada 100, todas sobre un mismo plan. Un control diario que compare el precio dado en cada llamada con la lista de precios vigente revisa todas las llamadas sobre ese tema, no una muestra.

Dónde encaja DRING

Los límites de seguridad, el traspaso a una persona, el análisis tras la llamada, las pruebas y la monitorización forman parte de la base común de todos los planes de DRING. En esta guía, el límite de atribuciones es un límite de seguridad, la salida segura se apoya en el traspaso a una persona y el control diario, en el análisis tras la llamada.

El análisis tras la llamada puede devolver campos adicionales que usted defina, a través de la API, su CRM, el panel y los informes. Uno de ellos puede ser el precio dado en cada llamada, lo que hace posible un control diario frente a la lista de precios vigente. Nuestra página de analítica de llamadas muestra el panel y los informes.

Cada agente de DRING pasa por entre 1.000 y 10.000 conversaciones simuladas, creadas para su empresa, antes de la primera llamada real. Las simulaciones ponen a prueba el filtro antes del lanzamiento. No sustituyen al protocolo de respuesta en las llamadas reales.

Si se acerca un cambio de precio o de política en su línea, solicite una llamada. Tenga a mano su lista de precios y el documento con el que responde su agente. Nuestro equipo puede revisarlos con usted a la luz de las cinco puertas.