¿El agente de pedidos debe sustituir el ERP o el OMS?

No. El ERP o el OMS sigue siendo la fuente de verdad del pedido. WhatsApp, Teams y los formularios web aportan solicitudes y muestran avances; el agente valida datos y coordina acciones autorizadas mediante interfaces controladas.

¿Qué acciones del pedido necesitan aprobación humana?

Durante el piloto, una persona debe aprobar la creación o los cambios relevantes del pedido, cancelaciones, sustituciones, precios excepcionales, cambios fiscales y cualquier acción basada en datos ambiguos. Los avisos de estado verificados pueden ganar autonomía acotada antes.

¿Qué debe medir un piloto de dos semanas?

Medí pedidos procesados sin recaptura manual, excepciones por motivo, tiempo de resolución, escrituras duplicadas evitadas, correcciones de estado y antigüedad de la cola. Compará contra una línea base documentada y no conviertas el resultado en una afirmación de ROI sin sustento.

Cómo hacer un agente de pedidos, desde intake hasta despacho

En 60 segundos: Construí el agente alrededor del ERP o sistema de gestión de pedidos, que conserva la fuente de verdad de cada pedido. Canales como WhatsApp, Teams y formularios web aportan solicitudes; no se convierten en el registro transaccional. Asigná un nivel de control a cada acción: la lectura puede ser amplia, la creación o modificación relevante empieza con aprobación, los avisos de estado verificados pueden volverse autónomos dentro de una política acotada y la cancelación sigue controlada. Conectá el agente con la API del ERP, inventario, notificaciones y una cola de excepciones con responsable. Ejecutá un piloto de dos semanas y medí pedidos sin recaptura, bloqueos y tiempo de resolución. Si los maestros de clientes, productos, impuestos, direcciones o inventario no son fiables, corregilos antes de habilitar escrituras.

Un pedido suele empezar como un mensaje incompleto y terminar como trabajo para el almacén. Entre esos puntos, alguien identifica al cliente, recaptura productos, confirma datos fiscales, consulta stock, concilia el pago y avisa a varias personas qué cambió. Un agente puede coordinar esos pasos cuando las reglas y los registros ya existen.

Este playbook cubre la construcción de ese coordinador. El mapa operativo de WhatsApp a despacho explica el recorrido completo por pago, almacén, transportista y factura. Acá el límite es más estrecho: entra un intake validado, se crea o actualiza el pedido en el sistema autorizado, los estados de inventario y despacho se mantienen sincronizados y cada caso sin resolver llega a una persona.

No especifica un WMS completo, routing de flota ni la operación de motorizados. El agente tampoco fija política comercial, aprueba crédito ni deduce que un pago fue conciliado.

Definí el trabajo y su punto de parada

Escribí el objetivo como una transición de estado observable:

solicitud validada -> pedido autorizado -> estado de stock o despacho -> actualización registrada

“Validada” significa que la solicitud tiene un cliente conocido o una ruta controlada para crearlo, productos y unidades reconocidos, campos fiscales obligatorios, una dirección atendible y contexto suficiente para aplicar la política comercial. Un mensaje fluido no equivale a una validación.

El agente termina cuando logra una de estas salidas:

escribe el estado permitido en el ERP u OMS y guarda el identificador devuelto; o
coloca el caso bloqueado en la cola de excepciones con motivo, responsable, evidencia y acción necesaria.

Este límite evita que un conector caído o un campo faltante desaparezca dentro de un chat. También le da un denominador a operaciones: cada intake elegible debe terminar en un estado registrado del pedido o en una excepción visible.

Conservá el ERP o el OMS como fuente de verdad

El canal aporta evidencia e intención. El ERP o el OMS controla el número de pedido, las líneas, los precios aprobados, el tratamiento fiscal, el vínculo con el cliente y el estado. Si el inventario se gestiona por separado, el ERP o el WMS controla cantidad disponible, reservas, ubicaciones y liberación.

