IA y automatización Publicado

Automatizar las peticiones de cuenta en un SaaS: contraseñas, usuarios y cambios de plan

Restablecer accesos, añadir usuarios, cambiar de plan o reenviar una factura son peticiones que llegan cada día a soporte y que tu producto ya sabe hacer. Cuáles conviene automatizar con un agente de IA que llama a tu API, cuáles no, cómo hacerlo seguro y qué pasa cuando algo falla.

Adrià Castany 11 min

Manojo de llaves sobre una mesa

«No me llega el correo para restablecer la contraseña.» «¿Podéis añadir a mi compañera al equipo?» «Quiero pasarme al plan anual.» «Necesito la factura de marzo con el CIF nuevo.»

Son peticiones que llegan cada día al soporte de cualquier SaaS, que alguien del equipo resuelve en dos minutos entrando en el panel de administración y que, sumadas, se comen una parte enorme de la semana. Tu producto ya sabe hacer todas esas cosas: lo que falta es que el cliente pueda pedirlas en una conversación y que se hagan sin esperar a una persona.

La respuesta corta

Las peticiones de cuenta de un SaaS se automatizan con un agente de IA que, además de responder, llama a tu API con los permisos que le des. Conviene empezar por las de lectura (estado de la cuenta, plan, uso, facturas) y por las de escritura reversibles y de poco riesgo (reenviar un correo de acceso, añadir un usuario dentro del límite del plan). Las que mueven dinero o borran datos, mejor con una comprobación previa o con una persona. Para hacerlo seguro hacen falta tres cosas: saber quién pregunta, que el agente solo pueda hacer lo que le declares y que cada acción quede registrada.

Qué peticiones automatizar primero

PeticiónTipoRiesgoRecomendación
¿Qué plan tengo y cuánto uso?LecturaNingunoAutomatizar ya
Reenviar el correo de acceso o de verificaciónEscrituraBajoAutomatizar ya
Descargar o reenviar una facturaLecturaBajoAutomatizar ya
Añadir un usuario dentro del límite del planEscrituraBajoAutomatizar
Ampliar la prueba gratuita unos díasEscrituraBajoAutomatizar con un límite
Cambiar de planEscrituraMedio (dinero)Con confirmación del cliente y reglas claras
Cambiar el email del propietario de la cuentaEscrituraAltoPersona
Cancelar y borrar la cuentaEscrituraAltoPersona, o flujo propio del producto

La regla: cuanto más fácil es deshacerlo, antes se automatiza. Un correo reenviado de más no hace daño; un plan cambiado por error, sí.

Cómo funciona: el agente llama a tu API

Una acción es una llamada a un endpoint que ya tienes: tu panel de administración hace exactamente esas llamadas. Defines cuatro cosas:

  1. Qué endpoint y con qué método: lectura (GET) o escritura (POST, PUT, PATCH o DELETE).
  2. Qué datos necesita y de dónde salen: el identificador del cliente de la conversación, el usuario a invitar, el plan nuevo.
  3. Cuándo usarla: una descripción en lenguaje normal, como «para reenviar el correo de verificación cuando el cliente dice que no le llega».
  4. Qué hacer con la respuesta: cómo explicársela al cliente.

El agente decide cuándo usarla en función de lo que pide el cliente y responde con el resultado real, no con una suposición.

Conversación en la que el agente consulta el plan del cliente en la API antes de responder
El agente llama a la API del producto, lee el plan real del cliente y responde con ese dato.

Cómo hacerlo seguro

Saber quién pregunta

Antes de tocar una cuenta hay que estar seguro de que quien escribe es el dueño. Si el chat va dentro de tu aplicación, lo mejor es pasarle la identidad del usuario conectado con una firma de tu servidor, para que no se pueda suplantar desde el navegador. Si escribe desde fuera (la web pública, el correo), las acciones de escritura deberían pedir antes una verificación: un código al correo de la cuenta, por ejemplo.

Que solo pueda hacer lo que declares

El agente no tiene acceso libre a tu API: solo existen las acciones que configuras, con los parámetros que configuras. Si solo le das endpoints de lectura, no hay forma de que escriba nada. Usa una clave de API con los permisos mínimos para esas acciones, no la de administrador.

Comprobar antes de actuar

Para lo delicado, encadena: que el cambio de plan solo pueda ejecutarse después de haber consultado el plan actual en esa conversación, por ejemplo. Y que el agente confirme con el cliente antes de ejecutar: «Te paso al plan Pro anual por 1.548 € al año, ¿lo confirmo?».

Que quede registrado

Cada acción ejecutada debe quedar en la conversación y en un registro: qué se llamó, con qué datos y qué devolvió. Es lo primero que vas a querer mirar cuando un cliente diga «yo no pedí eso».

Qué pasa cuando algo falla

Las APIs fallan: un tiempo de espera, un error 500, un dato que no existe. Lo que no puede pasar es que el agente invente el resultado. Lo correcto:

  • Decir que no ha podido hacerlo, sin tecnicismos.
  • Pasar la conversación a una persona con el error a la vista, para que no tenga que reproducirlo.
  • No reintentar a ciegas una escritura: repetir un «añadir usuario» o un «cambiar plan» puede hacerlo dos veces.

Cuándo y cómo debe derivar un agente, en reglas de escalado de un agente de IA.

Cómo medir si funciona

  • Peticiones de cuenta resueltas sin persona sobre el total de peticiones de cuenta.
  • Acciones que fallan, por acción: una que falla mucho suele ser un permiso o un dato mal configurado.
  • Clientes que vuelven a escribir por lo mismo en los días siguientes: si vuelven, no estaba resuelto.

Cómo lo hace Intake

En Intake, cada acción es una llamada a tu API que declaras desde el panel: método, endpoint, datos que necesita y cuándo usarla. Las cabeceras y parámetros que marques como secretos se guardan cifrados; cada llamada tiene un tiempo límite (8 segundos por defecto, hasta 30); una acción de escritura no se repite dentro de la misma conversación, y puedes exigir que otra acción se haya ejecutado antes con éxito. El widget admite verificación de identidad firmada desde tu servidor, y cada ejecución queda registrada con su resultado. Lo tienes en ejecutar acciones.

Preguntas frecuentes

¿Es seguro dejar que una IA cambie datos de la cuenta?

Lo es si solo puede hacer lo que declaras, con una clave de permisos mínimos, sabiendo quién pregunta y dejando registro. Empieza por la lectura y por escrituras fáciles de deshacer.

¿Hace falta desarrollar algo nuevo?

Normalmente no: se usan los mismos endpoints que ya usa tu panel de administración. Como mucho, uno pequeño para lo que hoy se hace a mano en la base de datos.

¿Qué petición conviene automatizar primero?

La consulta del plan y el uso, y el reenvío del correo de acceso. Son frecuentes, de riesgo nulo o muy bajo, y se notan desde el primer día.

¿Y si el cliente pide algo que el agente no puede hacer?

Lo dice y pasa la conversación a una persona con la petición y los datos ya reunidos, para que solo tenga que ejecutarla.

¿Puede cambiar el plan de un cliente?

Sí, con una acción de escritura. Conviene que confirme con el cliente el plan y el importe antes de ejecutarla y que solo pueda hacerlo tras consultar el plan actual.

Para seguir