DEV Community: Gonzalo Terrones

Automatizaciones para pymes: las cinco que siempre piden, ordenadas por lo que cuesta mantenerlas

Gonzalo Terrones — Tue, 25 Aug 2026 18:58:38 +0000

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

Automatizar listas de precios: lo que se rompe cuando el proveedor cambia el Excel

Gonzalo Terrones — Wed, 12 Aug 2026 13:27:02 +0000

Hace un tiempo escribí sobre automatizar una distribuidora y puse la carga de listas de precios como el proceso con mejor retorno. Me preguntaron por el detalle, así que va la implementación, con las partes que se rompen.

El escenario: el proveedor manda una lista cada dos o tres semanas. PDF o Excel, formato distinto según quién la exportó ese día. Alguien la abre y carga cientos de artículos a mano en el sistema de gestión.

El error de arranque: mandarle el archivo entero al modelo

Lo primero que uno intenta es pasarle el PDF al LLM y pedirle el JSON de las 800 filas. Funciona en la demo con 20 filas y se cae con el archivo real: se saltea filas del medio, inventa códigos que no existen, y el costo por corrida sube sin necesidad.

El modelo no tiene que leer las 800 filas. Tiene que leer el encabezado.

Archivo del proveedor
        │
        ▼
Extracción determinística de la tabla   (pdfplumber / openpyxl)
        │
        ▼
LLM sobre las primeras ~15 filas  →  mapeo de columnas
        │                             {codigo: "B", precio: "F", bulto: "D"}
        ▼
Aplicar ese mapeo a las 800 filas con código común
        │
        ▼
Matching contra el maestro  →  validaciones  →  escritura por lote

El LLM se usa una vez por archivo, no una vez por fila. Lo variable es el layout, no los datos.

Matching de códigos: tres pasadas y una bandeja

El código del proveedor casi nunca coincide con el tuyo. Van tres intentos, en orden:

Match exacto contra el código de proveedor guardado en el maestro.
Match normalizado: sin espacios, sin guiones, sin ceros a la izquierda.
Match por descripción, y solo si la similitud pasa un umbral alto.

Lo que no matchea no se crea. Va a una bandeja de revisión y alguien la mira. Un flujo que da de alta productos solo te llena el maestro de duplicados en tres meses, y eso no se limpia nunca más.

Cuando el humano resuelve un caso de la bandeja, se guarda la equivalencia. La bandeja del segundo mes es la mitad que la del primero.

Las validaciones que frenan la escritura

Determinísticas, en código, después del modelo:

Variación de precio mayor al umbral (arranco en 40%) → frena esa fila.
Precio en cero, negativo o no numérico → frena.
Código repetido dentro del mismo archivo → frena las dos filas.
Menos filas de las esperadas contra la última corrida → frena el lote entero.

Ese último es el que salva. Si el proveedor manda una lista parcial con 60 artículos y tu flujo asume que es la lista completa, cualquier lógica de "lo que no vino se discontinúa" te apaga el catálogo.

Lo que aprendí a los golpes

Separador decimal. 1.234,56 y 1,234.56 según quién exportó. Si lo parseás con la config local y el archivo vino de otro lado, cambiás precios por mil.

IVA. Algunos proveedores mandan con IVA, otros sin, y el mismo proveedor cambia de criterio cuando cambia de sistema. No se deduce del número: se guarda como atributo del proveedor y se valida contra el margen resultante.

Precio por bulto. La columna dice "precio" y es por caja de 12. Si tu maestro lo lleva por unidad, todo entra multiplicado por 12.

PDFs escaneados. Alguno llega como imagen. Ahí sí va OCR antes, y ahí sí conviene revisión humana del lote completo: el OCR confunde 0 con 8 y ese error pasa todas las validaciones porque es un número plausible.

Idempotencia y vuelta atrás

Dos cosas que parecen de más hasta la primera vez que las necesitás:

Hash del archivo antes de procesar. La misma lista reenviada por mail no se procesa dos veces.
Batch id en cada escritura, con el precio anterior guardado. Revertir un lote entero tiene que ser una consulta, no una restauración de backup.

