Omnichannel retail.
Stock, precios y promociones que dicen lo mismo en todos lados.
Una marca con tiendas físicas, e-commerce, marketplace, app móvil y contact center necesita que todos los canales hablen de la misma realidad. Con MuleSoft conectás POS, WMS, OMS, e-commerce y marketplace en torno a Process APIs como single-stock, pricing y order routing. El cliente ve disponibilidad real, paga el precio correcto y puede retirar en tienda lo que compró online.
¿Qué resuelve Omnichannel retail con MuleSoft?
Sin omnicanalidad real, dos canales digitales hablan precios distintos, las promos no aplican en tienda, el stock muestra disponible pero al despachar descubre quiebre, el cliente que compra en marketplace no aparece en el CRM. Cada canal opera como un silo. Con MuleSoft, las Process APIs single-stock, pricing y order-router actúan como columna vertebral. La experiencia del cliente es la misma en todos lados.
- Stock unificado en tiempo real entre tiendas, CD, tránsitos y reservas.
- Pricing engine que aplica promociones consistentes en cada canal.
- BOPIS, ship-from-store y devoluciones cross-canal orquestadas.
- Distributed Order Management como Process API que rutea cada pedido al fulfillment óptimo.
Sistemas típicos involucrados
Las familias que conviven en una operación retail omnicanal seria.
POS
Aldata, Compass POS Toshiba, Oracle Retail XStore, Cegid y soluciones POS verticales según el formato de la cadena.
E-commerce y marketplaces
Vtex, Magento, Salesforce Commerce, Shopify Plus, Tienda Nube. Marketplaces: Mercado Libre, Amazon, integraciones via channel managers.
WMS y OMS
Manhattan, JDA, IBM Sterling OMS, Manhattan Active Omni, Kibo, SAP EWM como gestores de inventario y orquestación de pedidos.
CRM y loyalty
Salesforce Service y Sales como CRM, programas de loyalty propios o sobre Comarch / Annex Cloud para puntos y promociones por segmento.
Arquitectura objetivo
Process APIs como columna vertebral. Cada canal consume Experience APIs optimizadas y reusa la misma fuente de verdad.
+----------+ +-----------+ +-----------+ +-----------+ +----------+
| Tienda | | E-commerce| |Marketplace| | App Móvil | | Contact |
| (POS) | | (Vtex) | | (MELI) | | | | Center |
+-----+----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+----+
| | | | |
+------------+-------+-----+-----+-------+----+--------+
| |
v v
+---------------------------------------------------------------+
| Experience APIs (storefront / cart / customer) |
+----------------+----------------+-----------------------------+
| |
v v
+---------------------------------------------------------------+
| Process APIs |
| single-stock-pa, pricing-pa, order-router-pa, |
| returns-pa, loyalty-pa, customer-360-pa |
+----+--------+--------+--------+--------+--------+------+------+
| | | | | |
v v v v v v
POS WMS/OMS Pricing Marketplace LMS ERP / CRMSystem APIs
pos-sapi, vtex-orders-sapi, meli-orders-sapi, wms-stock-sapi, oms-orders-sapi, pricing-engine-sapi, loyalty-sapi. Una API por sistema fuente con contratos limpios alineados al negocio.
Process APIs
single-stock-pa calcula stock vendible. order-router-pa aplica reglas DOM. pricing-pa calcula precio efectivo con promociones y loyalty. returns-pa orquesta devoluciones cross-canal.
Experience APIs
storefront-eapi para web y app, pos-eapi para tienda con datos extras del operador, csr-eapi para contact center con vista 360 y acciones rápidas. Cada canal recibe el shape que necesita.
Flujo paso a paso
BOPIS end-to-end: compra online, retiro en tienda, eventos consumidos por el resto del ecosistema.
- 1 Cliente en web busca un producto. La Experience API storefront-eapi devuelve detalle, precio, promociones y stock disponible global, con flag de disponibilidad para retiro en tienda.
- 2 Cliente selecciona retiro en tienda y elige un local específico. La UI llama a single-stock-pa con filtro de location para confirmar disponibilidad real en esa tienda.
- 3 La UI muestra disponible en la tienda elegida con tiempo estimado de preparación. Si hay alta rotación del SKU, el TTL del cache es muy corto para no mostrar disponibilidad obsoleta.
- 4 Cliente avanza al checkout. cart-eapi valida el stock por última vez (puede haber cambiado), aplica pricing-pa, aplica loyalty-pa si el cliente usa puntos y procesa el pago.
- 5 Si hay stock confirmado, order-router-pa decide el fulfillment óptimo: en este caso, fulfillment desde la tienda elegida. Crea la orden en el OMS y reserva stock con TTL.
- 6 El sistema notifica a la tienda: pos-sapi recibe la pickup task. La app del staff de tienda muestra la alerta con detalle del pedido.
- 7 El personal de tienda prepara, escanea y marca como ready for pickup. El POS llama a unified-order-pa para actualizar el estado del pedido a ready.
- 8 Sistema notifica al cliente vía WhatsApp, SMS o push: tu pedido está listo, vení a buscarlo cuando quieras dentro de las próximas 24 horas.
- 9 Cliente llega al punto de retiro y se identifica con el QR del email de confirmación. POS marca como delivered. Updates a OMS, CRM y loyalty para acreditar puntos.
- 10 Eventos publicados: order.delivered.v1 consumido por finanzas (revenue recognition), por marketing (segmentación de comportamiento) y por BI para reporting.
- 11 El reservation-with-TTL libera la reserva si el checkout no se completa, evitando overselling cuando dos clientes llegan simultáneamente con stock al límite.
Patterns aplicados
Los patrones que sostienen la operación omnicanal en pico estacional sin sustos.
Scatter-gather
single-stock-pa consulta WMS, tiendas, reservas y tránsitos en paralelo y devuelve el stock disponible vendible con breakdown.
CQRS light
Las queries de stock van a una vista materializada con cache; los commands (reservas, ventas) van directo al sistema source para evitar inconsistencias.
Saga
Para checkouts multi-paso (validar stock, aplicar pricing, redimir loyalty, cobrar, reservar fulfillment): cada paso tiene su compensación.
Distributed Order Management
order-router-pa aplica reglas de routing para decidir el fulfillment óptimo: CD principal, ship from store, split en múltiples nodos.
Reservation with TTL
Al iniciar checkout, se reserva stock por una ventana corta. Si no se completa, la reserva expira y libera para evitar overselling.
Event sourcing
Cada movimiento de inventario se publica como evento, lo que habilita reconstrucción del estado, auditoría y consumers desacoplados.
Cómo lo implementamos
Cinco fases del primer canal en producción al omnicanal pleno con marketplaces.
Mapa omnicanal y dolor
Inventario de canales, sistemas y reglas de fulfillment, identificación de overselling actual, mapeo de reglas de pricing y promociones, auditoría de programa de loyalty. Entregables: assessment, business case, roadmap de APIs.
Modelo canónico y reglas DOM
Diseño API-Led: System APIs por sistema (POS, WMS, OMS, e-commerce, marketplace), Process APIs single-stock, pricing, order-router, loyalty. Reglas DOM acordadas con operaciones y comercial.
Construcción y pico de tráfico
Implementación de las APIs core, configuración de cache y CDN, load testing simulando picos tipo Hot Sale o Black Friday. Tests MUnit, CI/CD a sandbox del e-commerce y los POS.
Go-live por canal
Go-live por canal: web primero, luego app, luego BOPIS. Hypercare durante el primer pico estacional con auto-scaling agresivo y monitoring intensivo.
Marketplaces y nuevos formatos
Incorporación de marketplaces como canal más, ship-from-store ampliado a más tiendas, devoluciones cross-canal, expansión a nuevos formatos. Capacitación del equipo del cliente para gobernar el omnicanal.
Requisitos del proyecto
Lo que tiene que estar disponible del lado del cliente para arrancar.
Datos mínimos
Catálogo de productos consolidado, lista de precios y promociones documentadas, jerarquía de tiendas y CDs, reglas DOM acordadas con operaciones, política de devoluciones.
Licencias y capacidades
Anypoint Platform con CloudHub 2.0 (auto-scaling para picos), conectores POS, WMS, OMS, e-commerce y marketplace según el stack del cliente.
Integraciones típicas
POS, e-commerce, marketplace, WMS, OMS, pricing engine, programa de loyalty, CRM y data warehouse para reporting omnicanal.
Pre-requisitos organizacionales
Sponsor del programa omnicanal, líder de operaciones, líder de digital y de tienda alineados, política unificada de pricing y promociones, capacidad de change management para staff de tienda.
KPIs operativos
Las métricas que típicamente se monitorean tras el go-live del omnicanal.
| KPI | Qué mide | Por qué importa |
|---|---|---|
| Stock check P95 | Latencia P95 de la consulta de stock disponible vendible. | Define la velocidad de la UI del e-commerce y del POS. Cada milisegundo cuenta en pico estacional. |
| Oversell count | Cantidad de pedidos vendidos sin stock real. | Es la métrica que define la confianza del cliente y el costo operativo de cancelaciones forzadas. |
| Cart abandonment correlated with latency | Correlación entre latencia de las APIs y abandono de carrito. | Confirma o cuestiona si las inversiones de performance se traducen en conversión. |
| Pricing calculation P95 | Latencia del cálculo de precio efectivo con promociones aplicadas. | El pricing engine está en el camino crítico. Lentitud aquí impacta directo la conversión. |
| Loyalty redemption rate | Porcentaje de checkouts donde el cliente redime puntos. | Indicador de salud del programa de loyalty y de su integración real con la operación. |
| BOPIS share of e-commerce | Porcentaje del e-commerce que se cumple como retiro en tienda. | Mide adopción del modelo omnicanal y eficiencia de fulfillment desde tienda. |
Time-to-value: primer canal con stock unificado y pricing consistente en producción tras 14 a 18 semanas. BOPIS y marketplaces se incorporan en olas posteriores.
Cómo se mide: dashboard sobre Anypoint Monitoring con métricas técnicas y de negocio (overselling, conversion, BOPIS share), integrado con el BI del cliente.
Preguntas frecuentes
Con stock unificado en tiempo real más reservation-with-TTL en el checkout. La consulta de stock consolida WMS, tiendas, reservas activas y tránsitos esperados. Al iniciar checkout, se reserva stock por una ventana corta (típicamente entre 10 y 20 minutos). Si dos clientes llegan al checkout con la última unidad, el segundo recibe un mensaje claro de que se agotó mientras finalizaba.
Depende del SKU. Para productos de baja rotación, un cache con TTL de 30 a 60 segundos es razonable. Para SKUs de alta rotación o piezas únicas, el cache es muy corto o se va siempre live al sistema fuente. La política de cache se configura por categoría según las reglas del negocio y se monitorea para detectar inconsistencias.
Sí, y se diseña para eso. Cache en CDN para catálogo, cache en Object Store para queries calientes, scatter-gather con timeouts cortos, auto-scaling de runtimes. El load testing previo simula picos de varias decenas de veces el tráfico baseline. La arquitectura tolera degradación parcial: si una fuente cae, las demás siguen sirviendo y el flujo principal continúa.
Con un pos-sapi minimalista. La app del staff puede ser una web mobile-friendly que recibe la pickup task, muestra el detalle del pedido y permite marcar como ready y como delivered. Si la tienda tiene POS moderno, se integra al sistema existente. Si no, se entrega esa pieza ligera como parte del proyecto.
Conceptualmente sí, pero hay que respetar sus quirks. Cada marketplace tiene políticas de refund, fees, formatos de productos y reglas de cancelación distintas al e-commerce propio. La integración pasa por su System API específica (meli-orders-sapi, amazon-sapi) que abstrae esas diferencias y entrega al hub interno un objeto Order canónico.
Stock, precios y promociones que dicen lo mismo en todos lados.
Hablemos de tus canales y diseñamos juntos el roadmap omnicanal.