B2x Commerce y lo que significa para la arquitectura de frontend

B2B y B2C ya no son desarrollos separados. Cada vez más marcas venden a empresas y a consumidores desde el mismo catálogo, el mismo dominio y, cada vez más, el mismo storefront. Esa convergencia tiene nombre, B2x commerce, y presiona una parte del stack que la mayoría de los proyectos de replatforming tratan como algo secundario: el frontend. Los precios específicos por cuenta, los roles y las aprobaciones, los catálogos mixtos y el self-service no son funcionalidades de backend que se activan con un interruptor. Son experiencias que hay que componer en la superficie, por usuario y por sesión.

¿Qué es el B2x commerce?

El B2x commerce es el modelo operativo en el que un único storefront atiende tanto a compradores empresariales como a consumidores finales sin bifurcarse en dos aplicaciones separadas. La "x" representa aquello que resulte ser el visitante: un comprador anónimo, un consumidor identificado, un usuario de compras con un contrato negociado o un revendedor con precios específicos por cuenta. En lugar de mantener una tienda B2C y un portal B2B en paralelo, un setup B2x resuelve el contexto del comprador en tiempo de ejecución y renderiza el catálogo, los precios y las acciones correctos para ese contexto.

El motivo por el que esto importa ahora: la línea entre ambas audiencias se ha difuminado. Los compradores B2B esperan el self-service y la rapidez que tienen como consumidores particulares, y las marcas de consumo abren cada vez más niveles wholesale, pro o de membresía. Mantener dos bases de código para lo que en gran medida es el mismo catálogo sale caro y garantiza que las dos experiencias acaben separándose.

Por qué la lógica B2x pertenece al frontend y no al monolito de backend

Existe la tentación de asumir que B2x es un problema de backend: añades un módulo B2B, activas los precios por cuenta y listo. En la práctica, la mayor parte de lo que hace funcionar una experiencia B2x se decide en la superficie.

Piensa en lo que cambia entre un consumidor y un comprador empresarial en la misma página de producto:

• Precio: precio de tarifa frente a un precio de contrato ligado a la cuenta.
• Disponibilidad y unidades: artículos sueltos frente a cantidades por caja o importes mínimos de pedido.
• Acciones: "añadir al carrito" frente a "solicitar presupuesto", "añadir a la lista de pedido" o "enviar para aprobación".
• Visibilidad del catálogo: algunos SKU son solo para consumidores, otros están restringidos a cuentas aprobadas.
• Navegación y contenido: un comprador empresarial ve recompra, presupuestos y centros de coste donde un consumidor ve listas de deseos y recomendaciones.

Ninguno de estos es un único valor de backend. Se componen a partir de varias fuentes a la vez: el backend de commerce para el catálogo base, un servicio de precios o contratos para los precios específicos por cuenta, un proveedor de identidad para los roles y una capa de contenido para los mensajes. El frontend es la única capa que los ve todos juntos para un usuario dado en una sesión dada. Por eso la lógica B2x tiene que componerse ahí. Un monolito de backend puede almacenar los datos, pero no puede ensamblar la experiencia sin convertirse en un segundo frontend encubierto.

Los roles y las aprobaciones son un asunto de sesión

Los flujos de aprobación son el ejemplo más claro. Que un usuario pueda finalizar la compra, o solo enviar un carrito para que lo apruebe un responsable, depende del rol asociado a su sesión, del importe del carrito y de las reglas de la cuenta. Esa decisión cambia la UI en tiempo real: botones, banners y pasos disponibles. Codificarla en lo profundo del backend significa que cada cambio en una regla de aprobación espera a una release de backend. Compuesta en el frontend, contra una API de roles, ese mismo cambio se publica como un despliegue de frontend.

Cómo un frontend Composable resuelve B2x sin replatformar el backend

El movimiento Composable para B2x es el mismo que se aplica a la búsqueda, los pagos y las suscripciones: dejar los sistemas especializados donde están y componer la experiencia en una capa de frontend desacoplada. En concreto:

• Una capa de datos unificada (normalmente GraphQL) se sitúa delante del backend de commerce, del servicio de precios o contratos y del proveedor de identidad, de modo que el frontend consulta un único endpoint y recibe catálogo, precio de cuenta y rol en una sola respuesta resuelta.
• El contexto del comprador (anónimo, consumidor, cuenta empresarial, rol) se resuelve por sesión y determina qué componentes se renderizan. Un frontend Composable y Headless trata ese contexto como una entrada de primer nivel, no como un caso especial pegado a un tema B2C.
• El catálogo, los precios y los roles se quedan en sus propios sistemas. No migras el backend para obtener comportamiento B2x; compones sobre el backend que ya tienes en marcha.
• La misma biblioteca de componentes renderiza para ambas audiencias. Una tarjeta de producto, un bloque de precio o una acción de carrito se vuelve consciente del contexto una sola vez, y cada página que la usa hereda el comportamiento B2x.