Lo que queda

El proceso pasa de media jornada a un par de minutos, más el rato de la bandeja de revisión, que se achica sola. Pero lo que realmente cambia no es el tiempo: es que los precios de la góndola y los del e-commerce dejan de estar desfasados respecto del sistema, porque ahora se actualizan en el mismo movimiento.

Dos reglas que me quedaron de esto y valen para cualquier automatización que escriba en un sistema de producción: el modelo interpreta y el código decide, y ningún flujo escribe sin poder deshacerse.

Escribo sobre automatización con IA para pymes argentinas desde Varka. La versión no técnica de esta nota, para dueños de negocio, está en el blog.

Chatbot de WhatsApp con IA para pymes: qué es y cómo funciona

Gonzalo Terrones — Tue, 11 Aug 2026 14:41:52 +0000

En Argentina, WhatsApp es el canal donde la gente le habla a los negocios. El problema es que las consultas llegan a toda hora, se repiten mil veces ("¿tenés stock?", "¿cuánto sale?", "¿hacen envíos?") y cada mensaje sin responder rápido es una venta que se enfría. Un chatbot de WhatsApp con IA resuelve exactamente eso: atiende, informa y vende 24/7, sin que tengas que estar pegado al teléfono.

Qué es (y qué no es)

Un chatbot de WhatsApp con IA es un asistente que responde los mensajes de tu negocio entendiendo lenguaje natural. No es el clásico bot de menú de "marcá 1 para ventas, 2 para soporte" que se traba apenas el cliente escribe distinto. Este entiende lo que la persona quiere aunque lo diga con sus palabras, mantiene el hilo de la conversación y resuelve casos que no estaban guionados. Es, en la práctica, un agente de IA trabajando en tu WhatsApp.

Qué puede hacer por tu pyme

Atender 24/7: responde las consultas frecuentes al instante, de día y de noche, resolviendo el grueso de los mensajes sin intervención humana.

Informar y vender: da precios, disponibilidad y características, recomienda productos y guía al cliente hasta la compra.

Tomar pedidos y reservas: ideal para comercios y gastronomía — mirá el caso de IA para gastronomía.

Calificar prospectos: hace las primeras preguntas y te pasa al vendedor solo los contactos que valen la pena.

Hacer seguimientos: recordatorios de turnos, pagos pendientes o clientes que hace rato no compran.

Si dudás de si tu negocio ya lo necesita, mirá las 5 señales de que tu pyme necesita un chatbot.

Cuánto cuesta

Depende del alcance y de las integraciones, pero para una pyme suele arrancar en el orden de unos cientos de dólares de implementación, más un costo mensual de operación. Comparado con las horas de atención que ahorra y las ventas que rescata fuera de horario, el retorno suele ser rápido.

Cómo se implementa

Se conecta a tu número de WhatsApp (a través de la API oficial de WhatsApp Business), se lo "entrena" con la información de tu negocio —productos, precios, políticas, tono— y se lo integra con tus sistemas para que deje todo registrado. Bien hecho, el cliente siente que habla con alguien de tu equipo, y siempre puede pedir pasar a una persona.

Errores comunes a evitar

Que suene a robot y frío; que no sepa cuándo derivar a un humano; que no esté integrado y te obligue a recargar todo a mano; y que se arme sin pensar en la conversación real de tu cliente. Un buen chatbot es tan bueno como el criterio con el que se diseña, no solo la tecnología detrás.

Preguntas frecuentes

¿Qué es un chatbot de WhatsApp con IA?

Es un asistente que responde los mensajes de WhatsApp de tu negocio usando inteligencia artificial. A diferencia de un bot de menú tradicional (opción 1, opción 2), entiende el lenguaje natural del cliente, mantiene una conversación real, responde preguntas sobre productos y precios, toma pedidos o reservas y deriva a una persona cuando hace falta. Trabaja las 24 horas, todos los días.

