Returns & RMA Agent.
Devolución resuelta desde WhatsApp en menos de 5 minutos. RMA, courier, refund y cierre con audit log.
El agente custom que gestiona devoluciones end-to-end desde Commerce Cloud: identidad, elegibilidad, scoring de fraude, generación de RMA con label, coordinación con courier, refund o cambio, y cierre con audit log. Para Customer Care, Operations y Commerce que necesitan self-service real sin abrir la puerta al fraude.
¿Qué hace Returns & RMA Agent?
Returns & RMA Agent recibe la solicitud de devolución por WhatsApp, web chat, app o email; valida elegibilidad contra la política digitalizada; aplica scoring de fraude; genera el RMA con label de envío; coordina pickup con el courier óptimo; procesa refund o cambio; y cierra el case con audit log inmutable. Customer Care queda para excepciones de alto valor o fraude detectado.
Cómo funciona paso a paso
De la solicitud por WhatsApp al cierre con audit. 8 pasos con scoring de fraude.
Solicitud de devolución
El cliente inicia por WhatsApp, web chat, app o email. El agente identifica la orden y los ítems.
Identidad y validación de elegibilidad
Verifica identidad, ventana de devolución, condición del producto, política de la categoría y motivo declarado.
Análisis de fraude
Calcula score con histórico del cliente, frecuencia de devolución, monto acumulado e inconsistencias en motivos. Si supera el threshold, escala a Customer Care.
Generación de RMA + label de envío
Crea el RMA con número de tracking. Genera label en PDF y la envía por el canal del cliente con instrucciones de embalaje.
Coordinación con courier
Selecciona courier óptimo por zona, costo y SLA. Coordina pickup con franja horaria que el cliente acepta.
Tracking del retorno
Sigue el envío de vuelta al WMS. Notifica al cliente al recibir el producto en el centro de distribución.
Procesamiento de refund o cambio
Refund al medio de pago original o cambio por otro producto. Ofrece store credit con bonus si está en política.
Cierre con audit log
Actualiza inventario en WMS, emite nota de crédito fiscal vía conector certificado, cierra el case y registra todo en audit trail inmutable.
Ejemplo de interacción real
Arquitectura del agente
Las cuatro primitivas que sostienen al Returns & RMA Agent dentro de tu org de Salesforce.
Data
Fuentes de grounding
- Order DMO + OrderItem
- Return DMO + RMA Line Item
- Customer 360 unified profile
- Política digitalizada (JSON)
- Catalog DMO (retornable / no)
- Fraud Score Model
Actions
Lo que el agente ejecuta
- validateEligibility
- scoreFraud
- generateRMA + label
- requestCarrierPickup
- trackReturnShipment
- issueRefund / createReplacement
- updateWMSInventory
- emitFiscalCreditNote
Guardrails
Controles de confianza
- Política como structured data, no texto libre
- Threshold de fraude escala a humano
- Audit trail inmutable
- PII masking en logs
- Compliance fiscal LATAM (AFIP, SAT, DIAN)
Channels
Dónde opera el agente
- WhatsApp Business (canal principal)
- Web chat embebido
- App móvil
- Portal de cliente
Requiere Data Cloud: Recomendado (Customer 360 + fraud signals)
Requiere integración a courier APIs: Sí (mínimo 2 carriers por país)
Requiere Einstein Trust Layer: Sí (incluido en Agentforce)
Implementación en 5 fases
De discovery a producción. Returns & RMA Agent procesando devoluciones en 12-14 semanas.
Discovery y política
Workshop con Customer Care, Operations, Legal y Finanzas. Mapeo de política por categoría, carriers vigentes, flujo fiscal por país, dataset histórico de fraude.
Data readiness
Order history 24 meses, Catalog con metadata retornable, política formalizada como JSON, identity resolution Order-Contact, dataset labeled de fraude.
Agent build
Topics, integraciones a courier APIs y payment gateways, flujo fiscal por país, fraud scoring, plantillas WhatsApp pre-aprobadas.
Piloto asistido
10-15% del volumen de devoluciones. Customer Care supervisa en paralelo y revisa edge cases. Calibración del fraud score con datos del piloto.
Rollout autónomo
100% del volumen elegible. Customer Care queda con excepciones y alto valor. Governance semanal con métricas de devolución, fraude detectado y SLA.
Equipo típico de implementación
Requisitos para arrancar
Lo que necesitás tener listo antes de poner Returns & RMA Agent en producción.
Datos mínimos
- Política de devoluciones digitalizada (JSON)
- Order history 24 meses
- Catalog con metadata retornable
- Dataset histórico labeled de fraude
Licencias
- Commerce Cloud (B2C, B2B o D2C)
- Agentforce for Commerce (Flex Credits)
- Data Cloud (recomendado)
- MuleSoft (integraciones carriers / ERP)
Integraciones
- ERP (órdenes, fiscal)
- WMS sincronizado (recepción, stock)
- Carrier APIs (Andreani, OCA, FedEx, etc.)
- Payment gateways (MercadoPago, Stripe)
- Fiscal connectors (AFIP, SAT, DIAN)
Org readiness
- Política Legal aprobada por categoría
- Carriers con API habilitada
- Customer Care preparado para excepciones
- Sponsor en Operations / CX
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 | Después | Cambio |
|---|---|---|---|
| Time-to-RMA | 2-4 días | < 5 minutos | Días → Minutos |
| Self-service rate | 0-10% | 60-80% | +50-70 ppt |
| Costo logístico de devoluciones | Baseline | -15-25% | Eficiencia |
| Fraude detectado | Baseline | +30-50% | Mejora |
| AHT del CX en devoluciones | 15-18 min | 2-3 min | -80-85% |
| Time-to-value | N/A | 4-6 semanas post go-live | Progresivo |
Solu entrega dashboard con devoluciones por categoría y carrier, fraude detectado, SLA de procesamiento, fiscal compliance.
Riesgos comunes y cómo los mitigamos
Fraude de devoluciones
Wardrobing, serial returners y devoluciones de productos no comprados acumulan pérdidas significativas.
Mitigación: Scoring de fraude pre-aprobación con histórico, frecuencia, monto y patrones. Threshold de escalation a Customer Care. Recalibración trimestral con outcomes reales.
Política cambiante o ambigua
Si la política está en texto libre o cambia sin actualizar al agente, las decisiones quedan inconsistentes.
Mitigación: Política como structured data versionada, no como texto libre. Validación determinística pre-LLM. Cambios documentados y testeados antes de pasar a producción.
Compliance fiscal LATAM
Una nota de crédito mal emitida deriva en multa de AFIP, SAT, DIAN o equivalente.
Mitigación: Conector fiscal certificado por país. Validación contable en ERP antes de emitir. Test trimestral con el equipo de Finanzas. Audit trail completo del documento fiscal.
Carrier API downtime
Si el courier API está caído, no se puede coordinar pickup y el cliente queda en limbo.
Mitigación: Multi-carrier por zona como redundancia. Queue de reintentos automáticos. Notificación al cliente con ETA actualizado. Monitoring de uptime por carrier con alerta.
Adopción CX débil
El equipo de Customer Care siente que el agente lo reemplaza y deriva todo a humano por reflejo.
Mitigación: CX maneja excepciones de alto valor y casos de fraude (rol premium). Métricas de satisfacción del CX. Training en nueva función desde la semana 1 del proyecto.
Preguntas Frecuentes
Sí. El agente identifica el canal de compra original y aplica la política correspondiente. Un producto comprado online puede devolverse en tienda si la política lo permite, y viceversa. La clave es tener identity resolution unificada y la política de cross-canal explícita.
Sí. Integramos con Andreani, OCA, FedEx, DHL y Mercado Envíos como base. Sumamos carriers locales por país (Coordinadora en Colombia, Estafeta en México, Correios en Brasil) según los acuerdos vigentes. El agente selecciona el óptimo por zona, costo y SLA.
Sí, vía conector fiscal certificado por país. En Argentina emite Nota de Crédito B/C vía AFIP. En México genera CFDI de egreso. En Colombia usa la DIAN. Siempre pasa por el ERP para validación contable antes de emitir y queda registrada en audit trail.
Calcula score con histórico del cliente, frecuencia de devoluciones, montos acumulados, inconsistencias en motivos declarados y patrones de wardrobing (compra-uso-devolución). Cuando supera el threshold, escala a Customer Care en lugar de aprobar automáticamente.
Sí. Según la política configurada puede ofrecer store credit como alternativa, típicamente con un bonus (ej. 110% del valor) para incentivar la retención. La decisión final es del cliente y siempre puede elegir refund al medio de pago original.
12-14 semanas. La primera devolución self-service suele ejecutarse en la semana 10 durante el piloto asistido. El valor tangible (reducción de AHT y aumento del self-service rate) se ve a partir de la semana 12 con governance semanal.
De solicitud a refund, sin fricción y sin abrir la puerta al fraude.
Hablá con un Commerce Architect de Solu. En discovery mapeamos tu política de devoluciones y diseñamos el flujo end-to-end.