Precios por cliente en WooCommerce: cómo armar listas mayoristas sin romper el checkout

En B2B no existe "el precio". Existe el precio que ve el supermercado regional, el que ve la cadena de farmacias con convenio anual y el que ve el taller que recién abrió cuenta. El mismo SKU, la misma bodega, tres números distintos. Un e-commerce mayorista que muestra un solo precio público está modelando mal el negocio: o regala margen o espanta clientes grandes que ya tenían condiciones negociadas por fuera. El trabajo no es "poner precios", es reproducir en el checkout la estructura de precios que ya vive en tu ERP y en los acuerdos de tus vendedores.

Por qué un precio público no alcanza

El precio en B2B es una variable de la relación comercial, no del producto. Depende del volumen comprometido, del plazo de pago, del rubro del cliente y de cuánto pelea el vendedor. Esa lógica ya existe en tu operación: está en el ERP, en planillas o en la cabeza del jefe de ventas. El e-commerce no la inventa, la tiene que respetar. Cuando un cliente con 12% de descuento entra a la tienda y ve el precio de lista, no piensa "qué moderno": levanta el teléfono y pregunta por qué le están cobrando de más. Cada incoherencia entre la tienda y la cotización que le mandó su vendedor es una venta que vuelve al canal manual.

Las cuatro formas de implementarlo en WooCommerce

1. Precios por rol de usuario

El enfoque más simple. Creas roles (mayorista, distribuidor, convenio) y a cada uno le asignas una lista o un porcentaje de descuento sobre el precio base. Sirve cuando tus clientes caben en tres o cuatro segmentos limpios y dentro de cada segmento el precio es homogéneo. Es liviano, predecible y fácil de cachear. Se queda corto apenas un cliente del mismo segmento negocia condiciones propias: ahí el rol deja de describir la realidad y empiezan los parches.

2. Plugins B2B (B2BKing, Wholesale Suite)

Resuelven gran parte del flujo: grupos de clientes, reglas de precio por cantidad, ocultar precios a invitados, registro con aprobación. Son un buen punto de partida. El problema en Chile no es la funcionalidad, es la localización. Esperan que el precio se administre dentro de WooCommerce, y tu fuente de verdad es el ERP. Asumen un modelo de impuestos donde el IVA se calcula sobre un neto; nuestros catálogos suelen exhibir precio con IVA incluido, y ahí las reglas de descuento por porcentaje empiezan a arrojar diferencias de pesos por redondeo. Tampoco hablan con Bsale, Defontana ni Softland: la sincronización de precios queda como tarea tuya, y el plugin solo decide cuál de los precios que ya cargaste mostrar.

3. Precios por cliente individual

El modelo que el B2B realmente necesita: cada cliente tiene su propia tabla de precios, SKU por SKU. Es lo más fiel a la operación mayorista y lo más caro de mantener a mano. Con 30 clientes y 500 productos ya son 15.000 precios que alguien tendría que actualizar cada vez que cambia un costo. Hacerlo dentro de WooCommerce, como metadatos por usuario, es insostenible: la tabla de postmeta se infla, las consultas se vuelven pesadas y la administración es un infierno. Este enfoque solo funciona si los precios no se editan en WooCommerce.

4. El ERP como fuente de verdad

Aquí los precios por cliente no se guardan ni se editan en la tienda: se calculan en el ERP —donde ya viven las listas, los convenios y los márgenes— y se sincronizan hacia WooCommerce. La tienda deja de ser un segundo lugar donde mantener precios y pasa a ser una proyección de lo que el ERP ya decidió. Es más trabajo de integración al inicio y muchísimo menos mantención después. Cada vez que ventas ajusta una lista en Defontana, la tienda queda coherente sin que nadie toque WordPress.

Dónde se rompe cada enfoque en producción

En la demo, con 20 productos y dos clientes, todos los enfoques funcionan. La diferencia aparece con el catálogo real, los clientes reales y la caché encendida.