Registro	Fuente autorizada	Qué puede hacer el agente
Cliente y perfil fiscal	ERP o maestro de clientes aprobado	Encontrar una coincidencia exacta, validar campos obligatorios o pedir revisión
Producto, unidad y precio	Catálogo del ERP y reglas de precio aprobadas	Resolver IDs estables y rechazar valores ambiguos o vencidos
Pedido	ERP u OMS	Crear o actualizar mediante un comando idempotente y releer el resultado
Inventario	ERP o WMS	Consultar disponibilidad, pedir una reserva y conservar el estado devuelto
Pago	Banco, proveedor o proceso de conciliación aprobado	Leer un resultado verificado; nunca inferir la conciliación desde una imagen del comprobante
Despacho	WMS, TMS o sistema del transportista	Leer eventos confirmados y actualizar el pedido mediante transiciones permitidas
Conversación	WhatsApp, Teams o canal web	Conservar la referencia de origen y comunicar información aprobada
Excepción	Cola compartida de operaciones	Asignar bloqueo, decisión, evidencia y resolución

Evitá mantener un “estado del agente” paralelo que pueda contradecir al ERP. La capa de orquestación puede guardar IDs de correlación, intentos y eventos de auditoría, pero relee el estado de negocio antes de actuar y devuelve el resultado al sistema autorizado.

La guía sobre el coste de copiar datos entre sistemas ayuda a localizar los traspasos donde el equipo recaptura estos registros. Eliminar esa recaptura es un objetivo más preciso que “automatizar pedidos”.

Los datos maestros limpios son una dependencia

El agente necesita IDs estables de cliente, códigos SKU, unidades de medida, ubicaciones de almacén, categorías fiscales, monedas, reglas de dirección y transiciones de estado permitidas. Un producto descrito como “el azul grande” puede ser claro para el vendedor y seguir siendo inseguro para una API del ERP.

Antes de habilitar escrituras, probá pedidos recientes para encontrar:

clientes duplicados o sin coincidencia;
SKU inactivos, alias, empaques y unidades inconsistentes;
identificadores fiscales faltantes o perfiles fiscales en conflicto;
direcciones que no pueden validarse contra la cobertura de entrega;
registros de stock que no reflejan reservas, bloqueos o la ubicación correcta; y
estados de pedido con significados distintos para ventas, finanzas y operaciones.

Asigná un responsable a cada maestro. El agente puede mostrar una coincidencia incierta y preparar una corrección, pero no debe fusionar clientes, inventar el mapeo de un SKU o reparar un perfil fiscal por su cuenta. Cuando estos fallos dominan la muestra, el primer proyecto es limpiar datos y definir estados.

Asigná un nivel de control por acción

El control pertenece a la acción, no al agente completo. El marco de copiloto o piloto automático: cinco niveles de control desarrolla el método. Una matriz inicial para pedidos puede ser esta:

Acción	Control durante el piloto	Condiciones para aumentar autonomía
Leer cliente, catálogo, pedido e inventario	Lectura o recomendación	Se verificaron scopes de mínimo privilegio, filtros de campos y registros de acceso
Estructurar el intake como borrador de pedido	Borrador	Cada valor extraído enlaza a su origen y los campos dudosos quedan vacíos
Crear el pedido o cambiar líneas, cantidad, precio, impuestos o dirección	Ejecución aprobada	La autonomía posterior se limita a un segmento documentado con maestros válidos, controles deterministas, idempotencia y recuperación probada
Informar un estado	Borrador en casos ambiguos; autonomía acotada ante eventos verificados	El estado viene de la fuente autorizada, el destinatario y el consentimiento son válidos, y la plantilla no promete nada nuevo
Reservar stock o liberar trabajo al almacén	Ejecución aprobada	La política de liberación, la condición de pago o crédito, ubicación, cantidad y reversión pueden validarse por máquina
Sustituir, dividir o dejar pendiente una línea	Ejecución aprobada	Conservá la aprobación cuando la elección cambia precio, fecha, producto o compromiso con el cliente
Cancelar un pedido	Ejecución aprobada	Verificá identidad, ventana de cancelación, estado del envío, efectos financieros y reversión aguas abajo antes del comando

La aprobación debe quedar ligada al payload exacto. Si una persona aprueba la versión 3 del pedido y la dirección o las líneas cambian antes de ejecutar, la aprobación vence. Releé cada escritura desde el ERP y guardá quién o qué la ejecutó.

