Commercetools es una plataforma de comercio electrónico headless basada en la nube y bien establecida. Los minoristas admiran su rendimiento, escalabilidad y alta disponibilidad, mientras que los desarrolladores disfrutan de funciones y API completamente documentadas, así como de un amplio apoyo de la comunidad de código abierto. Diseñada históricamente con un enfoque en las características B2C, esta poderosa plataforma MACH ha comenzado a obtener mucha tracción en el mundo B2B también.
1. Arquitectura
Commercetools hace todo lo posible para que su infraestructura e implementación de la tienda sea lo más ligera posible. Su típica implementación de Commercetools B2C podría ser tan simple como esto:
Ten en cuenta que todo el storefront puede ejecutarse como una aplicación del lado del cliente. Commercetools se encarga de la autenticación, la autorización y el alcance de los datos para cada llamada a la API. Una vez autenticado como cliente, el endpoint /me/* devolvería datos en el contexto del usuario actual solamente – mis pedidos, mis listas, mis carritos, mi perfil… Esto elimina la necesidad de cualquier capa entre el código del lado del cliente y la instancia de Commercetools.
Las cosas cambian cuando se trata de B2B, donde el cliente no es un usuario sino una organización. El endpoint /me/* sería inútil ya que los usuarios dentro de la misma organización de clientes compartirían el acceso a los carros, el historial de pedidos, las listas y otros datos de toda la organización. Lo que se necesita es una capa de acceso a datos adicional que implemente los endpoints /me/* de la organización y que tenga permisos elevados para acceder a los datos de Commercetools. Puede ser un middleware, un microservicio o incluso código del lado del servidor para tu aplicación web de tienda.
Veamos cómo se pueden implementar algunas de las funcionalidades B2B más importantes (clientes B2B, catálogos específicos de clientes y precios específicos de clientes) dentro de la plataforma Commercetools.
2. Clientes B2B
Como ya habrás adivinado, no hay soporte para clientes empresariales u organizaciones de clientes. La entidad Cliente existente está adaptada a los escenarios B2C, donde un cliente = usuario. Tampoco hay una forma rápida y directa de declarar una organización como cliente con múltiples cuentas de usuario y roles asociados. Hay bastantes opciones a considerar.
2.1 Enfoque de las tiendas
Puede sonar un poco contraintuitivo, pero piénsalo: ya existe un método fuera de la caja para agrupar las cuentas de los clientes, e incluso sus carritos. En muchos escenarios B2B tu no vas a utilizar las tiendas para tu propósito de todos modos, ya que no hay necesidad real de ubicaciones físicas de venta al por menor y / o tiendas de marca. Por lo tanto, para cada organización de clientes B2B se puede crear una nueva tienda y asignar a los usuarios de los clientes a ella utilizando el Merchant Center y las API. Incluso tienes la ventaja de clasificar automáticamente los pedidos por cliente para que los usuarios de tu empresa puedan ver rápidamente los pedidos por cliente B2B sin tener que escribir una sola línea de código. La mayor desventaja del enfoque de Tiendas es el límite de Commercetools de 100 (recientemente disminuido de 500) tiendas por proyecto (también conocido como instancia de Commercetools). Por lo tanto, si tu implementación es para manejar más de 100 organizaciones de clientes B2B, esta opción no va a funcionar.
2.2 Enfoque de canales
El Canal es otro tipo de entidad preexistente en Commercetools que puede ser utilizado para modelar organizaciones de clientes B2B. Mientras que no hay una manera de asociar directamente los usuarios de los clientes a los canales, es relativamente fácil de hacer añadiendo un tipo de referencia de Canal a la entidad Cliente. De hecho, se puede hacer a través del Merchant Center sin escribir ningún código. El beneficio real de este enfoque viene cuando tu necesitas tener disponibilidad de productos y precios específicos para clientes B2B, ya que Commercetools soporta tal funcionalidad para los canales fuera de la caja. El mayor problema con el enfoque de canales es, una vez más, el límite de 100 (recientemente disminuido de 500) canales por proyecto.
2.3 Enfoque de objetos personalizados
Commercetools permite la creación de datos arbitrarios con formato JSON que pueden ser almacenados dentro de la plataforma y recuperados usando las APIs de Commercetools. Los objetos personalizados pueden utilizarse para representar organizaciones, o incluso estructuras de organización que pueden ser referenciadas por los objetos estándar, como Cliente, Tienda, Producto, etc. Sin embargo, este tipo de flexibilidad tiene un coste: los desarrolladores serían responsables de implementar las aplicaciones personalizadas de Merchant Center para permitir a los usuarios de la empresa gestionar los objetos personalizados y sus relaciones. A diferencia de los tipos estándar de Commercetools, la integridad y consistencia de los datos de los objetos personalizados tendría que ser proporcionada por el middleware o los servicios personalizados. Por último, los objetos personalizados de Commercetools tienen una funcionalidad de consulta muy limitada, por lo que recuperar organizaciones por algo como el estado o la ciudad podría acabar siendo muy complejo.
2.4 Enfoque de sistema externo
Este enfoque es similar al de los objetos personalizados, pero los datos de la organización empresarial se almacenan y gestionan en un sistema externo. Éste puede ser tan simple como una simple base de datos o tan complejo como un CRM o un ERP. Aunque proporciona una capacidad de modelado y gestión de datos considerablemente mejor, este tipo de implementación no es barata, y empuja los límites de la solución de comercio electrónico mucho más allá de la plataforma Commercetools. El enfoque de Sistema Externo es ideal para las implementaciones B2B a gran escala.
3. Catálogos específicos para el cliente
La capacidad de proporcionar un conjunto diferente de productos a cada cliente empresarial es un requisito firme en casi todas las implementaciones de comercio electrónico B2B. Un proyecto Commercetools no tiene un concepto de catálogos múltiples, por lo que los desarrolladores tienen que ser un poco creativos aquí.
3.1 Enfoque por categorías
El uso de categorías es la forma más natural de simular múltiples catálogos dentro de uno solo. Sólo tienes que crear una categoría de nivel superior para cada cliente B2B y poner las categorías y productos relacionados debajo de ella. Por supuesto, tendrás que ser cuidadoso con la implementación de tus consultas para asegurarte de que cada cliente B2B se limita a tu categoría de nivel superior cuando consultes y busques productos. También hay un límite para el número total de categorías en un catálogo de Commercetools: 10,000. Esto significa que incluso si no tienes ninguna subcategoría en tu catálogo B2B, estarías limitado a 10K clientes B2B por proyecto. Este número se reduciría rápidamente si tu catálogo tiene subcategorías. Recuerda que, a diferencia de los productos, las categorías en el catálogo Commercetools sólo pueden tener una categoría principal, por lo que no puedes «reutilizar» la misma subcategoría bajo diferentes categorías de nivel superior. Si tu catálogo B2B tiene 99 categorías, estarías limitado a 10.000/(99 subcategorías + 1 categoría superior) = 100 clientes B2B con este enfoque.
3.2 Enfoque de canales
Modelar las organizaciones de clientes B2B contra los canales de suministro de Commercetools viene con la capacidad incorporada de asignar SKUs a clientes específicos. Incluso se obtiene una interfaz de usuario de gestión en Merchant Center (en la pestaña de Inventario de la pantalla de gestión de variantes de productos). Ahora la consulta de productos específicos del cliente se convierte en algo sencillo: sólo hay que recuperar los productos asignados a un canal específico. Por supuesto, este no es el uso previsto de los canales de suministro dentro de Commercetools, y el tope suave en el número de canales es una vez más un factor limitante. Sin embargo, si tu caso de uso particular no implica múltiples fuentes de inventario, y el número de clientes B2B es inferior a 100, esta podría ser la forma más rápida de obtener la funcionalidad B2B dentro de Commercetools.
3.3 Enfoque de sistema externo
A las implementaciones B2B grandes y escalables les convendría confiar en un sistema externo para mantener la asociación de disponibilidad de productos específicos del cliente. Un enfoque típico es una base de datos personalizada gestionada a través de una aplicación personalizada de Merchant Center, e indexada por un motor de búsqueda empresarial, que a su vez proporciona productos específicos del cliente a los escaparates. Esto puede parecer costoso de implementar, pero los beneficios son evidentes.
4. Precios específicos para el cliente
La fijación de precios específica para el cliente es otro requisito absoluto para casi todas las implementaciones B2B. Desafortunadamente, aquí es donde las capacidades actuales de Commercetools son muy limitadas.
4.1 Enfoque de canales
Dado que los precios de los productos en Commercetools pueden ser especificados por el canal de suministro, la asignación de dicho canal a cada cliente B2B elimina automáticamente la necesidad de implementar un nuevo sistema de precios, una API para exponerlo y una UI para gestionar las asignaciones de precios. Todo estaría resuelto excepto el límite blando de 100 canales (por tanto, 100 clientes B2B). Una opción viable para implementaciones B2B más pequeñas.
4.2 Enfoque de grupos de clientes
El grupo de clientes es otra forma de segmentar los precios de un producto en Commercetools. La creación de un grupo por cliente B2B proporciona beneficios similares al enfoque de Canales – UI de gestión, y API disponible para consultar. Un proyecto de Commercetools tiene un límite de 1000 grupos de clientes, y esto podría parecer una mejor alternativa que 100 canales. Sin embargo, una variante de producto en Commercetools tiene un límite suave de 100 precios asignados, por lo que 1000 grupos de clientes no supone realmente una gran diferencia, a menos que cada cliente B2B tenga acceso a una parte relativamente pequeña de todo el catálogo.
4.3 Enfoque del sistema externo
La mayoría de las soluciones Commercetools B2B tendrían que depender de implementaciones externas para la gestión de precios. La buena noticia es que muchos proveedores de servicios B2B ya disponen de un sistema de gestión de precios, ya sea un ERP o un software dedicado a la administración de precios. Sin embargo, no sólo hay que exponer adecuadamente la información de precios a los escaparates (a través de un motor de indexación y APIs personalizadas), sino que también hay que implementar extensiones de la API de Commercetools para las entidades de carros/pedidos/pagos con el fin de que Commercetools conozca los precios de productos externos que no pueden ser modelados o incluso almacenados dentro de sus propios modelos de datos.
…Y algo más
Hemos pasado por los obstáculos típicos en las implementaciones de Commercetools B2B. Por supuesto, dependiendo de las especificidades del negocio, podría haber más funcionalidades requeridas que no son actualmente nativas de Commercetools, tales como cotizaciones de productos, reservas, facturación, soporte para MTO (made to order) y ATP (available to promise), etc. Sin embargo, muchas plataformas de comercio electrónico B2B requerirían amplias personalizaciones para las características mencionadas de todos modos. Dicho esto, hay numerosos casos de uso B2B en los que Commercetools es una solución muy adecuada. Por eso, cerca del 30% de las implantaciones actuales de Commercetools están en el área B2B.
