Plataforma B2B estándar o a medida

La elección de una plataforma B2B suele comenzar con una petición sencilla: que los clientes puedan hacer pedidos online. Después aparecen las condiciones que el equipo comercial maneja cada día: un cliente compra con una tarifa, otro pide presupuesto y un tercero necesita enviar a varias ubicaciones.

Muchas de esas reglas ya existen, aunque estén repartidas entre el sistema de gestión, los correos y la experiencia de las personas. El proyecto de ecommerce necesita hacerlas explícitas para que comprar online no obligue al cliente a llamar y resolver lo que la web no entiende.

No hace falta desarrollar todo desde cero. Hace falta comprobar qué parte cubre una plataforma, qué parte requiere configuración y qué parte necesita una adaptación real.

La plataforma B2B empieza por tus clientes

Un portal puede servir para repetir pedidos habituales, consultar un catálogo, solicitar una oferta o ampliar la relación con clientes nuevos. Esos objetivos no piden exactamente el mismo recorrido, aunque compartan productos.

Si tus clientes ya te compran por teléfono, observa qué información necesitan antes de confirmar. Puede ser la disponibilidad, una referencia compatible o la aplicación de sus condiciones. Trasladar ese contexto al canal digital suele tener más valor que añadir funciones que nadie utilizará.

El canal también debe encajar con el trabajo comercial. Decide qué puede hacer el cliente por sí mismo y en qué momentos interviene una persona. Una solicitud de presupuesto puede ser el final correcto del recorrido para ciertas operaciones. No todo tiene que terminar en un pago inmediato.

El ecommerce B2B funciona mejor cuando esa decisión está resuelta antes del diseño. Así puedes evaluar si el portal facilita el trabajo de ambas partes o añade una bandeja nueva que alguien tendrá que atender manualmente.

Las tarifas merecen una prueba propia

«Precios por cliente» puede significar varias cosas. Una tarifa asociada a una cuenta no es lo mismo que una combinación de descuentos, cantidades, acuerdos por familia y ofertas negociadas. Antes de contratar, documenta las reglas que realmente utilizas.

Después prueba un pedido representativo y una excepción. El objetivo es comprobar que el precio mostrado, el presupuesto y el pedido final mantienen la misma lógica. Si el cálculo depende de otro sistema, también hay que decidir qué sucede cuando ese sistema no está disponible.

No traslades al comprador una discrepancia que deba resolver internamente el proyecto. Si la web muestra un precio y el equipo corrige otro después, el canal puede resultar menos cómodo que el procedimiento anterior.

Algunas reglas pueden simplificarse por decisión comercial. Otras forman parte del acuerdo con el cliente y deben preservarse. Conviene que esa distinción la haga la empresa, con información sobre las consecuencias, y no que aparezca como una limitación inesperada al final del desarrollo.

Catálogo, disponibilidad y pedidos

Un catálogo útil necesita información que ayude a elegir: referencias, atributos, documentación e imágenes cuando correspondan. El primer trabajo puede ser ordenar esos datos y decidir quién los mantiene, incluso antes de cambiar la plataforma.

La disponibilidad requiere su propio criterio. Mostrar existencias exactas, una indicación orientativa o un plazo de consulta son compromisos distintos. Define qué puedes sostener con tus sistemas y con la frecuencia de actualización disponible.

En los pedidos, comprueba el recorrido completo: creación, recepción, confirmación y consulta posterior. Las modificaciones y cancelaciones también necesitan un tratamiento explícito, aunque inicialmente se gestionen con intervención comercial.

El ecommerce permite atender consultas y recibir solicitudes fuera del horario del equipo. Esa disponibilidad es útil, pero no equivale a prometer respuesta inmediata ni entrega automática. El texto del portal debe reflejar lo que la operación puede cumplir.

Qué puede aportar una plataforma existente

Una solución existente es una buena base cuando cubre el recorrido principal y las adaptaciones son acotadas. Puedes dedicar el esfuerzo a datos, implantación y experiencia de compra en lugar de reconstruir funciones comunes.

Pide que cada requisito se clasifique con claridad: disponible, configurable, cubierto por una extensión o pendiente de desarrollo. Esa distinción permite ver dónde se concentra el riesgo y quién mantendrá cada parte después.

