Piensa en el primer día de alguien que acabas de contratar para atender a tus clientes. Le explicas su rol y le das su usuario. Y antes del almuerzo, casi sin darte cuenta, le dices qué hacer cuando le pidan algo que no le toca: a quién se lo pasa y qué no puede prometer.
A nadie nuevo le dices "usa tu criterio" y lo dejas solo con tus clientes. Con los agentes de IA lo hacemos todo el tiempo.
Le cargamos documentos, le escribimos una descripción de la empresa y lo soltamos. Imagínate que un cliente pide una devolución fuera de plazo, y el agente, por ser amable, le contesta "claro, lo gestionamos". Nadie en tu empresa aprobó esa respuesta, pero ya está escrita, en tu canal y con tu marca.
Cuando un agente improvisa así, muchas veces no le faltó inteligencia. Le faltó una decisión que tu empresa todavía no tomó.
Por eso yo diseño un agente como una contratación. Y a la parte que más cuesta yo le llamo "lo que no le toca decidir".
Un rol acotado: un agente por cada trabajo
¿Qué me encuentro en muchas primeras versiones? Un solo agente que califica, da soporte, cobra y resuelve reclamos. Uno para todo, con un prompt que crece cada semana.
Mientras más alineado está un agente a un rol, mejor resuelve. Es lo mismo que haces cuando armas un equipo y diseñas cada rol: a cada persona le das una responsabilidad y un objetivo, y a nadie le pides vender y cobrar en la misma conversación.
Mi recomendación es separar.
Un agente por unidad de negocio y, dentro de cada una, si hace falta, uno por tipo de actividad: la consulta rutinaria por un lado y el caso complejo por otro. Después los conectas entre sí, para que tu cliente no tenga que saber con cuál está hablando.
¿Qué hace tu agente cuando le piden algo que no le toca?
Te lo pongo con las palabras que uso cuando muestro la plataforma, porque las digo casi igual cada vez: "viene un cliente y te pide algo que está fuera del alcance del agente IA, pero en lugar de que lo dejes al agente IA resolver bajo su propio criterio, le habilitas un procedimiento para decirle cómo resolver este tipo de problemas".
En Conversia hay dos cosas para esto, y conviene no confundirlas.
El flujo es el procedimiento general del rol. Da la bienvenida, diagnostica el problema, aclara las dudas, transfiere cuando el caso es de cierto tipo y cierra. Acompaña toda la conversación.
El protocolo es el procedimiento para un tipo de caso concreto que tú defines: la devolución, el reclamo, la excepción de política. Entra en juego cuando ese caso aparece, y le dice al agente qué pasos seguir en vez de dejarlo decidir.
Vuelve a la devolución fuera de plazo y mira la diferencia. Sin protocolo, el agente busca la respuesta más amable y promete.
Con protocolo, reconoce que es ese tipo de caso, no promete nada, le pide al cliente el número de pedido y el motivo, le explica que esa excepción la revisa una persona, y transfiere el caso con lo que ya averiguó. Tu cliente no se queda sin respuesta, y tu empresa no se queda con una promesa que nadie autorizó.
Fíjate que ninguno de esos pasos exige inteligencia extra. Exige que alguien en tu empresa haya decidido antes qué se hace con una devolución fuera de plazo.
Y ahora la objeción que seguro ya tienes: "Eduardo, si le tengo que escribir un procedimiento para cada cosa, ¿para qué quiero una IA?".
Para cada cosa, no. Lo repetitivo lo resuelve con su base de conocimiento y su flujo, y ahí no escribes nada más. Yo pongo protocolos donde hay riesgo: una devolución, una queja formal, un cobro en disputa. Suelen ser pocos, y son justo los casos que te pueden costar un cliente.
Los datos que le das
Un agente que consulta tres versiones de la lista de precios va a terminar ofreciendo lo que no hay.
Por eso, antes de diseñar el rol, yo pregunto dónde vive la información que ese agente va a necesitar: el producto, sus especificaciones y, sobre todo, el stock. Si vive en cuatro sistemas que no coinciden, ese es el primer trabajo, antes que cualquier IA, y no le toca al agente.
Yo empiezo por ahí, antes de escribir una sola línea del rol.
Hace poco me contaron de una empresa que intentó lanzar un bot y nunca lo sacó a producción, porque la información de sus productos estaba incompleta o era inconsistente. Es un caso ajeno, y el patrón lo reconozco.
Y hay una pregunta que casi nadie se hace en esta etapa: ¿qué debería hacer el agente si el sistema que consulta no le contesta? Si no lo defines, lo va a improvisar también. Por eso está en la plantilla del final.
Cuando falla algo que no es suyo
Un cliente nos reclamaba que su agente no daba precios. Estaban convencidos de que el problema era nuestro.
Mi equipo lo revisó y encontró otra cosa: el servicio de precios del propio cliente funcionaba de forma intermitente. El agente consultaba y, a ratos, del otro lado no había respuesta. No entramos a discutir. Armamos un informe con el detalle y se lo mandamos.
Yo prefiero un informe a una discusión, y ese día se notó por qué.
El informe cambió de lugar la conversación. Dejó de tratarse del agente y pasó a tratarse de su propio sistema: si los precios llegaban a ratos, ¿cómo iban a dar el siguiente paso, que era cotizar?
Aquí vuelvo a la persona nueva, porque es donde más enseña. Si una persona nueva no puede dar precios, primero revisas si el sistema le funciona y después lo evalúas. Con un agente, el reflejo es culparlo primero. A mí ese reflejo me preocupa más que el error, porque te hace arreglar lo que no está roto mientras lo roto sigue ahí.
Tu primer protocolo, en una hoja
Toma la solicitud fuera de alcance que más te llega. Solo una. Y llena esto:
- Cuando el cliente pida: la solicitud, con las palabras que usa tu cliente y no las de tu manual.
- El agente no decide: lo que queda fuera de su criterio, dicho en una línea.
- Lo que sí hace: los tres o cuatro pasos en orden, incluida la pregunta que tiene que hacer antes de avanzar.
- Qué datos consulta: el sistema exacto donde está la respuesta, y qué hace si ese sistema no responde.
- A quién lo transfiere: el equipo o la persona, y con qué información tiene que llegar el caso.
Si la segunda línea te cuesta escribirla, ya encontraste lo que te decía al principio. Es una decisión que tu empresa todavía no tomó, y que hoy toma cada quien en tu equipo a su manera.
¿Qué le diste a tu agente el primer día?
Si llenaste la hoja y quieres ver dónde vive cada una de esas líneas dentro de Conversia, agenda una conversación conmigo y lo miramos con tus casos reales.
¿Cómo diseñar un agente de IA para que no improvise respuestas?
Dándole un rol acotado, procedimientos escritos para los casos fuera de su alcance y acceso a una única fuente de datos. Un agente al que se le deja resolver con su propio criterio improvisa cuando aparece algo imprevisto. Con un protocolo, sabe qué pasos seguir, qué no puede decidir y a quién transferir el caso.
¿Qué es un protocolo en un agente de IA?
Es un procedimiento específico que le indica al agente cómo resolver un tipo de situación que queda fuera de su alcance habitual, en lugar de dejarlo actuar con su propio criterio. Se usa donde hay riesgo, como devoluciones, quejas formales o excepciones de política. Lo repetitivo se resuelve con la base de conocimiento y el flujo.
¿Conviene un solo agente de IA para todo o varios especializados?
Varios especializados, conectados entre sí. Un agente alineado a un rol concreto resuelve mejor que uno que califica, da soporte y cobra a la vez. La separación suele hacerse por unidad de negocio y, dentro de cada una, por tipo de actividad, porque una consulta rutinaria y un caso complejo exigen procedimientos distintos.
¿Por qué un agente de IA necesita una única fuente de datos?
Porque si la información de productos, precios o disponibilidad está repartida en varios sistemas que no coinciden, el agente puede ofrecer algo que no existe o no está en stock. Hay proyectos de bots que nunca llegaron a producción por tener la información de producto incompleta o inconsistente, sin que la tecnología fuera el problema.
¿Qué hacer si mi agente de IA falla al dar información?
Revisar primero las integraciones de las que depende, antes de cambiar el agente. Muchas veces el origen es un sistema del propio negocio, como un servicio de precios que responde de forma intermitente. Lo que funciona es revisar las conversaciones con evidencia y documentar dónde se corta la respuesta, en lugar de discutir la causa.