¿Qué puede hacer un chatbot de WhatsApp con IA en una pyme?

Puede atender consultas frecuentes 24/7, informar precios y disponibilidad, tomar pedidos y reservas, calificar prospectos antes de pasarlos a un vendedor, enviar recordatorios y seguimientos, e integrarse con el sistema de la empresa para dejar todo registrado. En la práctica resuelve el 70-80% de las consultas repetitivas sin intervención humana.

¿Cuánto cuesta un chatbot de WhatsApp con IA en Argentina?

Depende del alcance y de las integraciones, pero para una pyme suele arrancar en el orden de unos cientos de dólares de implementación, más un costo mensual de operación. Es bastante más accesible que hace unos años y, comparado con las horas de atención que ahorra, el retorno suele ser rápido.

¿En qué se diferencia de un bot de menú tradicional?

Un bot de menú sigue un árbol rígido de opciones y se traba apenas el cliente escribe algo distinto a lo previsto. Un chatbot con IA entiende lo que la persona quiere aunque lo escriba con sus palabras, mantiene contexto de la conversación y resuelve casos que no estaban guionados, dando una atención mucho más natural y efectiva.

Publicado originalmente en varka.tech.

Medir si un LLM nombra a tu empresa: por qué una captura no sirve como métrica

Gonzalo Terrones — Tue, 04 Aug 2026 23:40:44 +0000

Cada vez más gente arranca la búsqueda de un proveedor preguntándole a un modelo en vez de a un buscador. Y no pide diez opciones para comparar: pide una recomendación y recibe dos o tres nombres. Si tu empresa no está ahí, no quedaste octava. No estás en la respuesta.

La pregunta que sigue es obvia: cuánto tarda en cambiar eso. Pero antes hay un problema más aburrido y más importante, que es cómo se mide. Lo escribo porque es la parte que casi nunca se cuenta y es donde se rompen los informes.

Una captura de pantalla no es una medición

Es el error más común y el más difícil de discutir, porque la captura parece prueba.

La respuesta de una app conversacional depende del historial de la cuenta, de la sesión, del ruteo interno del proveedor, de si esa consulta activó búsqueda web o no, y de la región desde donde se pregunta. Dos personas preguntando lo mismo el mismo día reciben respuestas distintas. La misma persona preguntando dos veces también.

O sea: la salida no es determinista y el instrumento no es estable. Una captura te dice qué pasó una vez, en un contexto que no podés reconstruir. Como métrica de seguimiento no sirve para nada.

Lo que sí sirve es una serie: la misma consulta, literal, contra el mismo motor, con el mismo criterio de clasificación, repetida en el tiempo. El valor absoluto de un punto importa poco. Lo que importa es la diferencia entre puntos.

Fijar el texto de la consulta, no la etiqueta

Este es un bug de proceso que da resultados verosímiles y falsos.

Si guardás en la planilla una etiqueta como "consulta de chatbot" en vez del texto exacto que preguntaste, dentro de dos meses nadie se acuerda del wording. Y el wording cambia el resultado: preguntar "quién hace X en Argentina" y "mejores empresas de X en Argentina" devuelven listas distintas.

Cuando el texto se corre entre rondas, la serie deja de ser comparable, pero el gráfico sigue dibujándose igual de lindo. Guardá el string literal, versionado. Si tenés que cambiar una consulta, empezá una serie nueva en vez de contaminar la vieja.

Dos instrumentos que parecen uno

Preguntarle a un modelo con búsqueda web activada y preguntarle sin ella son dos mediciones distintas, y se contradicen entre sí. La misma consulta puede dar mención con uno y ausencia con el otro.

No es un error del modelo: son dos cosas diferentes. Uno te dice qué encuentra ahora; el otro, qué quedó incorporado. Mezclarlos en una misma serie produce oscilaciones que después se explican como "volatilidad del algoritmo" cuando en realidad es el instrumento cambiando de mano.

Cada punto de la serie tiene que registrar con qué se midió.

Tres estados, no un porcentaje

