Copiar la ficha de la tienda B2C y esconder el precio detrás de un login no es un canal B2B. El comprador no está eligiendo un color. Está comprobando si el SKU encaja en su tarifa, si llega al mínimo de pedido y si puede mandar esa página a operaciones sin una llamada.
Las fichas producto B2B fallan cuando tratan al cliente como un consumidor con más unidades. Quien decide el pedido a menudo no usa el producto. Quien lo usa no ve el precio. Y el que sí se ve no es el mismo para un distribuidor, un contrato o un prospecto sin cuenta.
Este artículo va a lo que la ficha tiene que resolver en B2B: precios por rol, mínimos y un flujo de compra que no es “añadir al carrito”. El trabajo es de diseño UX/UI, no de un plugin de “wholesale” puesto encima de un tema.
Por qué las fichas producto B2B no son un recorte del B2C
En B2C la ficha cierra una decisión individual: me fío, me vale, lo añado. En B2B la ficha es un documento de trabajo. Se abre en una pestaña, se manda por email, se pega en un Excel interno y vuelve tres días después con un “¿este es el de 24 unidades o el de 48?”. Si la página no aguanta ese uso, no tienes un canal: tienes un catálogo bonito que obliga a llamar.
En Truman hemos diseñado fichas de catálogo en tiendas como Ceylan y Base85. Ahí el comprador decide en la página: foto, variante, precio, plazo. El oficio de la ficha —jerarquía, dato, no teatro— es el mismo. Lo que cambia en B2B es quién mira, con qué permiso y qué tiene que poder hacer sin un comercial al teléfono.
Tres diferencias que no se resuelven con un “modo mayorista”: el precio es una función del rol; la unidad de venta no es la de uso; el siguiente paso rara vez es un checkout de tarjeta. Si la ficha asume las tres del B2C, el profesional pide la tarifa en PDF. Encima, B2B añade política comercial —el mismo oficio que en ecommerce B2B y en las fichas de producto de consumo, con reglas que la plantilla no trae.
Precios por rol: qué se ve, qué se esconde y qué se calcula
Un precio B2B no es un campo. Es una regla. Cliente con tarifa A, cliente con contrato anual, distribuidor, empleado, prospecto sin cuenta. Si enseñas el mismo número a todos, o estás regalando margen o estás mintiendo a alguien. Si no enseñas ninguno hasta el login, el que no tiene cuenta no puede ni preparar una comparativa.
Tres estados, no uno. Visitante: rango, “pide tarifa” o ficha técnica sin PVP. Logueado sin precio: un CTA de “solicitar condiciones”. Con rol y tarifa: el neto, la unidad y el IVA según facturéis. Mezclarlos en una plantilla es el origen del ticket “el cliente ve el precio de otro”.
| Qué muestra la ficha | Visitante | Cliente con tarifa |
|---|---|---|
| Precio neto | Oculto o PVP | El suyo, por unidad |
| Mínimo de pedido | Regla general, si existe | El de su contrato |
| Stock / plazo | Orientativo | El que puede servirle |
| Añadir al pedido | Bloqueado o “solicitar” | Con validación del mínimo |
| Descarga de ficha / PDF | Sí, sin precio o con rango | Sí, con su tarifa |
| Historial / repetir pedido | No aplica | En la ficha o la cuenta |
Un error habitual: calcular el precio solo en el carrito. La ficha muestra 12,40 € y al añadir salta a 11,10 € por tramo. El comprador no se fía del número. El precio de la ficha tiene que ser el de la cantidad que está eligiendo, actualizado al cambiar unidades, con el tramo visible (“a partir de 48 uds.”). Si el cálculo vive solo en backend y la UI miente, el comercial acaba mandando un Excel. Habéis construido un catálogo, no un canal.
Si un cliente con tarifa y un visitante abren la misma URL, ¿la página miente a uno de los dos? Si la respuesta es sí, el problema no es el copy. Es el modelo de roles.
Mínimos de pedido: en la ficha, no en el pago
El mínimo de pedido es una regla comercial, no un error de checkout. Puede ser por importe, por unidades, por familia o por almacén. Si el comprador lo descubre cuando ya ha montado el pedido, la ficha ha fallado en su único trabajo: decirle si puede comprar esto, ahora, en estas condiciones.
En la ficha tiene que verse: el mínimo que aplica a ese SKU o a esa familia, el progreso si ya hay líneas en el pedido (“te faltan 80 € en esta gama”), y qué pasa si no llega (no se puede añadir / se añade como borrador / se solicita excepción). Las tres salidas son válidas. Lo que no es válido es el silencio hasta el último paso. Eso es la misma fricción de checkout del B2C, peor: el pedido B2B tiene más líneas y más gente esperando.
Otro detalle que las plantillas ignoran: la unidad de venta no es la unidad de uso. Vendéis cajas de 12, el cliente piensa en unidades sueltas. Si el selector dice “cantidad: 2” y no aclara si son 2 cajas o 2 piezas, el pedido llega mal y la incidencia no es de almacén. Es de ficha. Escribe la unidad al lado del precio, en el selector y en el resumen. Tres veces. No es redundancia. Es el idioma del pedido.
El comprador no es quien usa el producto
En muchos B2B hay tres personas y una sola ficha. El técnico sabe qué referencia necesita. Compras sabe si entra en presupuesto y si el proveedor está homologado. Dirección firma si el importe lo pide. Si la ficha solo habla al técnico (“nuevo compuesto, mejor rendimiento”), compras no tiene con qué decidir. Si solo habla a compras (“mejor precio del mercado”), el técnico no puede validar que es el SKU correcto.
La ficha B2B tiene que separar capas. Arriba, identificadores: referencia, equivalente, homologación, ficha técnica descargable. Al lado, condiciones: precio de su rol, unidad, mínimo, plazo. Abajo, el argumento de uso: para qué sirve, compatibilidad, limitaciones. El lifestyle y el claim de marca, si hacen falta, no pueden tapar la referencia. En B2B “no encuentro el código” es abandono. No es un problema de inspiración.
Si hay cuentas que piden cada mes, la ficha no puede comportarse como si cada visita fuera la primera. El historial es parte del producto, no un extra de “mi cuenta” escondido en un menú.
Login, lista de pedido y el botón que no dice “comprar”
En B2B el CTA de la ficha a menudo no es comprar. Es añadir a un pedido que alguien más aprobará, solicitar una oferta, o guardar para más tarde. Si el botón dice “comprar ahora” y el flujo real es una orden con referencia interna, albarán y fecha de entrega, estás usando el vocabulario del B2C sobre un proceso que no lo es.
El login: pedirlo para la ficha técnica es hostil; para el precio de contrato, razonable si hay otra salida. Pedirlo a mitad del selector pierde el contexto. “No logueado” es un diseño, no un muro.
Tip técnico: el precio no puede ser solo CSS
Ocultar el PVP con display:none no es una política: HTML, schema y caché siguen sirviendo el número. El precio se resuelve en servidor según el rol, o no se pinta. Si cacheáis la ficha, la clave incluye rol y tarifa. Si no, no cacheéis el bloque de precio: mezclar cliente A con B es un incidente comercial.
La ficha B2B no es una PDP con el precio tapado. Es una herramienta de trabajo para alguien que no tiene por qué ser quien usa el producto. Si no puede ver su tarifa, su mínimo y su referencia, va a pedir un Excel. Y el Excel gana a la web.
Qué hay que cerrar antes de pintar la ficha
Antes de Figma: roles, qué ve cada uno, unidad de venta, dónde vive el mínimo y qué CTAs existen de verdad. Si eso no está escrito, el diseño inventa un B2C con login. En València lo vemos cada trimestre: la empresa ya vende por teléfono y quiere “pasar el catálogo a la web”. Hasta que la política comercial esté en reglas —no en la cabeza del comercial—, la ficha no puede ser honesta.
Antes de dar por buena una ficha B2B, verifica esto
- ¿El precio de la ficha es el del rol que está mirando, no un PVP genérico?
- ¿El visitante sin cuenta tiene una salida útil (rango, solicitud, ficha técnica)?
- ¿El mínimo de pedido se ve antes de construir el pedido, no en el pago?
- ¿La unidad de venta está escrita junto al precio y en el selector?
- ¿La referencia se puede copiar y hay PDF descargable?
- ¿El CTA dice el paso real (añadir a pedido, solicitar oferta), no “comprar ahora”?
- ¿Un cliente recurrente puede repetir la última cantidad desde la ficha?
- ¿La caché del bloque de precio incluye rol y tarifa, o no se cachea?
Preguntas frecuentes sobre fichas producto B2B
¿En qué se diferencia una ficha B2B de una ficha B2C?
En B2C la ficha cierra una compra individual. En B2B es un documento de trabajo: precio según rol, unidad de venta, mínimo, referencia y un siguiente paso que a menudo no es pagar con tarjeta. Recortar la ficha de consumo y tapar el precio no convierte el canal en B2B.
¿Hay que esconder el precio hasta que el cliente inicie sesión?
Depende de vuestra política, no de la plantilla. Esconderlo todo empuja al prospecto al teléfono. Mostrar el PVP puede romper al profesional. Lo habitual es un estado para visitante (rango o solicitud) y el neto solo para quien tiene tarifa. Las dos cosas se diseñan. No se improvisan.
¿Dónde se muestra el mínimo de pedido?
En la ficha, junto al precio y al selector, y de nuevo en el pedido si el mínimo es por importe o por familia. Descubrirlo en el checkout es hostil: el comprador B2B ha invertido tiempo en líneas. Ese tiempo no se recupera con un mensaje de error.
¿Qué roles hay que prever en una ficha B2B?
Como mínimo: visitante, cliente con tarifa y un rol interno (comercial o admin) que pueda ver o suplantar condiciones. A partir de ahí, distribuidor, contrato y “sin precio asignado” suelen aparecer. Si no modeláis esos estados, la ficha va a mentir a alguien.
