Ship From Store en Salesforce Commerce Cloud: Cómo Funciona

Ship from store es un modelo de fulfillment en el que el retailer usa las tiendas físicas como puntos de distribución para pedidos online, en lugar de enrutar todo a través de un centro de distribución centralizado. Si un cliente compra un producto y la tienda más cercana tiene el artículo en stock, el pedido sale de esa tienda, no de un CD que puede estar a cientos de kilómetros de distancia.

Vale la pena separar este concepto del BOPIS (compra online, retira en tienda), que resuelve un problema distinto: el cliente sigue yendo a la tienda, pero para recoger el pedido en persona, no para recibirlo en casa. Ambos modelos dependen de la misma visibilidad de stock a nivel de tienda, pero el flujo de fulfillment y la carga operativa sobre el equipo del punto de venta son diferentes. Si estás evaluando qué modelo tiene sentido para tu red de tiendas, conviene entender bien esa comparación antes de decidir cuál construir primero.

Para equipos que operan Salesforce Commerce Cloud (SFCC), esto no es un sistema paralelo pegado encima de la plataforma. La gestión de inventario y de pedidos es nativa de SFCC, lo que significa que el stock en tiempo real de cada tienda puede conectarse directamente al escaparate online, dando una visión única de inventario total entre canales. El resto de este artículo detalla cómo funciona ese flujo en la práctica, qué cuesta en esfuerzo de ingeniería y por dónde empezar la evaluación del build.

Cómo Funciona Ship From Store Dentro de Salesforce Commerce Cloud

La mecánica es directa sobre el papel. La complejidad está en los detalles de integración: precisión de inventario, lógica de asignación y la sincronía entre la operación de tienda y lo que el escaparate promete al cliente.

1. Una Única Visión de Inventario Entre Canales

Como la gestión de inventario y de pedidos corre nativamente en SFCC, el stock de tienda y el stock de e-commerce no son dos libros contables separados que haya que reconciliar después. La plataforma entrega un único sistema de registro para el inventario total, tiendas físicas y centros de distribución incluidos. Si tu operación ya sufre divergencias entre esos números, vale la pena revisar tu gestión de inventario antes de avanzar con ship from store.

2. Pedido Recibido, Disponibilidad Verificada en Tiempo Real

Cuando el cliente finaliza la compra, el sistema verifica la disponibilidad del producto en todas las ubicaciones, tiendas físicas y centros de distribución juntos. Sin consulta manual, sin job en lote corriendo cada hora: la verificación ocurre en el momento del pedido.

3. Asignación de Inventario Basada en Proximidad

El sistema asigna el stock a una tienda específica según la disponibilidad más cercana. La lógica de asignación pondera la proximidad del cliente, la cantidad disponible en cada tienda y otras reglas de negocio que tú definas, por ejemplo, si una tienda por debajo de un umbral mínimo de stock debe quedar fuera de la asignación para proteger las ventas presenciales.

4. Preparación del Pedido en Tienda

El equipo de la tienda recibe la notificación del pedido y pasa a ser responsable de picking, empaque y preparación del envío. Aquí es donde ship from store deja de ser un problema de integración de backend y se convierte en un problema operativo: el equipo de tienda gana un flujo de fulfillment superpuesto a sus funciones de retail.

5. Envío del Pedido

El pedido sale directamente de la tienda hacia la dirección del cliente, generalmente a través de las mismas transportistas ya integradas al fulfillment vía centro de distribución.

6. Actualización de Estado en Tiempo Real

Inventario y estado del pedido se actualizan en tiempo real conforme el pedido avanza por picking, empaque y envío. El cliente recibe la misma experiencia de seguimiento que tendría con un pedido salido de un CD, y esa consistencia es parte de lo que hace funcionar el modelo desde el punto de vista de experiencia.

El Caso de Negocio: Por Qué los Retailers Adoptan Ship From Store

Las ventajas se mapean directamente a métricas que el negocio ya monitorea:

• Entrega más rápida. Los pedidos atendidos por una tienda cercana eliminan la distancia que normalmente cubriría un centro de distribución.

• Mejor experiencia del cliente. Entrega más rápida sumada a un seguimiento consistente reduce la brecha entre la expectativa online y la expectativa de tienda física.