Como la lógica vive en una capa desacoplada, un equipo puede añadir un flujo de "solicitar presupuesto" o una lista de pedido al storefront de consumo existente sin tocar el backend y sin levantar una aplicación B2B aparte. El composable storefront es un único desarrollo que se comporta de forma distinta según el contexto del comprador, no dos desarrollos cosidos entre sí.

Catálogos mixtos y self-service en un solo desarrollo

Dos de los requisitos B2x más difíciles, los catálogos mixtos y el self-service, muestran por qué el frontend es el lugar adecuado para componer.

Los catálogos mixtos significan que el mismo storefront expone conjuntos de productos distintos a compradores distintos: SKU de consumo, SKU solo para empresas y SKU restringidos por cuenta. Filtrar eso únicamente en el backend lleva a variantes de API frágiles por audiencia. Resuelta en el frontend contra el contexto del comprador, la visibilidad del catálogo se convierte en un parámetro de consulta, y un único conjunto de componentes de listado y de detalle cubre todos los casos.

El self-service, es decir, la gestión de la cuenta, el historial de pedidos, la recompra, los presupuestos y la administración de usuarios, es donde los clientes B2B pasan la mayor parte del tiempo, y donde la experiencia se rompe con más frecuencia cuando se les redirige a una pantalla de administración del backend. Compuesta en el frontend, el área de cuenta usa los mismos componentes que el storefront, así que el comprador empresarial nunca sale de tu marca para gestionar su cuenta.

Módulo B2B nativo frente a frontend B2x Composable

• Dimensión | Módulo B2B nativo del backend | Frontend B2x Composable
• Contexto del comprador | Fijo por tienda o por sitio | Resuelto por sesión y rol
• Precios específicos por cuenta | Valor de backend, control de visualización limitado | Compuesto en la superficie, con estilo completo
• Roles y aprobaciones | Ciclo de release del backend | Despliegue de frontend, contra una API de roles
• Catálogos mixtos | Variantes de API separadas por audiencia | Una consulta, visibilidad guiada por el contexto
• Área de self-service | A menudo una pantalla de administración del backend | La misma biblioteca de componentes que el storefront
• Añadir B2C a un desarrollo B2B (o al revés) | Una segunda aplicación | Un solo desarrollo, un nuevo contexto

FAQ

¿El B2x commerce es simplemente B2B y B2C en el mismo dominio? No. Compartir dominio es la parte fácil. B2x significa que un único storefront resuelve el contexto del comprador en tiempo de ejecución y renderiza el catálogo, los precios y las acciones correctos para ese usuario, en lugar de derivarlo a una aplicación B2B o B2C separada.

¿Necesitamos replatformar el backend para soportar B2x? No. La idea de componer B2x en el frontend es precisamente que el catálogo, los precios y la identidad se quedan en sus sistemas actuales. Una capa de datos unificada los une y el frontend ensambla la experiencia sobre el backend que ya tienes en marcha.

¿De dónde salen los precios específicos por cuenta? Normalmente de un servicio de precios o de contratos separado del catálogo base. El frontend solicita el precio resuelto para la cuenta actual a través de la capa de datos unificada y lo renderiza en el mismo componente de precio que ven los consumidores, con valores distintos.

¿Cómo se gestionan los flujos de aprobación? El rol del usuario y las reglas de la cuenta se resuelven por sesión. El frontend los lee de una API de roles y ajusta en tiempo real las acciones disponibles, finalizar la compra frente a enviar para aprobación. Los cambios de reglas se publican como despliegues de frontend, no como releases de backend.

¿Podemos empezar con B2C y añadir B2B más adelante? Sí, y esa es la ventaja principal. Como el contexto del comprador es una entrada de primer nivel del frontend, añadir un nivel empresarial significa añadir un contexto y sus componentes, no construir un segundo storefront.

Más de la Laioutr Platform

• Composable Headless Frontend: la capa desacoplada donde el contexto del comprador, los precios y los roles se componen en una sola experiencia.
• Composable Storefront: un único desarrollo que renderiza tanto para compradores empresariales como para consumidores sin bifurcarse en dos aplicaciones.
• Frontend as a Service: cómo se opera y despliega la capa de frontend con independencia del backend de commerce.
• Agentic Frontend Management Platform: cómo los cambios rutinarios en las reglas de contexto y en los componentes pueden gestionarse con agentes de IA.

Siguiente paso

¿Quieres ver cómo se vería tu lógica B2x, precios por cuenta, roles, catálogos mixtos y self-service, compuesta en un frontend desacoplado? Habla con el equipo de Laioutr y te lo mapeamos sobre el backend que ya tienes en marcha.