Imagina que abres el correo de posventa un lunes. Hay un cliente que pregunta por un envío, otro que quiere devolver dos unidades y un tercero que solo dice «me ha vuelto a pasar lo de la semana pasada». Los tres mensajes han llegado al mismo buzón. ¿Les pondría un agente de IA delante? No a todos. Y antes de mirar herramientas, querría saber qué hace hoy la persona que los atiende.
Esa es la diferencia que más me importa cuando una pyme quiere automatizar con IA. A veces el equipo pierde tiempo copiando el mismo dato; otras, el trabajo de verdad consiste en entender un mensaje confuso y averiguar qué pasó antes. Desde fuera, todo parece «gestionar correos». Por dentro, son problemas distintos.
El correo más fácil no necesita un agente
Supongamos que las devoluciones llegan desde un formulario con el número de pedido, el producto y el motivo. Si el trámite empieza siempre igual, haría algo bastante sencillo: comprobar el número, registrar la solicitud y avisar a posventa. Si el pedido no se encuentra, lo dejaría en revisión. Es el tipo de flujo de desencadenantes y acciones que puedes explicar y comprobar sin discutir qué «entendió» un modelo.
Con la pregunta por el envío pasa algo parecido. Si el número está identificado y el sistema logístico devuelve el estado, una regla puede consultar ese dato. No quiero que un modelo improvise una fecha de entrega cuando el transportista todavía no la ha confirmado. Reservaría la IA para lo que de verdad cambia de un correo a otro: la forma en la que el cliente cuenta qué necesita.
Leer el mensaje no es lo mismo que decidir el trámite
Ahora imagina que las devoluciones ya no llegan por formulario. Una persona escribe «pedí tres y me quedo uno»; otra reenvía la confirmación y añade «el azul no era». Ahí sí usaría IA para proponer un motivo y extraer el número de pedido, si aparece. Pero no por eso le cedería todo el trámite. La comprobación de las unidades y la creación de la solicitud seguirían por el camino previsto. Y si el modelo devuelve dos pedidos posibles, alguien del equipo resuelve la duda.
A eso me refiero con IA acotada. Le das al modelo una tarea que antes requería leer o interpretar. El resto del proceso conserva sus reglas. Sirve también para una factura: la IA puede leer los campos de un PDF, mientras que el sistema comprueba importes y detecta duplicados antes de que nadie dé por bueno el documento. No hace falta que la misma pieza que interpreta los datos tenga permiso para aprobarlos.
El agente empieza a tener sentido cuando no sabes qué mirar primero
Volvamos al correo de «lo de la semana pasada». ¿Se refiere al envío anterior, a un producto dañado o a una incidencia que ya está abierta? Para resolverlo, quizá haya que leer la conversación, consultar los pedidos recientes y mirar qué dejó anotado otra persona en el CRM. Lo interesante es que la segunda consulta depende de lo que encuentres en la primera. Un flujo con agente puede elegir entre esas herramientas y reunir la información para proponer el siguiente paso.
Lo probaría con acceso de lectura y una salida muy concreta: «Esta parece ser la incidencia, estos son los registros en los que me baso y este es el mensaje que propongo». El equipo tendría algo mejor que un correo suelto y podría ver de dónde salió cada dato. Si la referencia no encaja o el agente encuentra dos clientes con el mismo nombre, prefiero que pida ayuda a que resuelva el empate por su cuenta.
También hay casos en los que la complejidad está en otro sitio. Si el historial está repartido entre hojas y cada persona identifica un pedido de una manera, conectar más herramientas no arregla esa incoherencia. Antes de comprar nada, comprobaría qué sistema es fiable para cada dato y si el ERP o el CRM permiten consultarlo con los permisos adecuados.
Yo separaría lo que puede preparar de lo que puede ejecutar
Que una respuesta esté bien redactada no significa que un reembolso esté autorizado. Dejaría que el agente resumiera el historial y preparara una propuesta, pero mantendría la decisión de devolver dinero, cambiar un dato maestro o enviar un compromiso al cliente en manos del equipo. Además, el permiso tiene que reflejarlo: si su trabajo es leer pedidos, no necesita una cuenta que también pueda modificarlos.
Si algún día se autoriza una acción, debe quedar claro quién la aprobó, qué iba a cambiar y cómo se corrige si sale mal. Lo mismo vale para los datos: probaría con registros de prueba o anonimizados, y limitaría la información que sale del sistema a la que haga falta para esa tarea. Cuando el proceso implique datos personales o decisiones sobre personas, revisaría las obligaciones aplicables antes de plantear siquiera una puesta en producción.
La prueba que haría antes de pagar por un agente
Escogería una sola bandeja y compararía cómo trabaja el equipo hoy con cómo trabajaría usando las propuestas del agente. No probaría solo los mensajes fáciles. Metería también el pedido que no existe, el cliente que mezcla dos problemas y la consulta al ERP que no devuelve nada. Ahí puedes ver si el agente reconoce que le falta información, deja una explicación útil y sabe pasar el caso a una persona.
El dato que me interesaría no es cuántos mensajes «procesó». Es cuánto tiempo se ahorra después de revisar y corregir sus propuestas. A eso le sumaría el coste de las integraciones, las llamadas al modelo y el mantenimiento cuando cambie un conector. Guardaría además las reglas y los casos de prueba fuera de la herramienta: si mañana decides cambiar de plataforma, ese conocimiento tiene que seguir siendo tuyo.
Si las reglas resuelven las devoluciones y la IA acotada solo hace falta para leer el correo, me quedaría ahí. Probaría un agente donde de verdad evite que alguien tenga que reconstruir una incidencia saltando entre sistemas. La mejor señal de que encaja es que el equipo recibe una propuesta útil y comprobable, no que el flujo tenga más autonomía.
Preguntas frecuentes
¿Un agente de IA sustituye a una automatización tradicional?
No. Si conoces las reglas y el orden de las acciones, suele ser más sencillo y predecible mantener un flujo convencional. Un agente puede ayudar cuando el siguiente paso depende de lo que vaya encontrando.
¿Qué diferencia hay entre un flujo con IA y un agente de IA?
Un flujo puede usar IA para clasificar un correo y continuar por una secuencia ya definida. En un agente, el modelo puede elegir la siguiente consulta o herramienta dentro de un conjunto autorizado.
¿Puede conectarse a mi ERP o CRM?
Sí, si hay una API o conector compatible. Antes de ponerlo en producción comprobaría qué datos puede leer, con qué permisos y qué ocurre cuando el sistema no responde. No hace falta darle acceso de escritura para preparar una propuesta.
¿Qué tareas no dejaría en manos de un agente sin supervisión?
Pagos, cambios en datos maestros, decisiones sobre personas y compromisos con clientes son ejemplos en los que mantendría controles y aprobación humana. La consecuencia de equivocarse importa más que lo fácil que sea configurar la acción.
¿Un agente cuesta más que una automatización convencional?
Depende del volumen y de las herramientas. Además de licencias y uso del modelo, incluye integración, revisión de resultados y mantenimiento. Compáralo con el tiempo neto que te ahorra en el proceso real.
¿Tiene que revisar una persona todos los casos?
No necesariamente. Una comprobación rutinaria y reversible puede seguir su camino previsto. En el piloto revisaría las propuestas, y conservaría la aprobación para las acciones sensibles o los casos en los que faltan datos.
¿Cómo sé si el piloto ha salido bien?
Comprueba qué propuestas pudo aprovechar el equipo, cuánto tardó en revisarlas y cuántos errores o casos ambiguos llegaron a tiempo a una persona. Prueba también si los registros permiten reconstruir qué consultó y qué propuso el agente.
¿Tu equipo pierde más tiempo leyendo correos o reconstruyendo lo que pasó?
En Soulvi podemos revisar contigo cómo entra una incidencia, qué datos hay que consultar y qué decisiones conviene reservar al equipo. Así podrás decidir si basta con unas reglas, si necesitas IA para leer mensajes o si tiene sentido probar un agente.
