Cómo elegir la plataforma de un eCommerce B2B industrial: los criterios que deciden el proyecto
Respuesta corta: en un canal B2B industrial, la plataforma no se elige comparando funcionalidades de escaparate. Se elige después de responder a cinco preguntas: qué proporción del alcance es realmente transaccional, cuántas tarifas conviven y si hay descuentos en cascada, qué sistema calcula el precio neto, qué sistemas están en transición y quién opera la infraestructura a tres años. Con esas cinco respuestas por escrito, la lista de plataformas viables se reduce sola. Sin ellas, cualquier estimación es una apuesta.
Esta guía recoge el método que aplicamos en eComm360 antes de recomendar nada. No hay una plataforma ganadora al final. Hay un orden de preguntas.
Qué parte de tu proyecto es realmente comercio
Casi todos los proyectos B2B llegan presentados como «un eCommerce nuevo». Casi ninguno lo es.
Antes de comparar plataformas hay que contar los requerimientos y ver dónde caen. La proporción entre lo transaccional —carrito, pedido, pago, pricing— y todo lo demás —catálogo técnico, documentación, perfiles profesionales, contenido, captación— decide qué se está comprando de verdad.
Si el bloque transaccional es una minoría clara del alcance, elegir la plataforma por su motor de comercio es elegirla por la parte pequeña.
El contraste rápido: número de pedidos al año frente a número de usuarios registrados y de referencias activas. Si los pedidos son órdenes de magnitud menores, el canal es de audiencia y catálogo, no de transacción. Y eso cambia por completo la decisión.
Las cinco preguntas de diagnóstico
Sin estas respuestas por escrito, cualquier presupuesto que reciba será orientativo en el mejor de los casos.
- ¿Cuántas tarifas distintas conviven, y hay descuentos en cascada? Es la pregunta que más presupuesto mueve y la que casi nunca aparece en el pliego.
- ¿Quién calcula el precio neto: el ERP, el CRM o la tienda? Determina la arquitectura entera.
- ¿Qué sistemas están en transición y con qué fecha? Un ERP que se reemplaza en doce meses hace que un conector profundo se pague dos veces.
- ¿Quién es la fuente de verdad de cada dato? Producto, precio, stock, cliente, contenido. Un dato con dos dueños es un incidente esperando fecha.
- ¿Quién opera la infraestructura a tres años? Con un stack autoalojado el coste no desaparece: se traslada del licenciamiento al mantenimiento.
Qué significa «tarifas» en B2B: trece capacidades, no un campo precio
Cuando un pliego dice «tarifas por cliente», puede estar describiendo trece cosas distintas. Conviene marcar cuáles aplican antes de mirar ninguna plataforma:
- Tarifas por grupo de cliente
- Matriz grupo de cliente × categoría de producto
- Precio neto negociado por cliente concreto
- Escalados por cantidad
- Descuentos en cascada: tarifa, cliente, línea y promoción
- Ventana de vigencia por tarifa
- Divisa y país como eje de precio, no como conversión
- Precio con o sin impuestos según canal y país
- Ocultar precio o solicitar presupuesto
- Cálculo en tiempo real contra el sistema maestro
- Carga y mantenimiento masivo de tarifas
- Mínimos de pedido, portes y crédito ligados a la tarifa
- Trazabilidad: por qué este cliente vio este precio
Las que hunden proyectos son la 3, la 5, la 10 y la 13. Ninguna plataforma de comercio las trae resueltas de serie. Las que sí suelen venir de fábrica son la 1, la 4 y la 7.
El método de la matriz
Tipologías de cliente en un eje. Categorías de producto en el otro. Cada intersección define una tarifa.
Se dibuja en una pizarra en dos minutos y es el mejor primer entregable de cualquier proyecto B2B. Si el equipo comercial no sabe rellenarla, el reto todavía no es tecnológico.
Las dos únicas arquitecturas de precio
Todo el diseño de un canal B2B con ERP detrás se reduce a elegir entre estas dos.
Tarifa replicada
El sistema maestro vuelca listas al motor de comercio, que calcula el precio.
- A favor: rápido, funciona con el maestro caído, sin latencia.
- En contra: se rompe con contratos por cliente, cascadas o cambios frecuentes. La replicación se desincroniza y el cliente ve un precio y factura otro.
- Cuándo vale: pocas tarifas, estructura estable, pocos cambios.
Tarifa calculada
El precio lo calcula el ERP o el CRM. El comercio lo pinta y lo inyecta en la línea de pedido.
- A favor: correcto por definición. Una sola fuente.
- En contra: exige caché con vigencia pactada, contrato de latencia y plan de degradación.
- Cuándo vale: contratos por cliente, cascadas, precio propiedad de otro sistema.
Regla de degradación, innegociable: si la fuente no responde, se sirve el último neto validado y se marca como tal. Nunca un error en pantalla y nunca un precio inventado.
Regla de trazabilidad: cada precio servido queda registrado con su origen, su versión de tarifa y su momento. Es lo que permite responder a un cliente por qué vio lo que vio. Esa necesidad siempre aparece más tarde de lo que se cree.
La consecuencia estructural: con un ERP o un CRM detrás, el cerebro del precio acaba fuera del motor de comercio en los dos escenarios. Eso es capa de integración, no escaparate. Y no depende de qué plataforma se elija.
Dónde vive cada dato: cuatro capas y una regla
| Capa | Qué contiene |
|---|---|
| Experiencia | Portal, área profesional, biblioteca técnica, tienda |
| Servicios | Contenido, catálogo, búsqueda, identidad, precio |
| Integración | Contratos de datos, colas, reintentos, caché, trazabilidad |
| Dato | ERP, CRM, PIM, DAM |
La regla: si un dato existe en el ERP, el CRM o el PIM, no se escribe en el CMS. El contenido editorial guarda la referencia del producto, nunca sus datos.
Incumplirla produce dos catálogos que divergen sin que nadie sepa cuál gana. Es el fallo más caro y más frecuente de las arquitecturas componibles, y no es técnico: es de gobierno del dato.
El mapa de plataformas: cuándo gana cada una
| Eje | Monolito (PrestaShop, Magento) | SaaS (Shopify Plus) | Sylius | Saleor | MedusaJS |
|---|---|---|---|---|---|
| Licencia | Sin licencia | Cuota + comisión | Gratis; B2B avanzado de pago | Sin licencia | Sin licencia (MIT) |
| Contenido y catálogo | Acoplados | Acoplados, CMS limitado | Acoplados | Separables | Separados por diseño |
| Tarifas por cliente | Vía módulos | Nativo por company | Edición de pago | Override de línea vía app | Listas + precio por línea |
| Multi-mercado | Una tienda por mercado | Markets, con límites | Canales | Canales nativos, punto fuerte | Regiones y canales |
| Catálogo técnico y CAD | A medida | Fuera de su terreno | A medida | Vía PIM | Vía PIM |
| Quién opera | Cliente | Proveedor | Cliente | Cliente | Cliente |
| Talento disponible | Alto (PHP) | Alto | Medio (PHP) | Bajo (Python/GraphQL) | Medio-alto (TypeScript) |
| Riesgo principal | Deuda acumulada | Dependencia y coste variable | Comunidad pequeña | Talento escaso | Exige decidir qué se construye |
Monolito evolucionado. Gana cuando el catálogo es simple, el equipo ya lo conoce y no hay presión de multipaís. Sigue acoplando contenido, catálogo y tienda: el coste no está en lo que hay, está en lo que cuesta añadir lo siguiente.
Shopify Plus. Gana cuando importa salir rápido, el B2B es de manual —cuentas, catálogos por cliente, condiciones de pago— y se prefiere delegar la operación. Se paga con cuota, comisión y datos fuera. Flojea cuando el proyecto es biblioteca documental, CAD, BIM y perfiles profesionales.
Sylius. Gana cuando el ecosistema ya es PHP y se quiere código abierto. Comprobar antes qué piezas B2B están en la edición de pago, porque suelen ser justo las que hacen falta: precios avanzados y multi-almacén.
Saleor. Gana cuando hay muchos mercados con precio, divisa, stock y fiscalidad diferenciados. Su modelo de canal es el mejor resuelto de origen. El precio por cliente se hace con override de línea desde una app, que es una solución honesta cuando el precio lo calcula otro sistema.
MedusaJS. Gana cuando se quiere control total, sin licencia ni comisiones, con un starter B2B que ya trae cuentas de empresa y empleado, límites de gasto, aprobaciones, presupuestos, listas de precio por cuenta y precio personalizado a nivel de línea de pedido. Sus flujos incorporan reintentos y compensación, algo que en una integración con ERP pesa más que cualquier funcionalidad de escaparate.
Dos avisos sobre MedusaJS:
- Se ha reportado que el precio calculado resuelve tomando el mínimo entre listas aplicables. Con varias tarifas solapadas, «el precio más bajo» y «el precio que le corresponde a este cliente» no son lo mismo. Hay que dominar esa lógica o vigilarla.
- Se autoaloja y se opera. Base de datos, colas, actualizaciones y observabilidad van en el presupuesto, o aparecen después.
¿Hace falta un PIM?
Con dos o más de estas señales, el PIM deja de ser un lujo y pasa a ser camino crítico:
- El mismo producto se describe en más de un sitio.
- Los datos llegan de orígenes heterogéneos: ERP, hojas de cálculo, PDF de proveedor, portales de marca.
- Hay variantes complejas: acabados, medidas, configuraciones.
- Hay documentación por referencia: fichas, certificados, CAD, BIM.
- Hay más de un canal de salida: web, catálogo PDF, partners, marketplaces.
Qué mirar al elegirlo
- Modelo de coste. Muchos parecen económicos hasta que se añaden dos módulos. Pedir el precio con el alcance completo, no el de entrada.
- API y capacidad de salida. Un PIM que estructura bien pero publica mal resuelve la mitad.
- DAM incluido o no. El reto de los activos llega justo después del de los atributos, y muchos PIM lo resuelven flojo.
- Completitud y control de calidad. Saber qué referencia está lista para publicar y cuál no.
- Servidor MCP o API consultable. Si hay ambición de agentes, el catálogo tiene que ser consultable por máquina.
El paso previo que nadie presupuesta
Antes del PIM hace falta una capa de normalización que traduzca cada origen al lenguaje de la casa: equivalencias de código, unidades, colores, tallas, duplicados, calidad de imagen. Y una cola de revisión donde lo dudoso se decide una vez y queda aprendido como regla para la temporada siguiente.
Lo importante no es acertar el cien por cien de forma automática. Es que la mayoría se resuelva sola, que el resto aparezca en una lista concreta en vez de descubrirse en la tienda, y que cada decisión manual quede guardada.
Y si el PIM aún no está elegido, no hace falta bloquear el proyecto: se construye el modelo de producto neutro sobre una capa propia y se conecta el PIM definitivo después, contra el mismo contrato de datos.
Integración: punto a punto o capa intermedia
Con N orígenes y M destinos, las integraciones directas producen hasta N×M caminos sin contrato. Cambia una fuente y hay que revisarlos todos.
Con una capa intermedia son N+M contratos. Cambia una fuente y se sustituye un conector.
La diferencia se nota poco con tres sistemas y es decisiva con ocho. Es también la única forma de que un reemplazo de ERP no obligue a rehacer la plataforma.
Lo que hay que exigir a esa capa
- Contratos de datos estables. La plataforma no debe saber qué ERP hay detrás.
- Eventos y colas. Un sistema lento no puede bloquear la navegación ni la venta.
- Reintentos con compensación. Si falla el paso que crea el pedido en destino, se deshacen los anteriores. Nada de estados a medias.
- Idempotencia. El mismo pedido enviado dos veces se registra una. Es la diferencia entre reintentar y duplicar.
- Caché con vigencia pactada y plan de degradación explícito.
- Trazabilidad. Origen, versión del dato, momento y resultado, consultables desde el backoffice.
Seis preguntas concretas sobre su ERP
- ¿Expone API moderna o solo servicios heredados?
- ¿Existe la operación que hace falta, o hay que programarla del lado del ERP? Es habitual que la creación de pedido de venta no venga de serie.
- ¿Hay límites de tamaño en las peticiones masivas?
- ¿Qué versión del entorno se necesita para las funciones previstas?
- ¿La seguridad es por lista blanca de IP? Entonces el alojamiento necesita IP fija declarada.
- ¿Quién programa del lado del ERP y con qué calendario? Casi siempre es el partner del ERP, y su plazo condiciona el del proyecto. Conviene dejarlo por escrito antes de firmar.
Agentes, MCP y asistencia a la compra
Es la ambición declarada de casi todos los proyectos nuevos y la parte donde más ruido circula.
Un asistente o un agente no funciona por el CMS que haya debajo. Funciona si el catálogo está normalizado y expuesto por API. La normalización es el trabajo previo, no la guinda.
Traducido a decisiones:
- Cualquiera de las plataformas modernas lo permite. Un catálogo sucio no lo permite en ninguna.
- Lo que hay que exigir hoy es API documentada y datos estructurados, no una funcionalidad de IA en el folleto.
- Un configurador es un caso particular de esto. Su complejidad no depende del producto: depende de cómo esté definido y de cómo se venda. Si el usuario final es el técnico que ya tiene su propio software y sus librerías, no lo va a abandonar por una web.
Seis señales de alarma en una propuesta
- Un MVP cuyo plazo no cuadra con el número de requerimientos. La más frecuente y la más cara.
- Ninguna partida de discovery, gobierno, migración, seguridad, accesibilidad o formación. Si no están, se harán igual y se cobrarán después.
- Cobertura nativa muy alta sobre una arquitectura componible. Con un motor headless casi todo lo específico se construye. Una matriz optimista se cae en el UAT.
- Precio cerrado sin condiciones de calendario. Si no dice qué espera del cliente y de terceros, el retraso acabará siendo de alguien.
- Silencio sobre quién opera la infraestructura. Con stack autoalojado alguien mantiene base de datos, colas y actualizaciones.
- Un plan que no dice qué queda fuera. Delimitar lo que no se va a hacer es tan importante como listar lo que sí.
Cómo verificar lo que dice un proveedor
Los motores de comercio modernos son backend y no emiten nada al HTML. Las herramientas de detección solo ven el front, que casi siempre es el mismo framework. Un listado de «tiendas con X» obtenido así es en realidad un listado de tiendas con ese framework.
La referencia útil no es «tenemos experiencia». Es: dos tiendas en producción con esta arquitectura, a poder ser con ERP integrado, y media hora de conversación con ellas.
Y si se ha pedido clasificar requerimientos entre nativo, configuración y desarrollo, conviene elegir diez filas marcadas como nativas y pedir verlas funcionando en la demo. Las categorías donde suele haber optimismo: gestión documental, workflow editorial con aprobaciones, gestión de proyectos, localizadores y accesibilidad.
Checklist de decisión antes de firmar
- Proporción real entre alcance transaccional y no transaccional
- Número de tarifas y existencia de cascadas
- Quién calcula el precio neto
- Sistemas en transición y sus fechas
- Fuente de verdad de cada dato
- Estado de la decisión de PIM y DAM
- Quién programa del lado del ERP y con qué calendario
- Quién opera la infraestructura a tres años
- Presupuesto anual de evolutivo, además del de implantación
- Propiedad del código y plan de salida
- Dos referencias en producción con arquitectura equivalente
- Qué queda explícitamente fuera del alcance
Si más de tres siguen en blanco, todavía no es momento de elegir plataforma.
Preguntas frecuentes
¿Cuál es la mejor plataforma para un eCommerce B2B industrial? No existe una respuesta única. La elección depende de cuántas tarifas conviven, de qué sistema calcula el precio neto, del peso del catálogo técnico frente al transaccional y de quién va a operar la infraestructura. PrestaShop y Shopify Plus resuelven bien escenarios de catálogo controlado y B2B estándar; Saleor y MedusaJS encajan mejor en multi-mercado y arquitecturas componibles.
¿Qué diferencia hay entre tarifa replicada y tarifa calculada? En la replicada, el ERP vuelca listas de precio a la tienda y la tienda calcula. En la calculada, el precio lo resuelve el ERP o el CRM en tiempo real y la tienda solo lo muestra e inyecta en la línea de pedido. La primera es rápida y frágil ante cascadas; la segunda es correcta por definición, pero exige caché, contrato de latencia y plan de degradación.
¿Necesito un PIM antes de lanzar el canal B2B? Si el mismo producto se describe en más de un sitio, los datos llegan de orígenes heterogéneos o hay documentación técnica por referencia (fichas, certificados, CAD, BIM), el PIM es camino crítico. Si aún no está decidido, se puede construir un modelo de producto neutro y conectar el PIM definitivo después contra el mismo contrato de datos.
¿Por qué una capa de integración y no conectores directos? Con N sistemas de origen y M de destino, las integraciones directas generan hasta N×M caminos sin contrato. Una capa intermedia los reduce a N+M. Es la única forma de que sustituir el ERP no obligue a rehacer la plataforma de comercio.
¿Cuánto se tarda en decidir la plataforma? El trabajo de decisión —matriz de tarifas, fuentes de verdad, inventario de requerimientos y clasificación por tipo de cobertura— suele resolverse en dos o tres semanas de discovery. Es el tramo que más presupuesto ahorra en las fases siguientes.
¿Se puede montar un asistente de IA sobre el catálogo? Sí, si el catálogo está normalizado y expuesto por API. La plataforma casi nunca es el factor limitante: lo es la calidad del dato de producto. Sin normalización previa, ningún motor ni ningún modelo lo resuelve.
Dónde encajamos nosotros
Somos neutrales respecto al motor. Trabajamos sobre PrestaShop y PrestaShop Enterprise, Shopify y Shopify Plus, BigCommerce, VTEX y LogiCommerce, y sobre arquitecturas componibles con Saleor, Sylius y MedusaJS: canal nativo y multi-mercado en Saleor, ecosistema PHP en Sylius, control total y precio personalizado por línea de pedido en MedusaJS.
La plataforma la elige el cliente. Nosotros aportamos el análisis previo que la sostiene y la capa que la conecta con su ERP.
Lo nuestro es la capa que ninguna de ellas trae de serie: la integración con el ERP y el CRM, la normalización del dato de producto y el motor de tarifas B2B. Más de cien integraciones en producción sobre Integrafy, en industria, distribución y construcción.
Y preferimos demostrarlo antes de venderlo. Cuando cualquiera genera una propuesta en minutos, lo que distingue es enseñar software funcionando con los datos del cliente.
Integrado, automatizado, rentable.
¿Está en fase de decisión? Hablemos de su caso: ibosch@ecomm360.es · www.ecomm360.es
