Portal B2B para un fabricante de descanso con más de un siglo de historia

Este proyecto también es anterior a Helix y también viene con acuerdo de confidencialidad. Podemos contar el perfil: un fabricante español de productos de descanso con más de un siglo de historia y una red de miles de puntos de venta. Lo que sigue es el sistema que la fundadora de Helix construyó para que esa red pidiera a fábrica sin llamadas ni hojas de cálculo.

El encargo: que la tienda pida por el cliente

Un B2B de fabricante funciona al revés de lo que esperarías de una tienda online: el usuario no es el cliente final, es la tienda. Y dentro de la tienda no todos pueden hacer lo mismo, así que el sistema se construyó sobre los roles reales del mostrador: el dependiente que atiende, el manager que aprueba y el superusuario que administra qué puede hacer cada uno.

La pieza central es la impersonación. Cuando un cliente entra en una tienda física y elige su producto, el dependiente lo busca en el portal, actúa en su nombre y le monta el pedido completo desde el mostrador. El cliente se va con su compra cerrada y la tienda con el pedido lanzado a fábrica. Eso obliga a resolver algo delicado: una misma sesión donde conviven dos identidades (quién opera y en nombre de quién) con permisos, precios y trazabilidad separados. Si eso falla, el pedido acaba facturado a quien no toca. Con eso no se juega.

Descuentos que dependen de quién, dónde y qué

La otra mitad del sistema era el precio. En B2B no existe "el precio": existe el precio de esa tienda, para ese cliente, en esa operación. Condiciones comerciales por punto de venta, descuentos personalizados por cliente final y reglas que se combinan entre sí sin que el dependiente haga cuentas. El portal las aplica y deja registro de por qué ese pedido salió a ese importe.

Con miles de puntos de venta encima, un motor de condiciones montado a base de excepciones parcheadas muere en meses. Tiene que ser un sistema de reglas que el equipo comercial del fabricante mantenga sin tocar código. Ahí se jugaba la adopción, y la red lo adoptó por una razón muy poco romántica: hacía el pedido mejor y más rápido que el canal de siempre.

Lo que nos llevamos a Helix

Dos lecciones que hoy aplicamos a cualquier proyecto. La primera: los permisos se diseñan sobre cómo trabaja la gente de verdad, con su mostrador y su trastienda, y no sobre un organigrama teórico. La segunda: cuando el software refleja el flujo real del negocio, la adopción ocurre sola. Es el mismo criterio que usamos cuando una empresa nos cuenta las señales de que necesita software a medida: casi nunca falla la herramienta que tienen, falla que su proceso ya no cabe en ella.