• Costo de envío menor. Distancias de envío más cortas suelen significar un costo de transportista menor por pedido, sobre todo en la última milla.

Nada de esto es automático. Depende de que la lógica de asignación sea precisa y de que la operación de tienda sea lo suficientemente confiable para que "ship from store" no se convierta en "ship from store, a veces, cuando el artículo realmente está ahí".

Trade-offs de Ingeniería que los Tech Leads Deben Planificar

Esta es la parte que no aparece en el pitch comercial, y es la que más importa para quien responde por la arquitectura.

La precisión de inventario deja de ser deseable y se convierte en un requisito duro. Si el conteo de stock a nivel de tienda se aleja de la realidad, un problema común en el retail físico, el motor de asignación va a prometer stock que en realidad no existe. Ship from store aumenta el costo de cualquier divergencia de inventario porque esta pasa a exponerse al cliente en tiempo real, no solo como una discrepancia de reporte interno.

El equipo de tienda absorbe carga operativa nueva sin aumento de headcount. Hacer picking y empacar pedidos online compite con el tiempo del equipo en el piso de venta. Es una decisión de negocio, no técnica, pero afecta directamente con qué agresividad puedes asignar pedidos a una tienda determinada.

La dependencia de geolocalización añade un servicio externo a tu historia de disponibilidad. La asignación basada en proximidad normalmente requiere un servicio de geolocalización (ver los prerrequisitos abajo). Es una dependencia externa más en el camino de fulfillment, que vale la pena considerar en el SLA y en la lógica de fallback.

Estás extendiendo la lógica de fulfillment, no sustituyéndola. Ship from store coexiste con el fulfillment vía centro de distribución que ya tienes, no lo reemplaza. Las reglas de asignación necesitan decidir, pedido a pedido, qué fuente prevalece, y esas reglas tienen que ser mantenibles por quien herede ese código después de ti.

Si tu equipo ya está al límite, el camino realista es tratar esto como una extensión de los modelos de pedido e inventario ya existentes en SFCC, no como un sistema paralelo, y es exactamente por eso que un punto de partida ya construido importa más aquí que en la mayoría de las integraciones.

Prerrequisito Técnico: Google Geolocation API

La asignación de tienda basada en proximidad depende de un servicio de geolocalización. Si usas el de Google, vas a necesitar:

• Una cuenta en Google Cloud Console

• Un proyecto nuevo (si aún no tienes uno dedicado a esta integración)

• La Maps JavaScript API habilitada

• Una clave de API creada para el proyecto

• La clave de API restringida a los dominios/servicios relevantes (recomendado, no opcional, si esto está orientado al cliente final)

• Billing configurado en el proyecto, ya que la Maps API es un servicio pago más allá del tier gratuito

Es una pieza pequeña del build general, pero es una dependencia externa que vale la pena documentar con claridad para quien mantenga esta integración después del go-live.

Un Punto de Partida: Cartridge SFS Open Source

En lugar de construir la lógica de asignación a nivel de tienda desde cero, Develoci mantiene un cartridge open source de Ship From Store para SFCC en GitHub. No sustituye las decisiones arquitectónicas específicas de tu red de tiendas y de tus reglas de asignación, pero le da a tu equipo una referencia funcional en lugar de una página en blanco:

Cartridge Ship From Store en GitHub

Dónde Entra Develoci

Si estás evaluando ship from store y no tienes espacio para crecer el equipo y construir y mantener esto internamente, esta es la situación con la que trabajamos con más frecuencia. Hacemos el scoping de la integración contra tu instancia SFCC existente, señalamos los trade-offs específicos de tu red de tiendas y de la precisión de tu inventario, y construimos la lógica de asignación como extensión de lo que ya tienes, no como un sistema paralelo que haya que reconciliar para siempre.

Si estás sopesando ship from store frente a tu fulfillment actual, o decidiendo si debe coexistir con BOPIS en la misma instancia SFCC, vale la pena discutir la arquitectura antes de comprometer horas de ingeniería en esto. Agenda una conversación con nuestro equipo para evaluar la integración contra tu red de tiendas y tu modelo de inventario.