Un cambio en un pedido de cliente parece sencillo hasta que ya existen una reserva de stock, una orden de preparación, una fecha prometida, una expedición en curso o una factura. Si la petición llega por teléfono, correo o un comentario en el CRM y alguien modifica un dato sin comprobar el estado real, ventas puede prometer algo que almacén no puede servir o finanzas puede conservar una condición que ya no corresponde.
La automatización puede convertir esas peticiones en casos trazables y la IA puede ayudar a interpretar mensajes, detectar los datos que faltan y preparar el expediente. Ninguna de las dos debe decidir por sí sola un cambio de precio, una anulación, una dirección sensible o una modificación que afecte a una expedición ya iniciada. Esas decisiones necesitan reglas aprobadas y una persona responsable.
El objetivo no es actualizar un campo, sino mantener una versión coherente del pedido
Un pedido conecta varias decisiones: qué se vende, a quién, en qué cantidad, con qué condición comercial, desde qué ubicación y en qué fecha. Por eso, una modificación debe comprobar qué partes del proceso ya se han ejecutado y qué sistemas necesitan recibir el cambio.
La unidad de trabajo útil es un expediente de cambio. Debe relacionar el pedido original, la solicitud recibida, el motivo, los datos propuestos, las comprobaciones realizadas, la decisión, las acciones ejecutadas y la comunicación final al cliente. Así se puede explicar por qué se aceptó, rechazó o limitó una petición.
Clasifique las solicitudes antes de automatizar su tratamiento
No todos los cambios tienen el mismo riesgo ni requieren el mismo circuito. Empiece por una clasificación corta, alineada con la operación real:
- cambio de cantidad o de referencias;
- cambio de fecha o de franja de entrega;
- cambio de dirección, persona de contacto o instrucciones logísticas;
- cancelación total o parcial;
- cambio de condición comercial, descuento o forma de pago;
- corrección de datos administrativos.
Para cada tipo, acuerde qué puede resolverse con reglas, qué debe comprobarse en el ERP, qué situaciones bloquean el cambio y quién puede aprobar una excepción. Una corrección de contacto no tiene el mismo impacto que reducir una línea ya preparada o cambiar una dirección después de generar la etiqueta de transporte.
Recoja una petición verificable
El flujo debe identificar el pedido antes de proponer una acción. Si llega por correo o formulario, la IA puede extraer una referencia, una fecha solicitada o una dirección; si hay ambigüedad, debe crear una tarea para completar la información, no adivinar.
Como mínimo, guarde el origen de la petición, quién la solicita, el pedido y líneas afectadas, el cambio solicitado, el momento en que se recibe y cualquier evidencia adjunta. Si la persona que pide el cambio no coincide con el contacto autorizado, el caso debe quedar retenido hasta su verificación.
Consulte el estado operativo antes de modificar nada
La misma solicitud produce respuestas distintas según el punto en el que se encuentra el pedido. Antes de cambiarlo, consulte la fuente que gobierna cada estado: pedido confirmado, crédito, reserva, preparación, expedición, entrega, factura y cobro. Evite reconstruir ese estado a partir de correos o notas manuales.
El sistema puede marcar reglas como estas: no modificar una línea ya facturada sin un procedimiento contable; no cambiar la dirección si el transportista ya ha recogido la mercancía; no liberar una reserva adicional sin comprobar disponibilidad; no cancelar una cantidad entregada. La regla debe mostrar el motivo del bloqueo y la siguiente persona que debe revisar el caso.
Separe la propuesta de la ejecución
Una automatización puede preparar una propuesta: qué líneas cambiarían, qué reserva se liberaría o solicitaría, qué fecha es compatible con la planificación y qué documentos o comunicaciones habría que actualizar. La ejecución debe producirse solo cuando el caso cumple la política o una persona autorizada la aprueba.
Esta separación evita que un mensaje mal interpretado modifique un pedido vivo. También permite revisar el impacto antes de tocar ERP, CRM, almacén o plataforma de transporte. Cuando se apruebe, use una única acción controlada para aplicar el cambio y registre el identificador de la operación resultante.
Diseñe las reglas de decisión con negocio y operaciones
Las reglas no deben esconderse dentro de un prompt. Documente para cada tipo de cambio qué condiciones deben cumplirse, qué datos se consultan, quién decide y qué ocurre si falta información. Por ejemplo, una modificación de fecha podría aceptarse si no existe preparación iniciada y hay capacidad confirmada; en caso contrario, puede requerir coordinación con logística.
También defina límites claros: cambios de precio, descuentos, cancelaciones con penalización, cambios de destinatario de riesgo o modificaciones tras una factura requieren una revisión explícita. La IA puede resumir antecedentes y redactar una comunicación, pero no debe interpretar contratos ni conceder excepciones comerciales.
Propague el cambio sin crear versiones contradictorias
Cuando el cambio se aprueba, el problema siguiente es la sincronización. Determine cuál es el sistema maestro del pedido y qué destinos reciben la actualización: CRM, ERP, gestor de almacén, plataforma de transporte, facturación o portal de cliente. No permita que cada equipo corrija su copia por separado.
La integración debe conservar la referencia del pedido y del expediente de cambio, registrar el resultado por destino y detectar operaciones repetidas. Si un destino no confirma, el caso no está cerrado: debe pasar a una cola de excepción con el dato que falta, el error técnico y una acción concreta para recuperarlo.
Comunique una decisión, no una promesa automática
El cliente necesita una respuesta comprensible: cambio aceptado, aceptado con alternativa, pendiente de confirmación o no posible por un motivo operativo. La automatización puede preparar el mensaje a partir de la decisión registrada, pero no debe enviar una nueva fecha o condición si no está confirmada en la fuente correspondiente.
Conserve la versión comunicada y el canal empleado. Si la petición cambia el compromiso de entrega, informe también a las personas internas que dependen de él; de lo contrario, el cliente puede recibir una respuesta correcta mientras el almacén trabaja con una instrucción anterior.
Trate las excepciones como trabajo visible
Habrá casos que no encajen: pedido sin referencia, petición duplicada, líneas parcialmente expedidas, discrepancia entre CRM y ERP, cambio urgente o datos del solicitante insuficientes. No los resuelva con una regla improvisada ni los deje en una bandeja genérica.
Asigne cada excepción a un equipo y conserve un estado claro: pendiente de información, pendiente de aprobación, en ejecución, bloqueada o cerrada. Mida la calidad por la capacidad de explicar y recuperar cada caso, no por el número de modificaciones realizadas automáticamente.
Cómo empezar con un alcance controlado
Elija un solo tipo de cambio frecuente y acotado, como la corrección de datos administrativos antes de la preparación. Documente el flujo actual, identifique el sistema maestro, defina campos obligatorios, pruebe casos válidos y bloqueados y confirme que la comunicación refleja el estado final.
Después añada cambios de cantidad, fecha o dirección solo cuando pueda demostrar que las comprobaciones, aprobaciones y sincronizaciones funcionan. Si quieres convertir este proceso en una solución conectada a tu ERP, CRM y herramientas de almacén, KMOOPS puede ayudarte con automatización de procesos diseñada alrededor de tus reglas operativas. Para revisar el alcance, contacta con el equipo.
Qué revisar antes de ponerlo en producción
- ¿El flujo identifica de forma fiable el pedido y a la persona solicitante?
- ¿Cada tipo de cambio tiene condiciones, límites y un responsable definidos?
- ¿Se consulta el estado real de reserva, preparación, expedición y factura antes de proponer el cambio?
- ¿Las excepciones comerciales, logísticas y contables quedan fuera de la ejecución automática?
- ¿Existe un registro de la solicitud, la decisión, la operación aplicada y la comunicación enviada?
- ¿Puede recuperarse una actualización fallida sin duplicar acciones en los sistemas conectados?
Si alguna respuesta es no, el siguiente paso no es añadir más IA: es concretar la regla, la fuente de verdad o el circuito de decisión que falta.