El otro lugar donde se maquillan los números es la clasificación. Conviene tener estados discretos:

Ausente — no aparece.
Mencionada — el modelo la nombra en el cuerpo de la respuesta, pero no cita el sitio. Sabe que existe; no está leyendo la fuente. Es un estado frágil: puede consolidarse o desaparecer en la ronda siguiente.
Citada — el dominio aparece en el bloque de fuentes. Sostiene lo que el modelo dice y además manda tráfico.

Colapsar los tres en un único "índice de visibilidad" produce una mejora que en la práctica no siempre existe: pasar de ausente a mencionada infla el número sin que nada estructural haya cambiado.

Un detalle de implementación si automatizás la clasificación: buscar el nombre de la marca por substring da falsos positivos cuando la marca es corta o queda pegada a otra palabra, y falsos negativos con acentos y normalización Unicode. Vale la pena armar un set de casos borde antes de confiar en el clasificador.

Y ahora sí, cuánto tarda

Con esas condiciones, lo que se ve repetido:

Las consultas de marca —"qué es tal empresa"— se mueven primero. Las de categoría —"mejores empresas de tal cosa en tal país"— bastante después. Y las de intención de compra —"a quién le contrato tal cosa"— son las últimas, y son justo las que traen clientes.

Tiene sentido si pensás qué necesita el modelo en cada caso. Para contestar qué hace tu empresa alcanza con haber encontrado información confiable sobre vos. Para ponerte en una lista de tres tiene que compararte con todo tu rubro y decidir que merecés el lugar.

El primer movimiento suele aparecer cerca de la cuarta semana. Antes de eso el trabajo está hecho pero todavía no se ve, que no es lo mismo que no estar funcionando. Ahí es donde la mayoría cambia de estrategia, justo cuando la anterior estaba por dar resultado.

Lo que se aprende midiendo

Que el sitio propio puede no ser la fuente. Es perfectamente posible que el modelo describa a tu empresa con tu texto y cite un directorio de terceros en vez de tu dominio. La descripción viajó; la atribución no.

Y que el reconocimiento no implica pertenencia. Un modelo puede describirte bien cuando lo nombrás, y no incluirte cuando le preguntás por la categoría. Son dos preguntas distintas y hay que correr las dos.

Nada de esto se resuelve con un truco. Se resuelve midiendo en condiciones repetibles el tiempo suficiente como para saber qué mover.

Escribo sobre automatización con IA aplicada a empresas. La versión original de esta nota está en varka.tech.

Por qué fracasan los proyectos de IA en las empresas (spoiler: no es la tecnología)

Gonzalo Terrones — Mon, 27 Jul 2026 20:15:59 +0000

Los proyectos de inteligencia artificial casi nunca fracasan por la tecnología. Fracasan en el último paso: el de incorporarla al trabajo de la gente.

Lo escribo después de una conversación con Mayra Regueira, Consultora Estratégica en Innovación & Negocios, que trabaja el lado humano de las organizaciones. Yo vengo del lado técnico — armo automatizaciones y agentes de IA — y ella me puso nombre a algo que veo seguido pero no había ordenado: el punto de quiebre no está en el modelo, ni en la integración, ni en el presupuesto. Está en el día después de la entrega.

El proyecto funciona y aun así no arranca

La secuencia es siempre parecida. Se define el proceso, se arma la automatización, se conecta con los sistemas que la empresa ya tiene, se prueba. La demo sale bien. Todos aplauden.

Y ahí empieza el problema de verdad, porque la herramienta entra en un equipo que tiene rutinas, jerarquías y una idea bastante clara de para qué está cada uno. La IA le toca eso a todos al mismo tiempo, y nadie preparó la conversación.

Una tecnología que funciona pero que nadie usa no es un problema técnico. Es un problema de trabajo no hecho.

Las tres preguntas que nadie prepara

Cuando el sistema queda andando, aparecen tres preguntas que rara vez están contestadas de antemano:

