Un cliente que pide cambiar la dirección, retirar un producto o cancelar una compra necesita saber si todavía es posible actuar. Para responder bien, un agente de IA para retail no puede basarse únicamente en la hora de compra ni en una política general: debe consultar el estado real del pedido, aplicar las reglas del comercio y confirmar la acción en el sistema que controla el fulfillment.
Este caso de uso se concentra en una ventana concreta: desde que el pedido fue confirmado hasta que queda preparado o despachado. Allí, unos minutos pueden determinar si el cambio se resuelve como autoservicio, necesita una pausa operativa o debe transformarse en devolución después de la entrega.
Seelai puede conectar el canal donde llega la solicitud con el inbox omnicanal, el CRM, el OMS o ERP y los webhooks de logística. El agente entiende la intención y reúne los datos mínimos; las reglas y el sistema operativo deciden qué acción sigue disponible; y el equipo recibe las excepciones con contexto.
Por qué cambiar un pedido no es solo editar una conversación
En retail, el pedido avanza aunque el cliente no vea cada transición. Puede pasar de pago autorizado a preparación, asignación de bodega, picking, packing y despacho en poco tiempo. Una respuesta que llega tarde puede ofrecer una cancelación cuando el paquete ya salió o modificar en el CRM una dirección que nunca llegó al operador logístico.
Microsoft Dynamics 365 Commerce documenta que la posibilidad de cancelar depende del estado: si la opción no está disponible, el pedido se encuentra en una etapa que ya no permite esa operación. Su documentación de fulfillment también distingue líneas pendientes, aceptadas, recogidas, empacadas y enviadas. La lección es aplicable a cualquier arquitectura: la conversación no define si el cambio es posible; el estado confirmado del pedido sí.
Los fallos más frecuentes aparecen cuando canal y operación están separados:
- El cliente escribe por WhatsApp, correo o webchat, pero la solicitud espera en una bandeja personal.
- El asesor consulta una copia desactualizada del pedido o debe preguntar a bodega.
- Se promete una cancelación antes de que el OMS confirme el resultado.
- El CRM registra una dirección nueva, pero el sistema de fulfillment conserva la anterior.
- Dos personas intentan editar el mismo pedido desde canales distintos.
- El pago se reversa, pero la orden sigue liberada para preparación, o sucede lo contrario.
- Cuando el cambio ya no es posible, el cliente no recibe una alternativa clara.
Qué solicitudes puede coordinar el agente
Un piloto debe empezar con acciones frecuentes, estados bien definidos y reglas estables. Por ejemplo:
- Cancelar el pedido completo antes de que entre a una etapa no reversible.
- Retirar una línea que todavía no fue preparada, cuando el OMS lo permite.
- Solicitar un cambio de dirección antes de la liberación logística.
- Cambiar la modalidad entre envío y recogida, si inventario, sede y política lo admiten.
- Corregir datos de contacto que no cambian la identidad ni el riesgo de la transacción.
- Poner el fulfillment en pausa mientras una persona revisa una excepción.
- Comunicar por qué ya no puede hacerse el cambio y cuál es el proceso posterior permitido.
El agente no debería cambiar precio, medio de pago, destinatario, producto regulado, condición fiscal o dirección de alto riesgo sin las validaciones correspondientes. Tampoco debe convertir automáticamente una solicitud ambigua —como “ya no lo necesito”— en una cancelación irreversible.
Flujo manual vs. cambios de pedido conectados
| Momento | Gestión fragmentada | Agente conectado al OMS o ERP |
|---|---|---|
| Solicitud | Queda como mensaje libre | Se identifica pedido, intención y cambio solicitado |
| Estado | El asesor pregunta a otra área | Se consulta el estado operativo vigente |
| Elegibilidad | Depende de interpretación manual | Una política versionada devuelve acciones permitidas |
| Pausa | Bodega puede seguir preparando | Un hold confirmado detiene temporalmente el flujo permitido |
| Ejecución | Se actualizan sistemas por separado | Una acción acotada escribe en la fuente oficial |
| Confirmación | Se responde antes de conocer el resultado | El cliente recibe el estado devuelto por el sistema |
| Excepción | El equipo reconstruye el caso | El handoff incluye bloqueo, evidencia y siguiente paso |
Flujo recomendado paso a paso
1. Identifica el pedido sin recopilar datos de más
El agente solicita el identificador de pedido y los datos mínimos definidos para localizarlo. Si el contacto ya está autenticado en una cuenta o sesión, puede reutilizar ese contexto autorizado. Un número de teléfono o un mensaje desde un canal conocido no deberían bastar por sí solos para permitir cambios sensibles.
El sistema debe buscar pedidos posibles, detectar ambigüedades y pedir confirmación antes de mostrar detalles. También debe reconocer si ya existe una solicitud abierta para evitar que un segundo mensaje cree una operación duplicada.
2. Consulta el estado en la fuente operativa
El agente consulta el OMS, ERP o plataforma de comercio para conocer pago, líneas, ubicación de fulfillment y etapa logística. No interpreta “pedido confirmado” como sinónimo de “cancelable”: la elegibilidad puede cambiar entre la respuesta del canal y la ejecución.
La consulta debe devolver estados estructurados y acciones disponibles. Si la integración está caída o la información es contradictoria, el agente comunica que no pudo confirmar el cambio y abre una revisión; no inventa un resultado probable.
3. Evalúa reglas de cambio y riesgo
Una matriz versionada combina estado, tipo de producto, método de entrega, pago, ventana de tiempo, país y señales de riesgo. Su salida no es una frase libre, sino una ruta operativa: ejecutar, solicitar confirmación adicional, pausar para revisión, ofrecer una alternativa o informar que el pedido ya pasó a devolución.
Estas reglas deben vivir fuera del prompt y tener propietario de negocio. Así, una política actualizada puede cambiar el comportamiento sin depender de que el modelo recuerde una instrucción histórica.
4. Coloca una pausa cuando el sistema lo permita
Si se necesita revisar una dirección, una línea o una excepción, el workflow puede aplicar un hold limitado antes de que el fulfillment avance. Shopify, por ejemplo, expone una operación específica para poner una orden de fulfillment en espera y exige permisos de escritura sobre el fulfillment correspondiente.
Una pausa no equivale a una cancelación. Debe tener motivo, responsable, vencimiento y una ruta para liberarla. Si el hold falla, el agente no debe decir que el pedido está detenido.
5. Pide confirmación para acciones irreversibles
Antes de cancelar, retirar líneas o cambiar un dato material, el agente resume qué pedido y qué elementos se afectarán, además de costos, tiempos o consecuencias conocidas. La aceptación del cliente se registra junto con la versión de la política aplicada.
OWASP identifica la agencia excesiva como un riesgo cuando una aplicación basada en modelos tiene funciones, permisos o autonomía innecesarios. En este flujo, la mitigación práctica es ofrecer al agente herramientas específicas —consultar, pausar, solicitar cancelación— y dejar que el sistema de destino valide autorización y estado en cada ejecución.
6. Ejecuta con una acción idempotente y permisos mínimos
Cada solicitud usa un identificador único. Si un webhook o el agente reintenta la operación, el sistema debe devolver el resultado existente o continuar el mismo proceso, no cancelar dos veces ni crear ajustes duplicados.
Los permisos deben separar lectura, pausa, edición y cancelación. La integración conversacional no necesita acceso general a precios, reembolsos, inventario y clientes para resolver un cambio acotado.
7. Confirma solo después de recibir el resultado
El mensaje final se genera a partir del estado devuelto por el OMS o ERP: cancelación aceptada, cambio confirmado, revisión pendiente o acción rechazada. CRM e inbox conservan el mismo resultado, el responsable y el siguiente paso.
Cuando existen depósitos, cargos o reembolsos, la comunicación debe diferenciar cancelación del pedido y movimiento financiero. La documentación de Dynamics 365 Commerce muestra que una cancelación puede involucrar cargos y operaciones de pago; por eso, no conviene presentar ambos estados como una sola acción instantánea.
8. Escala con una alternativa concreta
Si el pedido ya fue preparado o despachado, el agente explica el límite y ofrece la ruta aprobada: contactar al transportador si corresponde, rechazar la entrega bajo condiciones definidas, iniciar una devolución después de recibir o hablar con una persona. El handoff incluye pedido, solicitud original, estados consultados, intentos realizados y motivo del bloqueo.
NIST recomienda definir y documentar roles y responsabilidades para la interacción entre personas y sistemas de IA. En este caso, operaciones, servicio, fraude, pagos y logística deben acordar quién resuelve cada excepción y qué acciones nunca quedan bajo autonomía del agente.
Arquitectura mínima para un piloto
- Canal de entrada: WhatsApp, webchat, correo o voz.
- Inbox omnicanal para que IA y equipo compartan la conversación y el handoff.
- CRM con contacto, pedido relacionado, intención, estado y responsable.
- OMS, ERP o plataforma de comercio como fuente oficial del pedido y fulfillment.
- Motor de políticas para elegibilidad, riesgo y aprobaciones.
- Servicio de identidad cuando el cambio requiere autenticación adicional.
- Integración de pagos para consultar, no suponer, el estado financiero.
- Webhooks para hold, liberación, edición, cancelación, preparación, despacho, error y reembolso.
- Registro de auditoría con solicitud, versión de reglas, acción, respuesta y actor.
Qué automatizar y qué conservar bajo control
| El agente puede coordinar | Requiere sistema o persona autorizada |
|---|---|
| Entender la solicitud y pedir datos faltantes | Determinar si la identidad permite un cambio sensible |
| Consultar estado y acciones disponibles | Forzar una cancelación en un estado bloqueado |
| Aplicar un hold permitido y temporal | Aprobar excepciones de precio, pago o fraude |
| Ejecutar una cancelación estándar confirmada | Modificar un pedido ya preparado o despachado |
| Comunicar resultados confirmados | Prometer el momento exacto de un reembolso |
| Preparar un handoff con evidencia | Resolver disputas materiales o casos regulatorios |
Métricas que sí muestran impacto
La tasa de contención por sí sola puede ocultar cambios incorrectos o clientes que abandonaron. Conviene medir el resultado operativo completo:
- Tiempo desde la solicitud hasta la primera respuesta útil.
- Porcentaje de solicitudes atendidas antes del punto de no retorno logístico.
- Cambios y cancelaciones confirmados correctamente en el sistema oficial.
- Pedidos despachados después de una cancelación supuestamente aceptada.
- Holds aplicados, vencidos, liberados y abandonados.
- Operaciones duplicadas por reintentos o cambio de canal.
- Casos escalados con contexto completo y responsable.
- Diferencias entre estado comunicado, estado logístico y estado financiero.
- Contactos repetidos por la misma solicitud.
- Costo operativo y tiempo de atención por caso.
- Satisfacción del cliente y reclamos posteriores.
Segmenta por centro de fulfillment, transportador, canal, tipo de cambio, etapa y resultado. Así podrás distinguir si la fricción está en la conversación, las reglas, el tiempo de bodega, el sistema de pedidos o la conciliación con pagos.
Cómo empezar sin arriesgar toda la operación
Elige una categoría de producto, un centro de fulfillment y dos intenciones, por ejemplo cancelación total y corrección de dirección antes del picking. Mapea cada estado real y define el punto exacto a partir del cual la solicitud cambia de edición a devolución o revisión humana.
Después prueba escenarios adversos: mensaje ambiguo, identidad no validada, pedido dividido entre bodegas, una línea ya empacada, webhook repetido, hold que falla, cancelación aceptada con reembolso pendiente y dos solicitudes simultáneas desde canales distintos. Amplía el alcance solo cuando el estado comunicado coincida de forma consistente con la operación.
Preguntas frecuentes
¿Un agente de IA puede cancelar pedidos automáticamente?
Sí, en casos estándar donde identidad, estado, política y permisos lo permiten. La decisión final debe ser validada por reglas y por el sistema de pedidos; el modelo no debería saltarse controles ni declarar éxito antes de recibir confirmación.
¿Qué pasa si el pedido ya fue despachado?
La automatización debe dejar de ofrecer edición o cancelación y presentar la ruta posterior autorizada. Dependiendo de la operación, puede ser seguimiento con el transportador, rechazo controlado de entrega, devolución o atención humana.
¿Es necesario reemplazar el ecommerce o ERP?
No necesariamente. Seelai puede funcionar como capa de conversación y coordinación conectada al ecommerce, OMS, ERP, CRM y pagos mediante APIs y webhooks. El sistema operativo existente conserva la autoridad sobre estados y acciones.
¿Por qué usar un hold antes de cancelar?
Porque algunas solicitudes necesitan revisión mientras el fulfillment sigue avanzando. Una pausa confirmada puede preservar la ventana de acción, pero debe tener vencimiento y responsable; no todos los pedidos ni plataformas admiten el mismo mecanismo.
Dónde encaja Seelai
Seelai conecta agentes de servicio al cliente, inbox omnicanal, CRM inteligente, ERP y automatizaciones con webhooks para que una solicitud de cambio no se quede como un mensaje aislado. El agente interpreta la intención; el sistema operativo confirma lo que todavía puede hacerse; las reglas protegen acciones sensibles; y el equipo recibe las excepciones con el contexto listo.
El resultado buscado no es cancelar más pedidos. Es responder antes, ejecutar correctamente lo que todavía es posible y convertir cada excepción en un siguiente paso claro para el cliente y la operación.
Fuentes
- Microsoft Learn, Customer orders in point of sale (POS) - Commerce: https://learn.microsoft.com/en-us/dynamics365/commerce/customer-orders-overview
- Microsoft Learn, Store order fulfillment - Commerce: https://learn.microsoft.com/en-us/dynamics365/commerce/order-fulfillment-overview
- Shopify Developer Docs, fulfillmentOrderHold: https://shopify.dev/docs/api/admin-graphql/latest/mutations/fulfillmentorderhold
- NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0): https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
- OWASP GenAI Security Project, LLM06:2025 Excessive Agency: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
Si tu equipo recibe cambios y cancelaciones por varios canales mientras bodega, pagos y servicio consultan sistemas distintos, agenda una demo de Seelai en /demo. Revisaremos una intención, sus estados de pedido, permisos, webhooks, excepciones y métricas para diseñar un piloto conectado con tu operación real.