Dale cuatro herramientas operativas

El modelo no debe recibir una credencial genérica ni acceso irrestricto a la base de datos. Exponé herramientas acotadas con esquemas explícitos, permisos, timeouts y campos de auditoría.

API del ERP u OMS. Busca por identificadores estables, valida la versión actual, crea o actualiza con una clave idempotente y devuelve el ID canónico y el estado. Separá comandos de lectura y escritura.
Interfaz de inventario. Lee stock disponible para promesa por SKU, unidad, ubicación y momento; solicita la reserva solo cuando la política lo permite; devuelve faltantes y disponibilidad parcial como resultados estructurados.
Servicio de notificaciones. Envía una plantilla aprobada a un destinatario elegible o crea una alerta interna. Recibe hechos confirmados en vez de afirmaciones libres sobre stock, pago o entrega.
Cola de excepciones. Crea y actualiza casos con códigos de motivo, reglas de prioridad, responsable, referencias de soporte, decisión requerida y timestamps. Una respuesta en Teams sirve solo cuando la resolución vuelve a esta cola y al registro del pedido.

Colocá controles deterministas entre el modelo y cada efecto externo. La capa de comandos verifica campos obligatorios, transiciones permitidas, versión, alcance del permiso y clave idempotente. El agente puede elegir qué herramienta aprobada solicitar; la herramienta decide si la solicitud cumple el contrato.

Construí el flujo feliz como una máquina de estados

Un vocabulario compacto puede incluir received, needs_data, draft, pending_approval, confirmed, stock_exception, ready_for_dispatch, dispatched, manual_hold y cancelled. Usá los estados que ya admite el ERP siempre que sea posible y documentá cada transición permitida.

El flujo feliz tiene siete pasos:

El adaptador del canal registra ID del mensaje o formulario de origen, hora, canal y contexto de negocio autorizado.
El agente estructura cliente, líneas, unidades, cantidades, dirección solicitada y datos fiscales recibidos. La validación informa los valores faltantes o ambiguos sin completarlos por intuición.
La integración resuelve IDs estables de cliente y producto, lee política y estado actuales, y genera una clave idempotente para la acción propuesta.
Durante el piloto, una persona aprueba el payload exacto. El ERP u OMS crea o actualiza el pedido y devuelve ID canónico, versión y estado.
La herramienta de inventario consulta la ubicación correcta y solicita la reserva o liberación al almacén solo cuando lo permiten el pedido, la condición de pago o crédito y la política de stock.
Los eventos confirmados de almacén y despacho avanzan el pedido por estados permitidos. La herramienta de notificaciones comunica solo el estado releído desde la fuente autorizada.
Una conciliación compara intake elegible, pedidos del ERP, reservas y notificaciones. Los registros ausentes o en conflicto se convierten en excepciones visibles.

Los reintentos reutilizan la clave idempotente original. Un timeout puede justificar un nuevo intento después de comprobar el resultado anterior. Un dato fiscal inválido, una dirección rechazada o un faltante de stock no mejora por repetición.

Enrutá excepciones con contexto suficiente

La cola de excepciones forma parte del producto. Cada caso necesita la referencia canónica del pedido o intake, un código de motivo, enlaces a evidencia saneada, estado actual, decisión solicitada, responsable y hora de entrada. Conservá la PII del cliente en su fuente autorizada y mostrá solo el mínimo necesario para el rol asignado.

Excepción	Respuesta del agente	Responsable humano	Evidencia para reanudar
Stock insuficiente	Detiene la liberación, muestra cantidades solicitadas y disponibles por ubicación, y propone opciones permitidas sin elegir una	Operaciones o ventas	Entrega parcial, sustitución, nueva fecha, traslado o cancelación aprobada
Datos fiscales faltantes	Mantiene el pedido en `needs_data` e identifica el campo ausente	Ventas, atención al cliente o finanzas	Perfil fiscal validado en la fuente de verdad
Pago no conciliado	Mantiene el pago pendiente y bloquea cualquier liberación que dependa de la política	Finanzas	Evento verificado del proveedor o conciliación aprobada y vinculada al pedido
Dirección inválida	Detiene el despacho, identifica la regla incumplida y solicita corrección	Atención al cliente o logística	Dirección validada y resultado de cobertura

