Devoluciones retail, sin que CX revise una por una.
La política de devolución existe — el problema es aplicarla cien veces al día con consistencia. Un agente valida el caso contra tu OMS, arma la etiqueta de courier y comunica al cliente. CX entra solo donde hay ambigüedad real: producto dañado, cliente recurrente sospechoso, fuera de plazo con justificación.
Rangos referenciales para retail con política de devolución escrita y acceso al OMS. Dependen de la consistencia de la política entre canales y del % de casos atípicos (fraude, daño en tránsito).
El problema
Cada solicitud de devolución pasa por la misma checklist: ¿el pedido existe?, ¿está dentro del plazo?, ¿el producto es elegible?, ¿con qué courier?, ¿reembolso al medio original o nota de crédito? Es trabajo repetitivo pero error-prone — un caso mal procesado cuesta caro.
Cuando el volumen sube (post-Cyber, post-fin de mes), el equipo de CX se atrapa procesando RMAs y se descuida lo importante: detectar fraude real, gestionar reclamos de marca, evitar churn.
Qué hace el agente
1. Captura estructurada. Lee la solicitud por el canal de entrada y extrae lo necesario: número de pedido, motivo, producto a devolver, opcionalmente foto.
2. Valida contra el OMS. Consulta el pedido real: ¿existe?, ¿quién lo compró?, ¿cuándo?, ¿qué producto?, ¿está dentro del plazo de devolución según canal?
3. Aplica la política. "Producto sin uso, dentro de plazo, primera devolución del cliente → aprobar". Otros casos van a una de las reglas escritas o escalan. Nunca improvisa.
4. Gestiona la logística. Genera la etiqueta del courier vía API (Chilexpress, Starken, Blue Express, Correos), comunica los pasos al cliente y agenda el retiro si aplica.
5. Cierra el caso. Sincroniza el estado en el OMS, gatilla el reembolso al medio de pago original o nota de crédito según política, y registra todo para auditoría.
Cuándo tiene sentido
Volumen. Sobre 100 solicitudes/mes. Bajo eso, CX puede manejarlo con un formulario decente."
Política escrita. Si la política es 'depende del caso' o varía entre canales sin regla clara, primero hay que consolidarla. El agente no inventa."
OMS accesible. Lectura del pedido en tiempo real (Shopify, VTEX, Bsale, Defontana, Manager). Sin eso, no hay validación posible."
Couriers con API. Chilexpress, Starken, Blue Express, Correos Chile tienen API. Si operas con un courier que no tiene, queda como excepción manual."
Qué necesitamos de tu lado
Política de devolución escrita por canal. Últimas 500 solicitudes con su resolución (aceptada, rechazada, fraude detectado). API sandbox del OMS y de los couriers que usás. Reglas de reembolso por medio de pago.
Preguntas que te haremos en discovery
- ¿Cuántas solicitudes de devolución/cambio por mes?
- ¿La política es una sola para todos los canales o hay variantes?
- ¿Por dónde entran la mayoría de las solicitudes: WhatsApp, email, formulario?
- ¿Qué OMS/ERP usan?
- ¿Con qué couriers operan y tienen API integrada?
- ¿Venden en marketplaces (Mercado Libre, Falabella, Paris)? ¿Esos quedan dentro del scope?
- ¿Política de reembolso: automático al medio original o nota de crédito?
Preguntas frecuentes
¿Y los marketplaces? ¿Mercado Libre, Falabella?
Los marketplaces tienen su propio flujo de devoluciones que no podemos automatizar — los manejan ellos. El agente cubre el canal propio (web, WhatsApp, email). Para marketplaces, dejamos visibilidad pero la operación queda en sus reglas.
¿Detecta fraude?
Reglas básicas (cliente con muchas devoluciones, mismo producto varias veces, monto sospechoso). Detección sofisticada con ML viene después si el volumen lo justifica — y siempre con humano final.
¿Y si el cliente reclama por la decisión del agente?
Cualquier escalamiento del cliente entra a CX humano con todo el contexto. El agente no insiste, no se pone defensivo y no genera controversia.
¿Reemplaza al equipo de logística inversa?
No. Reduce la fricción del front-end (validación, comunicación, etiqueta), pero el flujo físico (recepción, inspección, reingreso a stock) sigue humano.