Del WhatsApp al despacho: cómo automatizar pedidos sin perder el control
En 60 segundos: WhatsApp recibe la consulta y comunica avances; Teams muestra alertas y aprobaciones. El ERP, el sistema de almacén, la pasarela y el transportista conservan los registros operativos. El flujo valida al cliente, crea una sola versión del pedido, confirma el pago desde una fuente autorizada, reserva stock, libera la preparación y comunica el despacho. Los pagos dudosos, descuentos, cambios fiscales, faltantes, sustituciones y reclamaciones se detienen para revisión humana. Empezá con un tramo medible, usá claves idempotentes y mandá todo fallo a una cola con responsable y plazo.
Una consulta que llega por WhatsApp puede terminar en seis lugares distintos: el chat, una hoja, el ERP, Teams, el correo y el portal del transportista. El problema aparece cuando cada lugar cuenta una versión diferente del pedido.
Este artículo usa un caso compuesto y anónimo basado en patrones habituales de empresas que venden y despachan productos. No describe a una empresa concreta ni presupone que una herramienta tenga la integración necesaria. Cada API, conector, evento y permiso debe validarse con los sistemas elegidos.
El alcance empieza cuando el cliente consulta o confirma una compra. El seguimiento de prospectos anterior a ese momento pertenece a otro flujo, descrito en nuestra guía de seguimiento comercial por WhatsApp y Teams.
Una fuente de verdad por objeto
No hace falta que un solo sistema contenga todo. Sí hace falta acordar cuál registro manda cuando dos pantallas discrepan.
| Objeto | Fuente de verdad propuesta | Papel de WhatsApp y Teams |
|---|---|---|
| Cliente | CRM o maestro de clientes del ERP | WhatsApp aporta mensajes y consentimiento; Teams ayuda a resolver duplicados |
| Pedido | ERP o sistema de gestión de pedidos | WhatsApp recoge la solicitud; Teams presenta excepciones para aprobar |
| Pago | Banco o pasarela para el movimiento; ERP para la conciliación | WhatsApp puede entregar un enlace o recibir un comprobante, pero no confirma el abono |
| Inventario | ERP o WMS | El chat consulta disponibilidad publicada; el almacén resuelve diferencias físicas |
| Entrega | TMS o sistema del transportista | WhatsApp comunica estados confirmados; Teams alerta sobre incidencias |
| Factura | ERP o sistema contable autorizado | WhatsApp o correo entrega el documento ya emitido; Teams no conserva el original fiscal |
Esta separación evita que una respuesta en un chat cambie el estado comercial sin dejar rastro. WhatsApp y Teams son interfaces: acercan el proceso a clientes y empleados. El registro principal debe tener controles de acceso, historial y una forma estable de consultar el estado.
El flujo completo, con responsables y paradas
La siguiente matriz sirve para una sesión de diseño. Los nombres de sistemas son funciones, no una promesa sobre un producto específico.
| Etapa | Entrada | Decisión | Salida | Responsable | Parada o excepción |
|---|---|---|---|---|---|
| 1. Identificar | Mensaje entrante, teléfono e ID del mensaje | ¿Existe un cliente único y puede usarse este canal? | Cliente vinculado o caso por completar | Ventas o atención | Sin consentimiento, baja, coincidencias múltiples o datos insuficientes |
| 2. Confirmar pedido | SKU, cantidad, precio vigente, dirección y datos fiscales | ¿Coinciden catálogo, condiciones y política comercial? | Pedido confirmado en el ERP | Ventas | Descuento especial, cambio fiscal, producto ambiguo o aprobación pendiente |
| 3. Validar pago | Evento del banco o pasarela, importe, moneda y referencia | ¿El movimiento corresponde al pedido y supera los controles? | Pago conciliado o estado pendiente | Finanzas | Comprobante dudoso, importe distinto, reverso, riesgo o referencia ausente |
| 4. Reservar stock | Pedido pagado o condición de crédito aprobada | ¿Hay cantidad utilizable en la ubicación correcta? | Reserva y orden para almacén | Operaciones | Faltante, diferencia física, lote restringido, sustitución o pedido parcial |
| 5. Preparar y despachar | Orden liberada, picking, packing y etiqueta | ¿El paquete y el servicio cumplen el pedido? | Despacho con identificador de envío | Almacén y logística | Producto dañado, dirección inválida, peso distinto o transportista no disponible |
| 6. Informar entrega | Evento confirmado por el transportista | ¿El estado es nuevo y corresponde al envío? | Actualización al cliente y registro en el ERP | Logística | Evento contradictorio, entrega fallida, devolución o reclamación |
| 7. Entregar factura | Documento emitido y vinculado al pedido | ¿La versión fiscal está aprobada y disponible? | Enlace o adjunto entregado y trazable | Finanzas | Corrección fiscal, documento incompleto, destinatario dudoso o fallo de entrega |
Una parada no borra el trabajo anterior. Cambia el estado a revisión, asigna una persona y conserva el motivo. El cliente recibe una respuesta prudente, por ejemplo que el pedido está en validación, sin una promesa inventada de stock o fecha.
Qué puede avanzar solo y qué necesita una decisión
La automatización segura mueve datos y ejecuta reglas ya aprobadas. Puede validar campos obligatorios, buscar precios vigentes, crear una reserva después del estado autorizado, registrar eventos firmados por un proveedor, actualizar el seguimiento y enviar una plantilla elegible con contenido operativo confirmado. Cada acción conserva su origen y puede detenerse.
Una persona decide cuando el caso cambia dinero, obligaciones o la relación con el cliente: descuentos fuera de política, pagos dudosos, datos fiscales nuevos, diferencias de stock, sustituciones, entregas parciales, devoluciones y reclamaciones. También revisa cualquier texto que pueda convertirse en un compromiso especial. La automatización prepara el contexto y registra la resolución; no deduce la decisión a partir del chat.
Cómo recorrería el pedido este sistema
1. De la conversación a un borrador verificable
El mensaje entrante llega con un identificador del canal. La integración busca al cliente por un identificador estable y presenta cualquier coincidencia dudosa a ventas. Después estructura productos, cantidades, dirección y datos fiscales como borrador.
El borrador todavía no es un pedido confirmado. Una regla puede validar campos y precios publicados. Una persona revisa texto ambiguo, descuentos, condiciones especiales y cambios fiscales. Cuando todo cuadra, el ERP crea el pedido y devuelve su propio identificador.
2. Del pedido al pago conciliado
El sistema puede enviar instrucciones o un enlace de pago aprobado. El cambio a “pagado” debe venir de un evento auténtico de la pasarela o del banco, o de una conciliación aprobada por finanzas. Una captura enviada por WhatsApp es evidencia para revisar, no una orden para liberar mercancía.
El flujo compara pedido, importe, moneda, referencia y estado. Pagos parciales, duplicados, reversiones o diferencias quedan pendientes. Finanzas decide si concilia, rechaza o solicita información.
3. Del pago al almacén
Una política explícita determina si el inventario se reserva al confirmar el pedido, al aprobar crédito o al conciliar el pago. El ERP o WMS comprueba cantidad, ubicación, unidad y restricciones. Si todo coincide, genera una reserva y una tarea de preparación.
Un faltante no debería producir una sustitución silenciosa. Operaciones evalúa entrega parcial, cambio de producto, nueva fecha o cancelación, y ventas confirma con el cliente cuando corresponda.
4. Del paquete a la entrega documental
El almacén confirma picking y packing. El sistema de envíos devuelve la etiqueta y el identificador de seguimiento. Solo entonces el pedido pasa a despachado y se prepara el aviso al cliente.
Los eventos del transportista actualizan el seguimiento si avanzan desde el último estado válido. Una entrega fallida, devolución o reclamación pone el caso en pausa. La factura sale del sistema contable y se entrega cuando la versión correcta está disponible. El chat nunca genera por su cuenta una factura ni modifica sus datos.
Idempotencia, reintentos y estados incompletos
Los duplicados aparecen aunque el flujo parezca sencillo. Un cliente reenvía el mismo mensaje, un webhook llega dos veces o un servicio responde tarde y la plataforma reintenta.
Cada acción con efecto debe aceptar una clave idempotente. Para crear un pedido, puede combinar el identificador del negocio, el ID del mensaje o solicitud y el tipo de acción. Para pagos y envíos conviene conservar el identificador único que entrega el proveedor. Antes de repetir, el flujo consulta si esa clave ya produjo un pedido, una reserva, un aviso o un documento.
También necesita estados persistentes. Un vocabulario posible es recibido, faltan_datos, revision_manual, confirmado, pago_pendiente, pagado, excepcion_stock, listo_almacen, despachado, documento_pendiente, cerrado y pausa_manual. Cada cambio registra hora, actor, origen y motivo.
Los reintentos sirven para fallos transitorios. Deben tener espera creciente, un máximo y la misma clave idempotente. Un error de validación, un pago dudoso o una dirección incompleta no mejora al repetir. Esos casos van a una cola de excepciones con:
- motivo legible y datos que faltan
- enlace al pedido y al evento original
- responsable, prioridad y plazo de atención
- acción para reanudar, cancelar o mantener la pausa
- historial de intentos sin datos sensibles innecesarios
El tablero debe mostrar estados incompletos que envejecen. Un pedido en documento_pendiente durante horas puede requerir atención aunque el despacho haya terminado bien.
Reglas actuales de WhatsApp que afectan el diseño
La Política de mensajería de WhatsApp Business exige que la persona haya entregado su número y aceptado recibir mensajes posteriores. La empresa también debe respetar las solicitudes de baja. Conviene guardar la fuente, fecha y alcance del consentimiento en el registro del cliente.
En la plataforma de WhatsApp Business, la empresa solo puede iniciar conversaciones con plantillas aprobadas. Puede responder sin plantilla dentro de las 24 horas posteriores al último mensaje del usuario; fuera de esa ventana debe usar una plantilla aprobada. La misma política permite automatización durante esa ventana si existen vías claras y directas para escalar a una persona.
Por eso una actualización de pedido necesita elegibilidad, plantilla, idioma y evento operativo confirmado. Una reclamación debe detener la secuencia rutinaria y ofrecer atención humana. Estas reglas se verificaron en la política oficial el 10 de septiembre de 2026, pero Meta puede actualizarlas. Revisalas de nuevo con Meta y con el proveedor antes de publicar o activar el flujo. El caso de negocio no debe depender de una tarifa fija.
Un piloto por etapas
Antes de elegir herramientas, aplicá el método de qué automatizar primero a esta cadena. Elegí el tramo con datos fiables, reglas claras y un responsable disponible.
- Mapeá diez o veinte pedidos recientes, incluidos duplicados, faltantes y reclamaciones. Definí estados, fuentes de verdad, permisos y responsables. Medí la situación actual.
- Automatizá desde pedido confirmado hasta la tarea de almacén. Mantené manuales el pago dudoso, las excepciones de inventario y los mensajes externos.
- Incorporá eventos verificados de pago y despacho. Probá duplicados, reintentos, caídas y reversiones antes de ampliar volumen.
- Agregá avisos de WhatsApp con plantillas aprobadas y escalamiento humano. Empezá con un solo tipo de actualización y un grupo acotado.
- Entregá la factura o documento ya emitido y medí pendientes. Ampliá el piloto solo cuando la cola de excepciones tenga capacidad y dueño.
Medí la mediana y el percentil 95 desde pedido confirmado hasta liberación de almacén, y desde liberación hasta despacho. Añadí porcentaje de pedidos duplicados, casos que entran en excepción, reintentos recuperados, tiempo de revisión humana, despachos con seguimiento enviado y pedidos con factura entregada. Vigilá también bajas, bloqueos y reclamaciones relacionadas con mensajes.
El volumen procesado por sí solo dice poco. El piloto funciona cuando reduce esperas sin aumentar pedidos incorrectos, promesas falsas o trabajo invisible. Si una etapa produce demasiadas excepciones, acotá el flujo y corregí los datos o la política antes de continuar.
Qué construiría Kiia primero
Kiia empezaría con el mapa de estados, una sola fuente de verdad por objeto y el tramo entre pedido confirmado y liberación de almacén. Añadiría después el evento de pago, el despacho y la comunicación al cliente, siempre con auditoría y pausas manuales.
Una primera versión útil no necesita decidir por las personas. Necesita entregarles los casos sensibles con suficiente contexto y dejar que el trabajo rutinario avance sin perder trazabilidad.
Preguntas frecuentes
¿Puede WhatsApp ser la fuente de verdad del pedido?
No. WhatsApp conserva la conversación, pero el pedido confirmado debe vivir en el ERP o sistema transaccional elegido. El mensaje puede iniciar una acción sin sustituir ese registro.
¿Se puede marcar un pedido como pagado a partir de un comprobante enviado por chat?
No de forma automática. El estado pagado debe proceder del banco, la pasarela o una conciliación aprobada. Un comprobante dudoso, un importe distinto o una referencia ausente requieren revisión humana.
¿Qué decisiones deben conservar aprobación humana?
Descuentos fuera de política, pagos dudosos, cambios fiscales, excepciones de stock, sustituciones, compromisos especiales de entrega y reclamaciones.
¿Cómo se evita crear dos pedidos por el mismo mensaje?
Cada operación usa una clave idempotente, conserva los identificadores del canal y del ERP, y comprueba el resultado previo antes de reintentar. Los casos ambiguos pasan a una cola de excepciones.
De la idea a la acción
¿Quieres convertir esto en un agente que trabaje para tu equipo?
Cuéntanos qué proceso quieres mejorar. En una llamada gratuita identificaremos el primer flujo que vale la pena construir.