El chatbot va último: cómo ordeno las cinco automatizaciones que más me piden
Tengo 16 flujos en producción para pymes y la lista de pedidos se repite casi siempre igual. Lo que no se repite es cuál conviene hacer primero.
La discusión habitual las ordena por dificultad de construcción, y esa es la métrica equivocada. Construir es la parte barata: el modelo escribe la mayor parte. Lo que se paga después es el mantenimiento, y ahí el orden se da vuelta.
Van las cinco, ordenadas por lo que cuesta sostenerlas, de la peor a la mejor.
5. Responder consultas frecuentes
La que todos piden primero y la que más mantenimiento tiene.
Parece contenida: son las mismas veinte preguntas. No lo es, porque el contexto que necesita se mueve todo el tiempo. Cambia el catálogo, cambian los precios, cambia el horario en verano. Meta cambia requisitos de la API. El modelo se actualiza y el mismo prompt deja de comportarse igual.
Y sobre todo: es la única de las cinco donde el error lo ve el cliente. Un bot que inventa un precio no genera un ticket interno, genera un reclamo.
Si igual va primera —y a veces va, porque es la que se ve—, presupuestala con el abono adentro desde el día uno.
4. Turnos y reservas
La más engañosa de la lista. Tomar un turno es trivial; el problema es todo lo demás.
Cancelaciones, reprogramaciones, dos personas pidiendo el mismo horario con cuatro segundos de diferencia, el turno que se cargó a mano en el sistema y el bot no vio. Es estado compartido con escritura concurrente, que es un problema viejo y conocido, disfrazado de chatbot.
Si la agenda vive en un sistema con API decente, baja bastante. Si vive en un Google Calendar que además tocan tres personas a mano, no la subestimes.
3. Mover datos entre sistemas
La que más valor devuelve y la que menos depende de vos.
El trabajo real casi nunca es la transformación de los datos: es el sistema del otro lado. Y en pymes ese sistema suele ser uno de gestión local, sin API pública, sin documentación, y con un proveedor que no contesta.
Cuando hay API, esta es la mejor inversión de las cinco. Cuando no la hay, el proyecto deja de ser de IA y pasa a ser de ingeniería de integración, con otro presupuesto y otro plazo. Averiguar eso antes de cotizar es la diferencia entre ganar plata y regalar dos semanas.
2. Seguimientos automáticos
Barata de construir y barata de sostener. Su riesgo no es técnico.
El código anda; lo que falla es el criterio. Mandarle el recordatorio de pago a alguien que pagó ayer por transferencia y todavía no está imputado hace más daño que no mandar nada. El bug no está en el flujo, está en que la fuente de verdad se actualiza más lento de lo que corre el cron.
Antes de automatizar un seguimiento, la pregunta no es cómo se manda: es cuánto tarda el dato en estar bien.
1. Reportes
La mejor relación de la lista, y la que menos entusiasmo genera en la reunión.
Es idempotente: si corre dos veces, no rompe nada. Falla hacia adentro, así que un error no llega al cliente. No tiene estado concurrente. Y el criterio de correcto es verificable — el número da o no da contra el sistema.
Encima es la única donde el ahorro se puede medir sin discutir: la persona que armaba la planilla el lunes sabe exactamente cuánto tardaba.
El criterio, en una línea
Ordenalas por qué pasa cuando fallan, no por qué tan difícil es construirlas.
Todo lo que falla hacia adentro, es idempotente y tiene un criterio de correcto verificable va primero. Todo lo que falla delante del cliente o pelea por estado compartido va después, con más presupuesto y con abono.
La versión sin tecnicismos, para mandarle a quien decide el presupuesto: https://varka.tech/blog/automatizar-pyme-con-ia
Top comments (0)