Un agente puede tener tus políticas enteras bien indexadas y aun así no poder contestar la pregunta más repetida de cualquier bandeja de entrada: dónde está mi pedido.
No es un fallo de la búsqueda. Son dos preguntas de naturaleza distinta y se contestan en sitios distintos. Una se contesta con lo que tu negocio tiene escrito. La otra sólo se contesta mirando el sistema donde vive la respuesta, ahora mismo.
Conocimiento y estado
- ConocimientoLo que el negocio escribió: plazos, condiciones, qué cubre la garantía. Cambia sólo cuando alguien lo cambia, vale igual para todos tus clientes, y se puede guardar en un índice y buscar. Es lo que resuelve un RAG.
- EstadoLo que está pasando con una persona concreta: su pedido, su saldo, su reserva, su devolución. Cambia solo, sin que nadie lo toque, cada cliente tiene el suyo, y dentro de cinco minutos es otro.
Un saldo indexado es un saldo de ayer.
Esto parece obvio escrito, y es el error más común que vemos en agentes ya montados: alguien exporta un listado de pedidos, lo sube como documento, y durante un mes el agente contesta con el estado que tenían esos pedidos el día que se exportó. Nada falla. Nadie se entera.
Guardarlo tampoco sirve
La tentación siguiente es copiar el dato cuando se consulta y reutilizarlo un rato, que es lo que haría cualquiera optimizando una web. En atención al cliente eso tiene un nombre peor: un dato leído hace cuarenta minutos no es un hecho, es un recuerdo. Y confirmarle a alguien un saldo de hace cuarenta minutos es exactamente el error que todo esto existe para evitar.
Por eso en Qopper lo que se lee de tus sistemas vive lo que vive el turno. No es una caché ni una copia de tu base de datos: se pregunta, se usa para responder, y se olvida.
Qué es, por dentro, conectar un sistema
Mucha menos cosa de la que suena. Para que un agente pueda consultar algo tuyo hacen falta cuatro piezas, y las cuatro las tienes ya si tienes una API.
- 1Una dirección. A qué se llama. La de tu propia API, la que ya usa tu web o tu aplicación.
- 2Una credencial. Cómo se demuestra quién llama. Un token, una clave en una cabecera, lo que ya tengas montado.
- 3Los campos que el modelo rellena. Número de pedido, documento de identidad, correo. Es lo único que el agente tiene que sacar de la conversación.
- 4Una descripción. Cuándo usar esto. Y no es documentación: la lee el modelo, no una persona, y es lo que decide si la usa en el momento correcto o no la usa nunca.
Lo interesante empieza cuando falla
Que la consulta funcione es el caso fácil y es el que se enseña en las demos. Lo que separa un agente que puedes poner delante de tus clientes de uno que no es qué pasa cuando tu sistema tarda, devuelve un error, o devuelve el dato a medias.
- Tarda más de la cuentaSe deja de esperar a los veinte segundos. Sin ese corte, la conversación se queda colgada hasta que el servidor la mata, y el cliente no recibe ni respuesta, ni disculpa, ni traspaso a una persona.
- Devuelve un errorEl agente no puede decir “401”. Lo que recibe no es un código, es una frase: no pudiste consultarlo ahora, dilo y ofrece que lo revise una persona. Un código de estado leído en voz alta es lo que convierte un fallo técnico en una conversación ridícula.
- Responde, pero falta un campoEl peor de los tres, porque parece que todo fue bien. Si el transportador aún no ha puesto fecha de entrega, el modelo no ve un hueco: ve un objeto sin esa línea y lo completa con lo que suena razonable. Así es como un agente acaba diciendo “llega el jueves” sin que nadie haya dicho nunca un jueves.
La respuesta a lo tercero es nombrar lo que falta. “No consta la fecha de entrega” es un dato tan útil como la fecha, y es el único que impide inventarla.
Lo que hay que mirar antes de dar una llave
Conectar un agente a tu API es darle una llave de tu casa. Estas son las cuatro cosas que yo preguntaría, nos las preguntes a nosotros o a quien sea.
- ¿A qué direcciones puede llamar?Sólo HTTPS, y nunca a una dirección de red interna. Un formulario que acepta cualquier dirección es un formulario por el que se le puede pedir al servidor que llame hacia dentro, a sitios que no son de nadie que esté mirando.
- ¿Dónde vive la credencial?Cifrada mientras está guardada, y en claro sólo durante la llamada que la usa. Nunca en un registro, nunca en una traza, nunca en lo que ve el modelo.
- ¿Puede una acción tuya sombrear una del catálogo?No debería. Una acción propia llamada igual que la de reembolsos pasaría el dinero por un camino donde el tope, la aprobación y la comprobación no están mirando.
- ¿Qué ve el agente que no has conectado?Nada. Lo que no conectas no existe para él, que es muy distinto de que exista y conteste que no puede.
Con eso resuelto, la pregunta de dónde está mi pedido deja de ser la que hace quedar mal a tu agente y pasa a ser la que lo hace útil. Es, de lejos, la más repetida.
