El contrato entre tu agente de voz y tus sistemas

Una clínica puso en marcha un agente de voz para reservar citas, y la conversación era impecable: educado, claro y rápido. Hasta que un martes por la mañana, con la línea algo lenta, el sistema de reservas tardó en confirmar una operación y el agente, al no recibir respuesta, volvió a intentarlo. La cita quedó registrada dos veces, y esa misma mañana tres pacientes distintos recibieron la misma hora con el mismo doctor. Cuando los tres llegaron a la vez, la sala de espera se convirtió en un problema que ningún guion podía arreglar.

Lo interesante del caso es que nadie había escrito un guion malo. El fallo no estaba en la conversación sino en lo que hay debajo, en cómo el agente hablaba con el sistema de citas: la parte que se oye —la voz— funcionaba de maravilla, mientras que la parte que no se ve —el contrato con el backend— sencillamente no estaba definida.

De ahí sale la idea que cambia la forma de construir agentes de voz fiables: tu conversación es la interfaz; tus sistemas son el backend. La voz es la pantalla bonita, pero el trabajo de verdad ocurre cuando el agente reserva, cobra, da de alta o consulta, y si esa parte no está bien especificada, da exactamente igual lo bien que hable.

El modelo rellena los huecos que le dejes

Hay un principio que conviene interiorizar antes que ningún otro: un modelo de lenguaje inventa comportamiento para cualquier hueco que no le hayas definido. Si no le dices qué pasa cuando la hora ya está ocupada, se inventará una respuesta; si no le dices qué hacer cuando el sistema no contesta, improvisará una. Y la improvisación, con el dinero o la agenda de tus clientes de por medio, es exactamente lo que no quieres.

La solución no pasa por escribir un prompt más largo, sino por darle a cada herramienta que el agente puede usar un contrato claro: una especificación de qué hace, qué necesita, qué devuelve y qué ocurre cuando algo sale mal. Sin huecos, porque donde no hay hueco no queda nada que inventar.

Qué incluye un buen contrato de herramienta

Un contrato completo cubre ocho apartados, y saltarse cualquiera de ellos es dejar un hueco abierto.

1. Propósito en una frase

Lo primero es poder decir qué hace la herramienta en lenguaje llano: "reservar una cita en la agenda del doctor para una fecha y hora concretas". Si no cabe en una frase, lo más probable es que la herramienta esté haciendo demasiadas cosas a la vez y convenga partirla en dos.

2. Entradas con validación

Después vienen los datos que la herramienta necesita, cada uno con sus reglas: el teléfono tiene que tener un formato válido, el identificador del paciente tiene que existir en el sistema. Rechazar las peticiones mal formadas antes de ejecutarlas evita esos fallos silenciosos que aparecen semanas después y de los que nadie sabe explicar el origen. Y como muchos de esos datos son personales, conviene tener claro desde el propio contrato qué crea el agente y qué exige el RGPD.

3. Esquema de salida

El contrato también fija la estructura exacta de la respuesta cuando todo va bien: identificador de confirmación, fecha y hora, estado. El agente necesita saber con precisión qué recibe para poder decir la frase correcta al cliente, porque un "le confirmo su cita, el código es…" solo funciona si sabe de dónde sale el código.

4. Tiempo de espera y reintentos

Toda herramienta necesita un techo de tiempo: cuánto espera el agente antes de darla por fallida. Para un SMS de confirmación, por ejemplo, cinco segundos de espera y un único reintento son razonables, y si el reintento también falla, se escala a una devolución de llamada humana. Sin ese techo, el agente se queda esperando indefinidamente y la persona, al otro lado del teléfono, escuchando silencio.

5. Idempotencia (no negociable)

Este es el apartado que le faltaba a la clínica del principio. Toda herramienta que cambia algo —reservar, cobrar, dar de alta— tiene que impedir acciones duplicadas, y la forma de conseguirlo es generar un identificador único de la petición a partir de los datos de la llamada: si esa misma petición llega dos veces, la segunda devuelve el resultado de la primera en lugar de ejecutar la acción otra vez. La idempotencia no es opcional en nada que modifique datos, porque es lo que separa un inofensivo "el sistema tardó y reintentamos" de tres pacientes citados a la misma hora.

6. Mapa de errores con respuesta hablada

