Nomad X Collective

A mediados de 2025, nomadxcollective.com todavía funcionaba con un software de tienda estándar. Está construido para un comerciante: un almacén, una cuenta de envío, una persona que mantiene los precios. El negocio que había detrás hacía tiempo que era otro. Nomad X Collective cura marcas independientes que venden también su origen, cada una con su propio almacén, su propia cuenta de envío y su propia idea de lo que hay que contar sobre una prenda. Si se obliga a esas marcas a entrar en un sistema que solo conoce a un comerciante, al final alguien acaba tecleándolo todo y cada cambio se convierte en un correo electrónico.

Por eso el encargo fue: tres sistemas conectados que se sientan como una sola marca y que atiendan a tres grupos de usuarios con tareas muy distintas.

• Operación de la plataforma: pedidos, facturación y nuevas altas de un vistazo, sin que nadie tenga que construir una hoja de cálculo.
• Marcas asociadas: catálogo propio, página de marca propia, pasos de fulfillment propios, sin desarrolladores a demanda.
• Clientas y clientes: una compra que se percibe curada y no como una plantilla de marketplace.

A eso se sumó el momento. La plataforma debía lanzarse junto con un rebranding completo, así que la interfaz de cara al cliente tenía que llevar una nueva identidad visual mientras por debajo funcionaba un marketplace por primera vez.

Construimos la plataforma como tres sistemas conectados sobre una base de datos común y repartimos el esfuerzo de diseño de forma desigual. La tienda lleva el rebranding completo; el panel de administración y el panel de vendedor funcionan sobre una interfaz base más sobria y funcional. Es un orden, no un ahorro: primero tienen que funcionar los procesos que hay debajo, porque un panel de vendedor bonito con un estado de pedido equivocado no vale nada.

1. Datos compartidos, soberanía separada

• Los productos, las variantes, el stock, los pedidos y los datos de clientes residen en una base de datos que los tres sistemas consultan a través de la misma interfaz REST.
• La soberanía sobre los contenidos sigue separada. Las credenciales de acceso de las marcas se crean de forma centralizada para que el onboarding quede en un solo sitio; a partir de ahí, los datos de marca y de producto de una marca le pertenecen a ella.
• Todas las imágenes residen en un bucket de S3 en eu-central-1. Los logotipos de marca y las imágenes de las páginas de marca se guardan por separado para cada comerciante; las imágenes de producto están en un espacio de nombres común, porque dependen del producto y no de la marca.

2. La importación es el verdadero trabajo de traducción

Las marcas suelen llegar con una tienda existente, por ejemplo en Shopify o WordPress. Para eso, el panel de vendedor ofrece un botón que conecta la tienda externa. La importación ahorra el tecleo, pero no resuelve por sí sola el problema más difícil. Dos tiendas describen la misma prenda de forma distinta: las tallas se nombran de otra manera, los nombres de color son denominaciones internas y lo que una tienda lleva como dos productos, en la otra es una variante del mismo producto. En un marketplace con filtros comunes, de ahí tiene que salir un vocabulario; si no, el filtro de color se descompone en sinónimos y no encuentra nada. Hasta dónde llega una equiparación depende además de lo que cada plataforma externa entregue por su API. Se lo dijimos así al cliente, en lugar de prometer una sincronización completa.

3. La redacción como registro de datos

La página de inicio, la de quiénes somos, la de contacto, el pie de página, el programa de partners y los talleres son, cada uno, una configuración que la tienda carga en tiempo de ejecución; las páginas de marca son un registro estructurado propio. Así se pueden cambiar imágenes, textos y la visibilidad de secciones enteras sin que nadie despliegue.

Cada marca asociada envía desde su propia ubicación a través de su propia cuenta de envío. No existe, por tanto, un flujo de envíos común que la plataforma pudiera leer, ni forma alguna de consultar el estado de entrega desde el servidor.

Esto afecta a más que a la indicación de estado. Si el envío queda en manos de la marca, un pedido que abarca dos marcas se convierte forzosamente en dos envíos: dos paquetes, dos plazos, dos enlaces de seguimiento. Por eso el carrito muestra los gastos de envío por comerciante y solo después los suma. Por la misma razón modelamos la devolución y el reembolso como un flujo de trabajo propio. Un reembolso toca a la vez el stock, el pago al comerciante y la comunicación con el cliente, y por regla general afecta a una parte del pedido, no a todo él.

El proceso está, en consecuencia, construido en torno a la relación de envío real:

1. La marca pone su parte del pedido en “enviado” y deposita al hacerlo el enlace de seguimiento que ha generado su propia cuenta.
2. Exactamente ese enlace sale automáticamente por correo electrónico.
3. La marca confirma manualmente “entregado” en cuanto lo ve en su lado.

Un estado de entrega automático sería, en este punto, solo una suposición, y una promesa adivinada es peor que una información honesta. Por eso la tienda dice exactamente lo que el sistema sabe, y lo dice donde surge la pregunta. En la sección de envío de la página de producto se lee “Each shipment is managed directly by our brand partners; therefore, costs and delivery times vary based on your location.”, y más abajo, en la misma sección, “Once your order has been dispatched, you will receive a tracking link via email.”

La tienda es la superficie en la que la historia de una marca se convierte en una compra. La página de inicio tiene una estructura fija de hero en vídeo, “Latest Arrivals” y “Meet Our Brands”, cuyos contenidos se fijan editorialmente. Estructura fija, contenidos libres: maquetación sin descontrol, redacción sin despliegue.

1. Catálogo