Rendimiento con catálogos grandes. Calcular el precio de cada producto por cliente en cada carga de página es caro. Si el precio se resuelve con una consulta a postmeta por SKU, una categoría con 200 productos dispara cientos de consultas. Con miles de SKU, el listado se arrastra. La salida es precalcular: el precio del cliente ya resuelto y guardado, no computado al vuelo.

Caché por rol. El page cache es lo que hace volar a WooCommerce, y los precios por cliente lo rompen de raíz: no puedes servir la misma página HTML a dos clientes que ven precios distintos. Si cacheas, un cliente termina viendo el precio de otro —un error grave en B2B—. Si no cacheas, el sitio se cae bajo carga. La respuesta intermedia es segmentar la caché por rol o grupo, no por usuario: cacheas una variante por segmento y los precios individuales se inyectan después, fuera del HTML cacheado.

Impuestos e IVA. Si manejas listas con IVA incluido y aplicas descuentos por porcentaje, el redondeo genera diferencias de pesos entre lo que muestra la tienda y lo que factura el ERP. Define desde el principio si el precio sincronizado es neto o con IVA, y que el cálculo de impuesto de WooCommerce coincida exactamente con el del ERP. Si no, cada pedido es una discusión de un peso.

Mostrar u ocultar precios a invitados. Muchos mayoristas no quieren exhibir precios al público —ni a la competencia—. Ocultar precios y el botón de compra hasta que el cliente inicie sesión es razonable, pero choca con el SEO y con la caché: la página pública y la del cliente logueado son distintas, y hay que decidir qué indexa Google y qué se sirve desde caché.

Conflictos con el carrito. El precio correcto debe sobrevivir todo el flujo: carrito, cupones, envío, checkout y, sobre todo, la creación del pedido. Si el precio por cliente se aplica con un hook tardío, un cupón mal configurado o un plugin de envío pueden recalcular sobre el precio de lista, y el cliente paga distinto a lo que vio. El precio del cliente tiene que aplicarse temprano y persistir como el precio real de la línea del pedido.

Comparación de enfoques

Enfoque	Cuándo sirve	Dónde se rompe
Precios por rol	Pocos segmentos limpios y homogéneos dentro de cada uno.	Cuando un cliente del mismo segmento negocia condiciones propias.
Plugin B2B	Necesitas el flujo B2B (grupos, ocultar precios, aprobación) ya armado.	Localización chilena: IVA, redondeo y cero integración con el ERP.
Precio por cliente individual	Cada cliente tiene su tabla y la fidelidad es innegociable.	Mantención a mano y rendimiento si los precios viven en WooCommerce.
ERP como fuente de verdad	Las listas ya existen en el ERP y cambian seguido.	Requiere integración seria al inicio; no es plug-and-play.

La recomendación

Para un mayorista con listas que cambian, el ERP es la fuente de verdad del precio y WooCommerce es la vitrina. No se edita el mismo dato en dos lugares. La integración sincroniza el precio por cliente —o por lista, según cómo el ERP modele el descuento— y lo deja precalculado en la tienda, listo para servir sin consultas pesadas en cada visita. La caché se segmenta por rol o grupo, no por usuario, para no devolver el precio de un cliente a otro y a la vez mantener el sitio rápido. El precio del cliente se aplica temprano en el flujo y se congela en la línea del pedido, de modo que cupones, envío y checkout operen sobre el número correcto. El IVA se define una vez —neto o incluido— y el cálculo de la tienda calza con el del ERP al peso.

No es la solución más rápida de instalar, y por eso muchas agencias venden el plugin B2B y dan por cerrado el tema. El plugin resuelve la pantalla; el ERP resuelve el negocio. La pregunta correcta antes de elegir no es qué plugin instalar, sino dónde vive el precio verdadero y cuántas manos lo tocan al día. Si esa respuesta es "el ERP, y cambia seguido", cualquier modelo que guarde precios dentro de WooCommerce es deuda que se paga después, en cada lista que alguien olvidó actualizar.