Crear una acción personalizada
Cómo dar al agente acceso a tus sistemas para que responda con datos reales, y cómo comprobar qué está haciendo.
Con tu conocimiento, el agente responde preguntas generales: qué política tenéis, cómo funciona algo, cuánto cuesta.
Con Acciones responde preguntas concretas: dónde está mi pedido, cuándo se me renueva, si mi factura está pagada. La diferencia entre las dos cosas es enorme para el cliente.
Están en Agente IA, en la sección Acciones.
Qué es exactamente una Acción
Es un permiso para consultar o hacer algo en un sistema tuyo.
Tú la defines una vez y el agente decide por su cuenta cuándo tiene sentido usarla. No hay que programar ninguna conversación: si has creado "Consultar estado de pedido" y alguien pregunta por su pedido, el agente pedirá el número, consultará y responderá con el dato real.
Antes de empezar: quién hace esto
La descripción y las instrucciones las escribe quien conoce el negocio y el soporte.
La parte de la conexión (a qué dirección llama, con qué credenciales) la rellena normalmente quien lleve la parte técnica de tu equipo, y es cosa de una vez por acción.
Si no tienes a nadie técnico a mano, no pasa nada: el agente funciona perfectamente sin Acciones. Son un escalón más, no un requisito.
Los cuatro bloques de una Acción
1. Qué hace y cuándo usarla
Es la parte más importante y la que más se descuida.
El agente decide si llamar a la acción leyendo esta descripción. Si es vaga, la llamará cuando no toca o no la llamará cuando toca.
Escribe las condiciones explícitas. Compara:
Mal: "Consulta pedidos." Bien: "Úsala cuando el cliente pregunte por el estado, la fecha de entrega o la ubicación de un pedido, y haya dado un número de pedido. No la uses para devoluciones ni para cambios de dirección."
Decir también cuándo NO usarla es lo que separa una acción que funciona de una que da problemas.
2. Qué datos necesita del cliente
Por ejemplo, el número de pedido o el correo electrónico.
El agente los pedirá en la conversación si no los tiene ya. Si el dato ya está en la ficha del cliente, no lo vuelve a preguntar.
Pide lo mínimo. Cada dato que haya que pedir es un turno más de conversación y una oportunidad más de que el cliente se canse y se vaya.
3. La conexión
A dónde llama, con qué método, y qué se envía. Es la parte técnica.
Hay dos límites que conviene conocer porque explican comportamientos raros: la respuesta que recibe el agente está limitada en tamaño, y lo que exceda se corta. Si tu sistema devuelve una parrafada enorme, es mejor que devuelva solo lo necesario, o el dato importante puede quedarse fuera.
4. Qué hacer con la respuesta
Puedes dejar que el agente use toda la información que recibe, o darle instrucciones sobre qué contar y qué callarse.
Esto último importa más de lo que parece. Si tu sistema devuelve el pedido entero, ahí puede haber márgenes, costes internos o notas del almacén que no quieres que acaben en un chat con el cliente. Las instrucciones son donde lo acotas.
Probarla antes de soltarla
Antes de guardar, puedes probar la acción con valores de ejemplo y ver exactamente qué devuelve tu sistema.
Hazlo siempre. Es la diferencia entre descubrir un problema ahora o descubrirlo en una conversación real.
Ver qué está haciendo: Ejecuciones
En Agente IA, entra en Ejecuciones. Ahí aparece cada llamada que el agente ha hecho a una acción: cuándo, qué envió y qué le respondió tu sistema.
Es el primer sitio donde mirar cuando algo va raro, y el diagnóstico casi siempre es uno de estos dos:
No hay ninguna ejecución cuando debería haberla. El agente no está llamando a la acción. El arreglo está en la descripción de cuándo usarla: hazla más explícita.
Hay ejecución pero la respuesta al cliente es rara. Mira qué devolvió tu sistema. O devolvió un error, o devolvió algo que el agente no supo interpretar, o venía cortado por tamaño.
Las ejecuciones se conservan un tiempo, así que si quieres investigar algo, no lo dejes para dentro de meses.
Empieza por consultar, no por modificar
La recomendación que ahorra disgustos.
Las acciones de solo consulta (mirar un pedido, comprobar un plan) tienen poco riesgo: si algo sale mal, se ha dicho un dato equivocado y se corrige con un mensaje.
Las acciones que cambian cosas (cancelar una suscripción, emitir un reembolso, borrar datos) merecen que primero veas cómo se comporta el agente durante unas semanas. Y cuando las montes, que tu propio sistema tenga sus comprobaciones: no confíes en que el agente nunca se equivocará de identificador.
Cuántas crear
Menos de las que crees.
Una acción bien descrita que cubre el 40 % de las preguntas concretas vale más que ocho acciones vagas que el agente confunde entre sí. Cuantas más tengas y más se parezcan, más fácil es que elija la equivocada.
El método que funciona: activa el agente sin acciones, deja pasar una semana, apunta qué preguntas no pudo responder por falta de un dato de tus sistemas, y crea la acción que resuelva más de esas. Repite.
Diagnóstico
No llama a la acción nunca. La descripción de cuándo usarla es demasiado vaga. Reescríbela con condiciones explícitas.
La llama cuando no debe. Añade a la descripción los casos en los que no debe usarse.
Confunde dos acciones parecidas. Diferencia mucho más sus descripciones, o fúndelas en una sola.
Responde con datos incompletos. Puede que la respuesta venga cortada por tamaño. Haz que tu sistema devuelva menos campos.
Cuenta cosas que no debería. Acota qué puede usar en las instrucciones de la acción.
¿Te ha resultado útil?
