Venta en línea B2B: precios por cliente sobre un catálogo de 12,000 referencias
Resumen:
- Las tarifas por cliente y las aprobaciones internas son lo que separa el B2B del comercio al público.
- El comprador profesional busca por código, no por nombre: el buscador debe estar hecho para eso.
- Mostrar el stock real reduce llamadas aunque parezca contraintuitivo.
- El portal no sustituye al comercial: le quita el trabajo rutinario.
Un distribuidor de material eléctrico con doce mil referencias activas y trescientos clientes profesionales quería dejar de recibir pedidos por teléfono y por correo. No por modernidad: porque dos personas se pasaban la jornada transcribiendo pedidos y cada transcripción era una oportunidad de error.
Los dos problemas que el comercio al público no tiene
Cada cliente ve un precio distinto
No había una tarifa con descuentos: había trescientas tarifas. Algunas negociadas por familia de producto, otras por volumen anual, algunas con condiciones heredadas de acuerdos antiguos que nadie recordaba haber firmado.
Publicar eso significa que el catálogo no es un catálogo: es una vista personalizada que se calcula para cada visitante autenticado. Un producto no tiene precio; tiene precio para ti.
Quien pide no siempre es quien autoriza
En las empresas clientes, el jefe de obra elige el material y administración aprueba el gasto. Un portal que solo contempla «usuario que compra» deja fuera a todos los clientes con control interno de gasto, que son justamente los más grandes.
Cómo se modeló el precio
| Nivel | Qué define |
|---|---|
| Tarifa base | El precio de catálogo. Existe siempre y es el punto de partida. |
| Tarifa de grupo | Condiciones por segmento de cliente. Evita replicar la misma regla trescientas veces. |
| Acuerdo particular | Excepciones negociadas con un cliente concreto, con vigencia y fecha de caducidad explícitas. |
| Promoción temporal | Campañas con fechas. Se resuelven al final y solo si mejoran el precio que ya tenía el cliente. |
La regla que evitó el caos: el orden de resolución es fijo y está documentado, y el sistema puede explicar por qué un cliente ve un precio concreto. Esa función de «explicar el precio» no estaba en el encargo y acabó siendo la más usada por el equipo comercial.
El buscador: para quien sabe lo que quiere
La primera versión tenía categorías, filtros y navegación por familias. Se usó poco.
Los compradores profesionales no navegan: escriben un código de fabricante y esperan encontrarlo. La segunda versión priorizó la búsqueda por referencia, con tolerancia a errores de formato, equivalencias entre fabricantes y acceso directo al historial de lo ya comprado.
Ese último punto fue el más valorado: la mayoría de los pedidos B2B son repeticiones. Poner «volver a pedir» a un clic desde el histórico convirtió el portal en algo útil desde el primer día, antes incluso de que aprendieran a buscar.
Preguntas frecuentes
¿Se puede montar un portal B2B sobre una plataforma de comercio al público?
Hasta cierto punto. Las tarifas por cliente y los pedidos con aprobación son las dos funciones que las plataformas generalistas resuelven peor, normalmente mediante extensiones que se vuelven frágiles cuando las reglas de precio son complejas.
¿Cómo se busca dentro de un catálogo de miles de referencias?
Por número de parte, por referencia del fabricante y por equivalencias, no por nombre comercial. El comprador profesional llega sabiendo qué quiere y escribe un código; un buscador pensado para navegar categorías le resulta inútil.
¿Conviene mostrar el stock real al cliente?
Sí, aunque asuste. El comprador profesional prefiere saber que no hay existencias a descubrirlo cuando no llega el pedido. Mostrar disponibilidad y fecha estimada reduce llamadas y aumenta la confianza.
¿Qué pasa con los clientes que siguen pidiendo por teléfono?
Que seguirán pidiendo por teléfono, y está bien. El portal no sustituye al comercial: absorbe los pedidos rutinarios y libera tiempo para las conversaciones que sí requieren una persona. Forzar la migración genera resistencia sin ganar nada.
¿Cómo se gestionan las aprobaciones internas del comprador?
Con roles dentro de la misma cuenta: quien prepara el pedido y quien lo autoriza. Sin eso, las empresas con control de gasto no pueden usar el portal y vuelven al correo electrónico.
Qué pasó con las dos personas que transcribían
No sobraron. Pasaron de teclear pedidos a resolver incidencias, buscar equivalencias para material descatalogado y atender a los clientes que llaman porque necesitan asesoramiento, no porque necesiten un formulario.
Es el resultado habitual de automatizar bien: no desaparece el trabajo, desaparece la parte del trabajo que no requería a una persona. Y en un distribuidor, donde el conocimiento del catálogo es el activo real, liberar ese conocimiento del teclado tiene más valor que el ahorro de horas.
El rendimiento con doce mil referencias
Un catálogo de ese tamaño con precios calculados por cliente plantea un problema técnico concreto: no se puede precalcular todo para todos.
La solución que funcionó fue calcular el precio solo de lo que se muestra —la página de resultados, no el catálogo entero— y guardar en memoria las reglas aplicables a cada cliente durante su sesión. Con eso, una búsqueda que devolvía cincuenta resultados hacía cincuenta cálculos, no doce mil.
| Decisión | Efecto |
|---|---|
| Calcular solo lo visible | El coste depende de lo que se muestra, no del tamaño del catálogo. |
| Reglas del cliente en memoria de sesión | Se resuelven una vez al entrar y no en cada consulta. |
| Búsqueda con índice propio | Consultar por código no puede depender de un recorrido de la tabla completa. |
| Histórico paginado | Un cliente con años de pedidos no debe cargar todo para ver los últimos diez. |
Ninguna de esas decisiones es sofisticada. Todas se toman al principio o se pagan después con un portal que tarda cuatro segundos en mostrar una búsqueda.
Lo que decidimos no construir
El encargo inicial incluía un configurador de producto, un módulo de presupuestos y un chat con el comercial asignado. Los tres se descartaron para la primera versión.
El motivo fue el mismo en los tres casos: eran funciones que suenan valiosas y de las que nadie podía decir cuántos clientes las usarían. En cambio, «repetir el último pedido» era algo que trescientos clientes hacían cada semana por teléfono.
Construir primero lo que ya ocurre a diario, y dejar para después lo que alguien imagina que ocurriría, es la regla que más proyectos ha salvado de nuestra lista. En este, permitió tener el portal en producción en la mitad del tiempo previsto y con la mayoría de los clientes usándolo desde el primer mes.