Order Management Agent para Commerce Cloud.
"¿Dónde está mi pedido?" se responde en segundos. Cancelaciones, modificaciones y devoluciones, también.
El agente OOTB de Agentforce que opera el ciclo post-venta: estado de pedido en vivo desde el OMS y los couriers, cancelaciones dentro de la ventana de cutoff, cambios de dirección, splits de envío, devoluciones con RMA y refunds tokenizados al gateway. Disponible 24/7 en chat web, WhatsApp, app mobile y email. Pensado para Customer Care de e-commerce, Order Operations y Logística.
¿Qué hace Order Management Agent?
Es un agente OOTB de Agentforce que resuelve el grueso de las consultas post-compra sin intervención humana. Recupera el Order DMO con tracking en vivo desde el OMS y APIs de couriers (DHL, FedEx, Mercado Envíos, Andreani), valida políticas de cancelación y devolución, ejecuta cambios contra el OMS, dispara refunds vía gateway con tokens y notifica al cliente con plazos exactos. Cuando el caso lo amerita, hace handoff a un agente humano de Service Cloud con el contexto completo precargado.
Cómo funciona paso a paso
De la consulta al cambio confirmado o al handoff humano. 6 pasos.
Autenticación e identificación de la orden
Login del storefront, OTP por email/SMS o resolución por email + número de orden para guest checkout. lookupOrder soporta fuzzy matching para errores tipográficos.
Identificación del intent
El LLM clasifica el intent (status, cancelación, modificación, devolución, reorder) y mapea al Topic correspondiente. Si hay ambigüedad, hace una pregunta aclaratoria antes de proceder.
Hidratación con Order, Shipment y Payment
Recupera Order DMO completo con OrderItems, estado de cada línea, datos del courier (Mercado Envíos, Andreani, DHL, FedEx) y transacciones de pago tokenizadas.
Validación de elegibilidad
Antes de cualquier escritura, valida ventana de cancelación, estado de fulfillment, política de devolución vigente y score de fraude (Cybersource Decision Manager o Forter para refunds sobre umbral).
Ejecución del cambio
Llama al effector correspondiente: cancelOrder, modifyShippingAddress, initiateRefund, applyRMA o splitShipment. Cada acción queda trazable en Einstein Activity Monitoring con timestamp y respuesta del sistema.
Confirmación o handoff
Confirma la acción al cliente con datos concretos (número de RMA, ETA del nuevo envío, plazo de acreditación del refund). Si hay excepción, escala a Service Cloud con el contexto completo precargado.
Ejemplo de interacción real
[Cliente en México pregunta por WhatsApp]
[El agente responde en segundos]
Arquitectura del agente
Topics, Actions, Hydrators y Effectors que sostienen al Order Management Agent.
Topics y canales
Dominios y dónde vive
- Order Status Inquiry (40-55% del volumen)
- Cancellation Request
- Modification Request
- Refund Processor
- Shipment Tracker
- Reorder Assistant
- Chat web · WhatsApp · App · Email
Actions
Lo que ejecuta
- lookupOrder (fuzzy matching)
- cancelOrder con validación de cutoff
- modifyShippingAddress
- initiateRefund (tokenizado)
- exchangeItem con validación de stock
- splitShipment
- applyRMA con label prepago
Hydrators y DMOs
Fuentes de contexto
- Order DMO + OrderItem
- Fulfillment Order + Shipment
- Payment Transaction (token)
- Customer (Identity Resolution)
- Inventory Hydrator
- Tracking events del courier
Effectors y Trust Layer
Escrituras y guardrails
- Order writes vía OMS Salesforce o externo
- Refund vía gateway con vault token
- Inventory restock automático
- Fuera del scope PCI por diseño
- PII masking en Order History
- Consent management transaccional
- Isolation multi-tenant para marketplaces
Implementación en 5 fases
El driver clave es la calidad de las integraciones con OMS y couriers. Timing típico: 9 a 13 semanas.
Discovery y políticas
Documentamos políticas de cancelación, modificación y devolución por categoría, mapeamos los couriers activos por país y los gateways de pago integrados.
Integraciones OMS y couriers
Conectamos Salesforce OMS o el OMS externo (SAP, Manhattan, Infor) vía MuleSoft. Integramos APIs de Mercado Envíos, Andreani, DHL, FedEx y Correo Argentino para tracking en vivo.
Agent build y políticas en KB
Configuración de Topics, Actions y Hydrators en Agent Builder. Carga de la política de devolución como Knowledge Base estructurada para que el agente la consulte en cada decisión.
Piloto multi-canal
Rollout en chat web y WhatsApp para 10-15% del tráfico. Validamos deflection, latencia, calidad de tracking y handoffs a Service Cloud.
Go-live y expansión a app y email
Rollout total. Expansión al canal app mobile, integración con email transaccional, monitoreo de CSAT y deflection. Tuning mensual de prompts y thresholds de fraude.
Equipo típico de implementación
Requisitos para arrancar
Lo que necesitás listo antes del go-live.
Datos mínimos
- Order DMO sincronizado con OMS
- Política de cancelación, modificación y devolución documentada
- Customer 360 con Identity Resolution para guest checkout
- Histórico de tickets por categoría para calibrar deflection
Licencias
- Salesforce Commerce Cloud B2C o B2B
- Commerce Cloud Agentic Edition
- Service Cloud (handoff humano)
- Salesforce OMS u OMS externo conectado
- MuleSoft (recomendado para couriers y OMS externo)
Integraciones
- OMS (Salesforce OMS, SAP, Manhattan, Infor)
- APIs de couriers: Mercado Envíos, Andreani, DHL, FedEx, Correo Argentino
- Payment gateways: Mercado Pago, Adyen, Stripe, Cybersource, Stone, EBANX
- Fraud providers (Cybersource Decision Manager, Forter)
- WhatsApp Business API
Org readiness
- Política de modificaciones documentada con SLAs
- Equipo de Customer Care entrenado en handoff
- Templates de WhatsApp pre-aprobados
- Proceso de escalamiento a humano definido
KPIs: antes y después
KPIs esperados al implementar este agente. Rangos referenciales para planificación; los resultados reales dependen del estado de los datos y la operación de cada empresa.
| Métrica | Antes (equipo humano) | Después (Order Management Agent) | Cambio |
|---|---|---|---|
| Tiempo de respuesta a status | Minutos a horas | Segundos | Minutos → segundos |
| Deflection a humano | Baseline | 60 a 80% | -60-80% volumen humano |
| Modificaciones self-service | Baseline | +50 a 70% | +50-70% |
| CSAT post-consulta | Baseline | +15 a 25 ppt | +15-25 ppt |
| Tiempo del primer contacto a resolución | 2 - 6 horas | Menos de 5 minutos | -95% |
| Cobertura 24/7 de status y devoluciones | Horario laboral | 24/7 | Continuo |
Arquetipo fashion con devoluciones altas: en moda, la tasa de devolución puede superar el 30% del GMV y cada devolución genera múltiples contactos (solicitud, confirmación de RMA, estado del crédito). Con el agente operando, el cliente recibe el RMA y la etiqueta de envío en la primera interacción y el equipo humano se enfoca en disputas y excepciones complejas.
Tenemos casos en este agente — hablemos para compartir los relevantes a tu industria.
Riesgos comunes y cómo los mitigamos
Tracking inexacto del courier
El courier devuelve un estado desactualizado o incorrecto y el agente promete un ETA que no se cumple.
Mitigación: integración a múltiples fuentes (OMS + courier) con regla de fallback, lenguaje conservador en respuestas ("estimado", "según última actualización") y monitoreo de discrepancias.
Modificaciones que rompen fulfillment
Un cambio de dirección llega después del cutoff y la orden se despacha al destino viejo.
Mitigación: validación obligatoria de ventana de cutoff antes de cada modificación, sincronización con WMS y notificación al courier en tiempo real cuando se aceptan cambios.
Notificaciones duplicadas o saturadas
Cliente recibe varios mensajes por el mismo cambio porque el agente y el sistema legacy notifican en paralelo.
Mitigación: capa única de notificaciones vía Marketing Cloud, frequency cap por orden y por canal, y deduplicación al momento del envío.
Refund a la cuenta equivocada por fraude
Un atacante pretende ser el cliente y solicita un refund que el agente aprueba sin validación.
Mitigación: consulta obligatoria a fraud provider para refunds sobre umbral, autenticación reforzada (OTP) para guest checkout y refund siempre al método de pago original.
Exposición accidental de datos PCI o PII
Un cliente tipea el número de tarjeta en el chat y queda en logs.
Mitigación: diseño fuera del scope PCI, masking automático de patrones de tarjeta, refund vía vault token y enmascaramiento de PII en Order History en logs accesibles.
Preguntas Frecuentes
No. El agente cubre el 60-80% del volumen de consultas repetitivas (status, modificaciones simples, devoluciones estándar). El equipo humano se enfoca en disputas, fraude, daños, casos sensibles y excepciones de política. La mayoría de los retailers que implementan el agente terminan elevando la calidad de cada caso humano, no reduciendo el headcount.
Sí. La integración nativa es con Salesforce OMS, pero soporta OMS externos vía MuleSoft o Integration Procedures de OmniStudio. Solu mantiene templates de integración para SAP, Manhattan e Infor. La latencia de la integración es un punto crítico que se monitorea como métrica de salud del agente.
Mercado Envíos (LATAM), Andreani y Correo Argentino (Argentina), Estafeta y FedEx (México), Coordinadora (Colombia), Chilexpress (Chile), Loggi y Mandaê (Brasil). Para cross-border, DHL y UPS. La integración se hace vía las APIs públicas de cada courier; Solu mantiene conectores prebuilt para los más comunes.
No. Por diseño, el agente queda fuera del scope PCI. Los refunds se ejecutan vía vault tokens del gateway (Stripe, Cybersource, Adyen, Mercado Pago, Stone). El agente nunca recibe ni almacena números de tarjeta, CVV ni fechas de vencimiento. El gateway devuelve el reference ID del refund para trazabilidad.
Vía Service Cloud handoff con la conversación completa precargada: número de orden, intent detectado, validaciones realizadas y motivo del escalamiento. El agente humano recibe el caso ya enriquecido y puede continuar sin pedirle al cliente que repita información.
Sí. PII masking automático, consent management para comunicaciones transaccionales, tokenización de refunds y audit trail inmutable. Los datos se procesan en residencia regional según la configuración del tenant Salesforce y los logs respetan los plazos de retención definidos por compliance.
El primer impacto medible llega en las primeras 4-6 semanas post go-live, cuando el agente cubre los topics de Order Status (volumen más alto). El plateau de deflection del 60-80% suele alcanzarse entre los 3 y 6 meses, a medida que se calibran las políticas y se expande a más topics y canales.
"¿Dónde está mi pedido?" deja de saturar al equipo humano.
Hablá con un Commerce Architect de Solu. Mapeamos tu OMS, tus couriers y proyectamos el deflection esperable en tu operación.