El contrato traduce cada error posible a una frase que el agente dice y a una acción siguiente, porque a un cliente no se le puede contestar "error 500". Si la hora pedida no está libre, el agente ofrece alternativas: "Esa hora no la tengo disponible, pero puedo ofrecerle el jueves a las 10 o el viernes a las 12, ¿le encaja alguna?". Si no encuentra la ficha del paciente, pide otro dato para localizarla: "No encuentro su ficha, ¿me confirma su fecha de nacimiento?". Si la hora se acaba de ocupar mientras hablaban, lo reconoce con naturalidad: "Justo me la han cogido; la siguiente libre es a las 10:30, ¿se la reservo?". Si el sistema de citas no responde, gana tiempo sin mentir: "Estoy teniendo problemas para acceder a la agenda, permítame un momento y lo intento de nuevo". Y si los datos de pago no son válidos, no insiste: transfiere a una persona para gestionar el cobro.

Cada situación de esa lista que dejes sin escribir es una frase que el modelo se inventará en directo, delante de tu cliente. Por eso cada error necesita su salida definida de antemano: a veces será reintentar, y a veces pasar la llamada a una persona con el contexto ya recogido.

7. Fallos parciales

Cuando una operación tiene varios pasos, hay que decidir de antemano qué se acepta que vaya bien y mal por separado. ¿Es válido que la cita se reserve pero el SMS de confirmación no llegue a salir? Casi siempre sí, resuelto con una degradación elegante —"le he reservado la cita; el mensaje de confirmación no ha salido, así que se lo envío por correo"— que siempre será mejor que cancelarlo todo porque falló el último eslabón.

8. Pruebas

El contrato no está terminado hasta que se ha probado entero: el camino feliz, cada uno de los errores del mapa, la idempotencia —llamar dos veces con el mismo identificador y comprobar que no aparece un duplicado—, el comportamiento cuando se agota el tiempo y las respuestas lentas. Lo que no has probado no lo tienes; lo supones, que es distinto.

Tres equilibrios que vas a tener que decidir

El primero es todo o nada frente a degradación elegante. Lo más limpio sería que, si falla un paso, se deshiciera todo lo anterior —la operación atómica de los libros de texto—, pero en la práctica deshacer cambios repartidos entre varios sistemas suele ser inviable. Casi siempre resulta mejor avisar del estado parcial, "cita reservada, mensaje no enviado", que dejar de dar servicio por perseguir una pureza que nadie va a agradecer.

El segundo es latencia frente a fiabilidad. Las herramientas que tardan —consultas complejas, comprobaciones de estado— gastan de tu presupuesto de un segundo, y ahí ayuda mucho lo asíncrono: lanzar la consulta, decir una frase puente del tipo "déjeme que lo compruebo…" y seguir hablando mientras llega la respuesta. Todo lo que se pueda precalcular o dejar en caché, mejor eso que consultarlo en tiempo real en mitad de la llamada.

Y el tercero es la seguridad del reintento frente a la experiencia. Reintentar protege de los fallos pasajeros, pero si el reintento también se demora, lo único que consigues es alargar el silencio. La política sana es un solo reintento con un tiempo claro y, si falla, escalar a una persona, en lugar de reintentar sin fin mientras el cliente espera preguntándose si sigue habiendo alguien al otro lado.

Prueba las herramientas antes que la conversación

Hay un orden que mucha gente invierte y acaba pagando caro: los contratos de las herramientas se prueban antes que la conversación. Si las herramientas fallan, probar la conversación no sirve de nada, porque nunca sabrás si el problema está en lo que el agente dice o en lo que el sistema hace por debajo. Primero verifica que cada herramienta se comporta como promete su contrato, incluidos todos los errores del mapa, y solo entonces dedícate a pulir cómo el agente habla del éxito y del fallo.

El contrato, punto por punto

Antes de dar por buena cualquier integración de tu agente, comprueba que su contrato responde a esto:

• ¿Está su propósito en una sola frase?
• ¿Están todas las entradas con sus reglas de validación?
• ¿Está definido el formato exacto de la respuesta correcta?
• ¿Tiene tiempo máximo de espera y política de reintento?
• Si cambia datos, ¿es idempotente? (esto, sí o sí)
• ¿Hay una frase hablada y una acción siguiente para cada error?
• ¿Está decidido qué pasa con los fallos parciales?
• ¿Se ha probado todo lo anterior, no solo el camino feliz?

La conversación es lo que el cliente oye, pero el contrato es lo que de verdad ocurre. Un agente que habla de maravilla sobre integraciones mal definidas no es un buen agente: es un problema con buena voz, y tarde o temprano se presenta en tu sala de espera.