1. ¿Qué hace ahora la persona que antes hacía esa tarea?
Si alguien dedicaba dos horas diarias a cargar datos y esas dos horas ya no existen, esa persona necesita saber en qué las va a usar. Si no se lo dicen, la respuesta que se arma sola en su cabeza es "me están por echar". Y una persona que piensa eso no colabora con la implementación: la sabotea, aunque sea sin querer.

2. ¿Cómo cambia el trabajo del equipo cuando una parte la resuelve la IA?
No es solo la tarea que desaparece. Cambian los tiempos, cambia quién revisa qué, cambia de quién es la responsabilidad cuando algo sale mal. Un equipo que no tiene eso definido vuelve al método viejo a la primera duda, porque el método viejo tiene reglas conocidas.

3. ¿Quién se lo explica a la gente?
Esta es la que más me quedó de la charla con Mayra. Y la respuesta incómoda es que no le toca al proveedor de tecnología.

El rol del líder es la parte que no se puede tercerizar

Yo puedo dejar un flujo andando perfecto. Puedo documentarlo, capacitar, dejar el soporte abierto. Lo que no puedo hacer desde afuera es decirle a un equipo para qué está cada uno ahora.

Eso le toca al líder del grupo. Es quien tiene que reposicionar a su gente y redefinir las actividades de cada uno en la nueva dinámica entre personas e IA: qué queda del lado humano, qué pasa a la máquina, y sobre todo qué cosas nuevas ahora se pueden hacer con el tiempo que se liberó.

Es un trabajo de conducción, no de sistemas. Y es el que más se saltea, porque no aparece en ningún presupuesto ni en ningún cronograma de implementación.

Cuando ese trabajo no se hace pasa siempre lo mismo: la herramienta queda instalada, se usa dos semanas, y al mes el equipo volvió a la planilla de antes. El proyecto figura como entregado y nadie lo está usando.

Qué se puede hacer, en concreto

Nada de esto es abstracto. Son cuatro cosas bastante prácticas:

→ Contestar la pregunta del puesto antes de arrancar, no después. Antes de la primera línea de código, que cada persona afectada sepa qué va a estar haciendo cuando el sistema esté andando. Si la respuesta honesta es "todavía no lo sabemos", eso también hay que decirlo, pero decirlo.

→ Que el líder del equipo esté en el proyecto desde el principio. No como aprobador del presupuesto: como parte del diseño. Es quien conoce las rutinas reales, que casi nunca son las del manual.

→ Empezar por un proceso que le moleste al equipo, no al gerente. La adopción es mucho más fácil cuando lo primero que automatizás es la tarea que todos odian. Se gana confianza antes de tocar algo sensible.

→ Medir uso, no entrega. El indicador no es "el sistema está en producción". Es cuánta gente lo usó esta semana. Si ese número baja, hay una conversación pendiente con el equipo, no un bug.

Y una que digo siempre desde el lado técnico: no automatices un proceso que está roto. Primero ordenalo. Si no, automatizás el caos y lo hacés más rápido.

La parte que la industria vende poco

El mercado de la IA vende capacidades: modelos, agentes, integraciones. Es lo que se muestra fácil en una demo. La parte que casi nadie factura — y que decide si el proyecto sirvió para algo — es el acompañamiento del equipo que va a convivir con eso.

Por eso me pareció que valía la pena escribirlo. Yo puedo garantizar que la tecnología funcione. Que la empresa la use es una responsabilidad compartida, y la mitad de esa responsabilidad no es técnica.

Si estás por meter IA en tu empresa, hacete la pregunta antes de firmar nada: ¿ya sabés qué va a estar haciendo tu gente el día después de que esto funcione?

La conversación que originó este artículo fue con Mayra Regueira, Consultora Estratégica en Innovación & Negocios, que trabaja justamente el lado humano de estos procesos. Yo escribo sobre automatización con IA para empresas desde Varka, una consultora de IA enfocada en la trastienda operativa de los negocios. Si estás evaluando automatizar algo y querés una opinión sin humo, escribime.

Automatizar una distribuidora con IA en Argentina: los procesos reales y el stack que uso