El mismo patrón sirve para clientes duplicados, precios vencidos, caídas de conectores y eventos de despacho contradictorios. Fijá los tiempos de resolución según los compromisos operativos actuales del equipo. La cola debe mostrar casos vencidos sin inventar un SLA genérico.

Ejecutá un piloto de dos semanas con línea base

Elegí una línea de negocio, un tipo de pedido, una política de almacén o ubicación y un grupo claro de responsables. Excluí condiciones comerciales inusuales hasta que el camino ordinario y sus excepciones sean observables.

Durante la primera semana, reproducí casos recientes anonimizados en modo sombra y procesá el nuevo intake elegible con aprobación antes de cada escritura. Registrá los pasos actuales de recaptura y compará el payload propuesto por el agente con el pedido que operaciones aceptó. Corregí esquemas, datos maestros, scopes de permisos y códigos de motivo a medida que aparezcan fallos.

Durante la segunda semana, mantené aprobadas la creación y las modificaciones relevantes. Permití automatización acotada solo en acciones de bajo impacto que hayan superado la primera semana, por ejemplo registrar un estado interno verificado o enviar una plantilla aprobada desde un evento confirmado. Probá entregas duplicadas, respuestas tardías, versiones vencidas, caídas de servicios, intentos de cancelación y cada excepción de negocio nombrada.

Definí las medidas antes de iniciar el piloto:

Medida	Definición para el piloto
Pedidos sin recaptura	Pedidos elegibles creados o actualizados sin que el equipo copie los mismos campos al ERP, dividido por todos los pedidos elegibles
Tasa de bloqueos	Excepciones divididas por intake elegible, agrupadas por stock, datos fiscales, pago, dirección, maestros, política y fallo técnico
MTTR de excepción	Tiempo desde la entrada en cola hasta una resolución registrada o decisión terminal válida; informá mediana y un percentil alto junto con la antigüedad de los casos abiertos
Calidad de escritura	Pedidos corregidos después de la escritura del agente, intentos de transición no autorizada bloqueados y escrituras duplicadas evitadas
Calidad de avisos	Actualizaciones enviadas desde un estado verificado, notificaciones fallidas o repetidas y avisos corregidos por el equipo
Carga de revisión	Casos revisados, cambios durante la aprobación y tiempo dedicado por aprobadores y responsables de excepciones

Informá conteos y denominadores. Separá fallos de integración, datos maestros deficientes y política sin resolver. Compará las dos semanas con la línea base documentada; no extrapoles throughput ni ROI desde una muestra pequeña.

Pausá el piloto si el agente puede escribir fuera de alcance, la cola de excepciones pierde responsable, la conciliación no explica un pedido ausente o el equipo debe reparar errores ocultos. Reanudalo cuando el problema de control o datos tenga una corrección probada.

Cuándo un agente de pedidos no es el próximo proyecto

No habilites este agente cuando los maestros de clientes y productos carecen de identificadores fiables, el stock físico suele contradecir al sistema de inventario o los equipos no acuerdan qué significa cada estado. Tampoco conviene cuando el ERP no tiene una interfaz de escritura controlada y el equipo no puede añadir idempotencia, historial de auditoría o conciliación.

Mantené el proceso manual cuando el volumen de pedidos no justifica mantener la integración, las excepciones dominan el trabajo ordinario o nadie se hace cargo de la cola. Corregí primero la política cuando precios, crédito, impuestos, cancelación o liberación dependen de criterios no documentados.

Si el problema anterior es demanda descuidada y no ejecución del pedido, empezá con el agente de seguimiento comercial. Cuando el comprador confirma la solicitud, el agente de pedidos puede tomar el relevo desde el intake validado sin mezclar persuasión comercial con autoridad operativa.

Kiia puede mapear la máquina de estados, definir los contratos de herramientas y ejecutar este piloto contra tus sistemas actuales. Traé pedidos recientes anonimizados que incluyan casos rutinarios y bloqueos; alcanzan para identificar el primer límite seguro.