• Filtros por categoría, marca y color, ordenación por novedad y precio, navegación por páginas con 16 artículos por página.
• Las tallas y las variantes de color ya están en la tarjeta, igual que la lista de deseos y el carrito. Quien ya sabe qué talla y qué color quiere no necesita abrir la página de producto.
• El carrito y la lista de deseos funcionan sin cuenta mediante un identificador de invitado en el servidor. El inicio de sesión es posible con contraseña, código de un solo uso o Google.

2. Página de producto

La página de producto está estratificada. Bajo la imagen, la talla y el precio hay secciones desplegables, y cuáles son las decide la marca a través de sus propios contenidos. Un pantalón mongol de yak lleva una sección de transparencia propia con el lugar de producción; una prenda de punto fabricada en Italia reúne composición, origen y cuidado en una sola sección y menciona allí su certificación. Debajo aparece la marca con su nombre, su historia y un enlace a su propia página.

3. Páginas de marca

Cada marca asociada recibe una página propia con la misma estructura: la historia de la marca, los bloques Material Traceability, Production Process, Origins & Resources y Maintenance & Repair, y sus propios productos al pie. El origen se convierte así en una estructura dentro del sistema que cada marca rellena por sí misma. Las marcas asociadas la rellenan con contenidos muy distintos, desde un fabricante mongol fundado en 1991 hasta una colección de punto confeccionada en Italia.

El panel de vendedor da a cada marca asociada un espacio de trabajo propio con cinco áreas: Dashboard, página de marca, gestión de productos, gestión de pedidos y ajustes. Una marca debe poder cambiar una descripción o marcar un pedido como enviado sin ocupar para ello a nadie del equipo de la plataforma.

1. El producto es un envoltorio, la variante es la mercancía

Un producto lleva título, descripción y una variante base; lo que se vende es siempre una variante con SKU propio, atributos propios de talla y color y precio propio. Por eso una marca puede poner un color más caro que otro y dejar variantes concretas en “sin stock” mientras el producto sigue activo.

El stock no figura ahí como una cifra, sino como tres: la cantidad, la parte reservada de esa cantidad y, derivada de ambas, la disponible. Esa separación es la diferencia entre un marketplace que vende dos veces la misma última pieza y uno que no lo hace.

2. Dos decisiones marcan el diseño

• El onboarding es un estado, no un formulario. El progreso se guarda paso a paso, así que una marca puede interrumpir la configuración y continuarla más tarde. El precio de ello es que pueden existir marcas a medio terminar: tienen que estar presentes en el sistema sin aparecer en el catálogo.
• El paso de envío exige una entrada. El enlace de seguimiento es la única información del ciclo de pedido que la plataforma no tiene por sí misma y, por eso, el único punto dentro de él en el que el panel exige algo antes de continuar.

Para fabricantes pequeños que trabajan de forma muy consciente, eso decide si es posible crecer sin dirigir de paso una empresa de logística.

Un marketplace solo sigue siendo curado si alguien lo revisa. Al mismo tiempo, esa revisión no puede significar que una marca escriba un correo electrónico por cada pie de foto. Lo separamos: la marca escribe por sí misma, pero no publica por sí misma.

Para ello, la página de marca se crea en el panel como una configuración de seis secciones, cada una editable por separado: hero, descripción, cuadrícula de información, galería, cuidado e identidad de marca. El hero admite a elección una imagen o un vídeo, y el texto alternativo figura al lado como campo propio en lugar de como añadido posterior, porque de otro modo no llega a existir nunca.

Al final no hay un “Guardar”, sino Submit For Approval. Con ello existen dos versiones en paralelo: aquella en la que la marca está trabajando y la última aprobada, que se entrega a la tienda. El panel dice ambas cosas en el mismo sitio, a saber, que la página está en vivo y qué versión es esa. Los productos pasan por el mismo mecanismo, por eso en la lista de productos, junto al título y las variantes, figura siempre también un estado de aprobación.

El efecto es que una errata en una página de marca no cuesta nada y, aun así, una presencia no acordada no llega a estar en vivo. El precio es una cola que alguien tiene que atender, y justo por eso la aprobación se limita a la página de marca y al catálogo de productos y no se extiende a cada cambio de stock.

Ambos paneles están construidos en torno a los mismos indicadores: pedidos, facturación, pedidos actuales y pedidos abiertos. Empezamos por el Dashboard, porque antes la pregunta por los pedidos y la facturación costaba una exportación y una tabla dinámica.

Debajo está el objeto propiamente dicho, el ciclo de pedido. Conoce seis estados, y la distribución entre ellos es el primer gráfico que ve una marca tras iniciar sesión:

• Pending, Packed, Shipped, Delivered como el camino normal. “Packed” está a propósito entre la entrada y el envío, porque en mercancía hecha a mano pueden pasar días entre ambos y, si no, una clienta no se entera de que esté ocurriendo nada.
• Cancelled y Refunded como las dos salidas. No son casos de error, sino estados finales con consecuencias propias para el stock y para el pago.

Junto a ello están las tareas que pertenecen solo a la plataforma: gestión de usuarios y de comerciantes con bloqueo y desbloqueo, historial de pedidos y exportación en CSV para la contabilidad, el ciclo completo incluidas devoluciones y reembolsos, así como la emisión de las credenciales de acceso para nuevas marcas asociadas.

Los correos transaccionales pasan por Brevo, para que la confirmación de envío, la devolución y la creación de cuenta tomen la misma vía de entrega y, en caso de duda, sigan siendo trazables. En un marketplace cuyos envíos llegan desde varias direcciones, el correo electrónico es el único canal que la plataforma controla por completo.