También conviene comprobar las limitaciones del plan o de la arquitectura propuesta. Una función presente en una demostración puede depender de una contratación distinta o de una integración que no forma parte de la oferta.

La prueba debería hacerse con tus reglas y datos de muestra. Un catálogo genérico sirve para valorar la navegación, pero no demuestra que la plataforma gestione una excepción de tarifa o un pedido con el recorrido administrativo que necesitas.

SaaS, código abierto y desarrollo propio

En un servicio SaaS, parte de la operación técnica queda en manos del proveedor. Aun así, debes revisar contrato, exportación de datos, integraciones, límites y cambios de precio. La comodidad operativa tiene que evaluarse junto a esas condiciones.

En una solución de código abierto hay acceso al código según su licencia, pero alguien debe ocuparse del alojamiento, las actualizaciones y el soporte. No implica por sí misma perder el control de los datos ni garantiza que cualquier cambio sea sencillo.

El desarrollo a medida permite trabajar sobre las reglas específicas del negocio, con la responsabilidad de mantener lo construido. Puede partir de una base de comercio electrónico: la documentación de Django Oscar lo presenta como un framework extensible para desarrollar soluciones de ecommerce.

Estas opciones no siempre son excluyentes. Un desarrollo ecommerce puede combinar una base existente con módulos propios e integraciones. Lo relevante es que la propuesta explique la combinación y no esconda trabajo específico dentro de una etiqueta genérica.

Integrar con el ERP exige concretar el intercambio

Antes de hablar de un conector, identifica los datos que deben viajar: productos, clientes, precios, existencias o pedidos. Para cada uno, decide dónde se mantiene y en qué dirección se actualiza.

Después revisa cómo se detectan las incidencias. Si un pedido no llega al sistema de gestión, alguien debe poder localizarlo, entender el motivo y recuperarlo. Si se repite un envío, la solución debe evitar que aparezca como una segunda operación.

La integración también necesita acuerdos sobre frecuencia y responsabilidad. Una actualización periódica puede ser suficiente para cierto catálogo. Otro proceso puede exigir una respuesta distinta. No conviene prometer sincronización inmediata sin comprobar qué permiten ambos sistemas.

Que una plataforma pueda integrarse con un ERP no acredita un conector concreto. Pide el nombre y la versión del sistema, las operaciones cubiertas y una prueba del recorrido incluido en el proyecto. Esa información vale más que una lista larga de logotipos.

Lo que muestra Nou Grup

En Nou Grup, Mecexis desarrolló plataformas B2B para socios de un grupo de distribución de material eléctrico. El caso explica una combinación de catálogos individuales y compartidos, con una base construida sobre Django Oscar.

El ejemplo es útil porque la necesidad comercial incluye autonomía para cada socio y una parte común de catálogo. Ese equilibrio afecta al sistema y a la administración del contenido. No se resuelve únicamente cambiando la apariencia de una tienda.

El caso también describe capacidad de adaptación a ERP propios, pero no identifica una marca, versión y flujo concretos de integración. Por tanto, no debe utilizarse como prueba de que cualquier conector está disponible ni de que una implantación tendrá el mismo alcance.

El primer lanzamiento debe cerrar un recorrido

Un alcance inicial razonable permite que un grupo de clientes complete una tarea útil: consultar sus condiciones, preparar una solicitud o enviar un pedido que el equipo pueda tramitar. Eso aporta más información que abrir muchas funciones a la vez sin terminar ninguna conexión.

Acuerda cómo evaluarás esa primera fase. Además de las visitas, observa si los clientes completan el recorrido, dónde necesitan ayuda y cuánto trabajo manual genera la recepción de pedidos. No confundas actividad en la web con pedidos válidos o con ahorro comercial.

Incluye mantenimiento, formación y correcciones en la comparación económica. Si la propuesta necesita que alguien revise cada pedido fuera del sistema, ese trabajo forma parte del coste, aunque no aparezca en la cuota de la plataforma.

La mejor elección será la que permita sostener tus condiciones comerciales con claridad. Cuando el cliente puede operar y el equipo entiende lo que ha ocurrido, el canal empieza a formar parte del negocio en lugar de convertirse en otra pantalla que atender.