Gonzalo Terrones — Mon, 20 Jul 2026 21:35:20 +0000

Trabajé más de 20 años en una distribuidora antes de dedicarme a la inteligencia artificial. Cuando alguien me pregunta "¿la IA sirve para una distribuidora?", la respuesta corta es: es de los rubros donde más se nota, porque el cuello de botella casi nunca es vender — es la montaña de tarea administrativa detrás de cada venta.

Esta es una guía concreta de qué se puede automatizar hoy, en 2026, en una pyme argentina real, y con qué stack lo armo.

El stack, en una línea

Nada exótico ni caro:

n8n (self-hosted) como orquestador de los flujos.
Un LLM (Claude / GPT) para las partes que requieren interpretar texto o archivos con formato variable.
Conexión por API a lo que el negocio ya usa: WhatsApp, el sistema de gestión, ARCA/AFIP, Google Sheets/DB.

El costo de la IA por operación suele ser de centavos. Lo que se paga es el armado y el mantenimiento, no un ERP de seis cifras.

1. Actualización de listas de precios (el clásico que a todos les duele)

El proveedor manda la lista nueva en un PDF o Excel con formato distinto cada vez, y alguien carga cientos de artículos a mano. Horas, con errores, y cuando terminás ya llegó otra lista.

El flujo:

Archivo del proveedor (PDF/Excel)
        |
        v
  Parser + LLM  ->  normaliza {codigo, descripcion, precio}
        |             (aunque cambie el formato de origen)
        v
  Validacion (codigo existe? variacion de precio razonable?)
        |
        v
  Update al sistema de gestion via API

La clave es usar el LLM solo para la parte difícil (interpretar un layout que cambia), no para hacer la matemática. Media jornada pasa a minutos. Es probablemente el proceso con mejor retorno, y casi nadie lo ofrece porque no es tan "vistoso" como un chatbot.

2. Pedidos por WhatsApp que se cargan solos

Tus clientes ya piden por WhatsApp; el problema es que una persona transcribe cada pedido al sistema. Un agente de IA lee el mensaje ("mandame 10 cajas de X y 5 de Y"), lo estructura, valida contra stock y lo deja listo para confirmar. El vendedor deja de ser transcriptor y vuelve a vender.

Técnicamente es una tool call: el mensaje libre entra, el modelo devuelve un objeto de pedido tipado (items[], cantidades, cliente), y ese objeto se valida antes de tocar el sistema.

3. Remitos y facturación automáticos

Al confirmar un pedido, el comprobante se genera solo: valida datos del cliente, emite la factura electrónica contra ARCA/AFIP, la manda por mail y WhatsApp, y actualiza el sistema contable. Sin copiar datos de una pantalla a otra.

4. Conciliación de stock

La eterna diferencia entre "lo que dice el sistema" y "lo que hay en el depósito". Un flujo que cruza entradas, salidas y ajustes, y avisa cuando algo no cuadra — antes de quedarte sin mercadería o comprar de más.

Dos consejos de ingeniería antes de automatizar nada

No automatices un proceso que está roto. Si tu carga de precios es un caos, primero ordenala. Automatizar el caos solo lo hace más rápido. La IA multiplica lo que ya tenés, para bien o para mal.
Validá siempre la salida del LLM antes de escribir en un sistema real. El modelo interpreta; tu código decide. Un precio con una variación del 400% o un código inexistente no deberían llegar nunca a producción sin un check determinístico en el medio.

Por dónde empezar

No intentes automatizar todo de una. Elegí el proceso que más horas te come por semana —en una distribuidora casi siempre es la carga de precios o la de pedidos— y arrancá por ahí. Medí cuántas horas te devuelve. Con ese primer resultado, el resto se justifica solo.

Escribo sobre automatización con IA para pymes argentinas desde Varka, una consultora enfocada en la trastienda operativa de los negocios (precios, stock, remitos, atención). Si tenés una distribuidora y querés ver qué se puede automatizar en tu caso, escribime — el diagnóstico inicial no cuesta nada.