Un catálogo no tiene por qué ser igual para todos tus clientes
En un ecommerce B2B, el Catálogo B2B por cliente permite que los productos disponibles cambien según quién ha iniciado sesión, su perfil comercial, sus permisos o las condiciones que ya mantiene la empresa en el ERP. No se trata solo de ofrecer Precios diferentes: dos Clientes pueden entrar en la misma tienda y tener acceso a productos diferentes.
Entramos en un ecommerce.
Buscamos un producto.
No aparece.
¿Significa que no existe?
No necesariamente.
Puede existir en el ERP.
Puede tener Stock.
Puede venderse online.
Y otro cliente conectado a la misma tienda puede estar viéndolo en ese mismo momento.
La diferencia es sencilla:
ese producto no forma parte de nuestro catálogo.
Estamos acostumbrados a pensar el catálogo ecommerce como una colección relativamente estable:
Productos publicados → categorías → cliente
Primero decidimos qué vendemos y después dejamos que los clientes naveguen por ello.
En B2B, distribución profesional y determinados sectores regulados, el orden puede ser diferente.
Cliente → condiciones → catálogo disponible
Lo que puede comprar forma parte de la relación comercial.
Personalizar el precio no es personalizar el catálogo
Supongamos que distribuimos material profesional.
Tenemos tres clientes.
Cliente A — Distribuidor
Puede comprar todo el catálogo y tiene la tarifa DISTRIBUIDOR.
Cliente B — Instalador autorizado
Puede comprar determinadas familias profesionales y tiene la tarifa INSTALADOR.
Cliente C — Particular
Puede comprar únicamente la gama destinada al consumidor.
Podríamos resolver los precios perfectamente y aun así tener mal planteado el ecommerce.
Porque la pregunta no es solamente:
¿A qué precio puede comprar este cliente?
También:
¿Qué puede comprar?
Son decisiones diferentes.
Un producto puede costar 80 € para un cliente y 72 € para otro.
Eso es precio personalizado.
Pero si el segundo cliente ni siquiera debería tener acceso al producto, estamos hablando de catálogo personalizado.
Y si puede verlo pero no comprarlo, aparece todavía otra dimensión:
permiso de compra.
Ver, comprar y pagar no son la misma decisión en un catálogo B2B por cliente
Conviene separar tres preguntas.
¿Puede verlo?
Determina si el producto forma parte del catálogo visible para ese cliente. En Shopify, los catálogos B2B determinan los productos a los que pueden acceder tus clientes.
¿Puede comprarlo?
Puede existir un producto visible cuyo pedido esté restringido a determinados perfiles.
¿A qué precio?
Una vez sabemos que puede comprarlo, todavía debemos determinar sus condiciones comerciales.
Podemos expresarlo así:
VISIBILIDAD
¿Puede verlo?
↓
ACCESO
¿Puede comprarlo?
↓
CONDICIONES
¿A qué precio y bajo qué reglas?
Parece una distinción pequeña.
En la práctica evita intentar resolver tres problemas diferentes mediante una única tarifa o grupo de clientes.
Un catálogo puede ser una función del cliente
En un ecommerce sencillo podemos imaginar:
CATÁLOGO = productos publicados
En otros contextos se parece más a:
CATÁLOGO = productos × cliente × permisos × contexto
No significa que debamos crear físicamente un catálogo diferente para cada cliente.
Significa que la vista del catálogo puede calcularse a partir de relaciones y reglas.
Por ejemplo:
Cliente → pertenece a → Grupo profesional
Grupo profesional → puede acceder a → Familia A
Cliente → tiene autorización → Producto B
Cliente → opera en → Territorio C
El catálogo que finalmente ve el usuario es el resultado de esas relaciones.
Un ejemplo veterinario
Imaginemos un distribuidor con tres tipos de cliente.
Particular
Puede acceder a alimentación y accesorios.
Tienda especializada
Puede acceder además al catálogo profesional correspondiente.
Veterinario
Puede acceder a otro conjunto de productos sujeto a sus condiciones y autorizaciones.
Los tres entran en el mismo ecommerce.
Los tres pueden buscar “producto X”.
Y los tres pueden obtener resultados diferentes.
No porque la búsqueda funcione mal.
Porque el contexto del cliente forma parte de la consulta.
Este patrón aparece también fuera de sectores regulados.
Una red de distribución autorizada funciona de manera parecida
Un fabricante puede trabajar con:
distribuidores;
instaladores;
servicios técnicos;
retailers;
cliente final.
No todos necesitan acceder al mismo catálogo.
Un servicio técnico puede necesitar repuestos que no deberían aparecer en la tienda destinada al consumidor.
Un distribuidor puede comprar cajas completas mientras el consumidor compra unidades.
Un instalador autorizado puede acceder a determinadas gamas profesionales.
Un cliente final puede consultar un producto pero tener que comprarlo mediante la red de distribución.
El producto no ha cambiado.
Ha cambiado la relación entre producto y cliente.
¿Dónde vive esa relación?
Aquí aparece el problema de integración.
El ecommerce puede conocer:
email;
cuenta;
sesión;
grupo de clientes.
Pero el ERP puede conocer:
código de cliente;
tarifa;
tipo de cliente;
comercial;
zona;
condiciones;
clasificación.
Y otro sistema puede mantener:
certificaciones;
autorizaciones;
pertenencia a una red;
contratos.
La pregunta vuelve a ser:
¿qué sistema tiene autoridad sobre cada información?
No deberíamos recrear manualmente en el ecommerce relaciones que ya existen y se mantienen en otro sistema.
El grupo de clientes ayuda, pero no siempre basta
Una solución habitual consiste en crear:
PARTICULAR
PROFESIONAL
DISTRIBUIDOR
VETERINARIO
y asociar cada cuenta a un grupo.
Puede funcionar perfectamente.
Hasta que aparecen excepciones.
Este distribuidor puede comprar la familia A pero no la B.
Este cliente profesional tiene acceso temporal a una gama.
Este instalador pertenece a dos programas diferentes.
Esta empresa opera en dos territorios.
Este cliente tiene una autorización que caduca.
Entonces una clasificación plana empieza a quedarse pequeña.
No significa que los grupos sean incorrectos.
Significa que grupo y regla resuelven problemas distintos.
El grupo expresa una clasificación.
Las reglas pueden combinar varias condiciones.
Tampoco hace falta crear 2.000 catálogos
Si tenemos 2.000 clientes, una interpretación literal de “catálogo por cliente” sería mantener 2.000 listas.
Eso probablemente sería una pesadilla.
Normalmente queremos definir reglas reutilizables.
Por ejemplo:
Mostrar productos de la gama PROFESIONAL cuando el cliente pertenece al canal INSTALADOR y opera en España.
O:
Permitir la familia VET-PRO cuando el cliente tiene una autorización veterinaria activa.
O:
Excluir determinados productos para clientes del territorio X.
Tenemos muchos clientes.
Pero probablemente muchas menos reglas.
Esa diferencia es importante para que el modelo escale.
Permitir y excluir tampoco son exactamente lo mismo
Imaginemos que nuestro catálogo contiene 20.000 referencias.
Podemos definir:
Permitir únicamente estas 500.
O:
Permitir todo excepto estas 500.
El resultado puede parecer parecido.
La política no lo es.
Cuando mañana aparezca un producto nuevo:
¿debería estar disponible automáticamente?
La respuesta depende de cómo hayamos definido la regla.
En el primer modelo:
deny by default
En el segundo:
allow by default
Esta decisión puede ser especialmente importante cuando existen restricciones comerciales o regulatorias.
El contexto también puede cambiar sin que cambie el cliente
Hasta ahora hemos hablado de quién compra.
Pero el contexto puede incluir:
canal;
país;
empresa;
tienda;
proyecto;
contrato;
fecha.
El mismo cliente podría tener acceso a un producto en un canal y no en otro.
O utilizar condiciones diferentes dependiendo de la empresa desde la que realiza el pedido.
Por eso el modelo completo puede terminar pareciéndose a:
Cliente + Producto + Contexto → Decisión
Y la decisión puede responder:
VISIBLE
COMPRABLE
NO DISPONIBLE
REQUIERE VALIDACIÓN
Lo importante es que la decisión sea explícita.
¿Qué ocurre cuando entra un pedido?
Las reglas de catálogo no deberían desaparecer en el momento de pulsar “Comprar”.
Si un producto requiere determinadas condiciones para ser adquirido, la integración debería poder validar que el pedido sigue cumpliéndolas.
Porque el frontend no es necesariamente la última autoridad.
Un pedido puede llegar:
desde el ecommerce;
desde una API;
desde un marketplace;
desde una importación;
o después de que las condiciones del cliente hayan cambiado.
Por eso conviene distinguir:
presentar una opción al usuario
de:
validar una operación empresarial.
La primera mejora la experiencia.
La segunda protege el proceso.
La personalización no debería convertirse en lógica duplicada
Aquí aparece el mismo riesgo que en otras integraciones.
ERP:
Cliente A → Canal profesional
Ecommerce:
Cliente A → Grupo B2B
Middleware:
Cliente A → Regla 7
CRM:
Cliente A → Distribuidor
Cuatro representaciones de la misma realidad.
Cuando el cliente cambia, ¿cuántas tenemos que actualizar?
Una buena integración debería intentar conservar una autoridad clara y derivar las vistas necesarias, en lugar de mantener manualmente varias copias de la misma decisión.
El catálogo empieza a parecerse otra vez a un grafo
Tenemos:
Cliente
→ pertenece a → Grupo
→ tiene → Condiciones
→ puede acceder a → Catálogo
→ contiene → Producto
Y quizá:
Cliente
→ tiene → Autorización
→ habilita → Producto
El catálogo que ve una persona es una vista de esas relaciones.
Esto conecta con algo que ocurre también en los catálogos técnicos: cuando aumentan las relaciones, pensar únicamente en tablas y campos empieza a ocultar parte del problema.
No estamos moviendo fichas.
Estamos conservando significado y contexto.
Antes de sincronizar clientes y catálogo, responde estas preguntas
¿Cómo identificamos al cliente?
Código ERP, NIF/CIF, email, ID externo…
¿Qué clasificaciones utiliza realmente la empresa?
Canal, tarifa, grupo, tipo, territorio…
¿Qué determina la visibilidad?
Producto, familia, marca, categoría…
¿Qué determina el permiso de compra?
Perfil, autorización, contrato, territorio…
¿Qué determina el precio?
Tarifa, cliente, cantidad, condiciones…
¿Cuál es la política por defecto?
¿Permitimos salvo excepción o restringimos salvo autorización?
¿Dónde se mantiene cada decisión?
ERP, ecommerce, CRM u otro sistema.
Solo después tiene sentido decidir cómo sincronizarlo.
No todos tus clientes tienen que ver la misma tienda
Solemos pensar en personalización ecommerce como:
recomendaciones;
productos relacionados;
orden de resultados;
campañas.
Pero en B2B puede existir una personalización mucho más estructural.
El propio catálogo.
Dos clientes pueden entrar en la misma URL, utilizar el mismo buscador y trabajar sobre el mismo ecommerce.
Y estar viendo dos ofertas diferentes.
No porque tengamos dos tiendas.
Sino porque la tienda entiende quién está comprando.
En Distillsync representamos cliente, producto, precio y las decisiones que relacionan esas entidades antes de traducirlas al modelo específico de cada aplicación.
Pero el principio es más general:
un catálogo no tiene por qué ser una lista de productos.
Puede ser una respuesta a una pregunta:
Para este cliente, en este contexto, ¿qué tiene sentido ofrecer?
