La situación
Latino Tax Pro vende educación de impuestos, y vende mucha de ella a través de otras personas. Decenas de negocios independientes manejan su propia tienda WooCommerce con marca compartida, con el mismo catálogo de unos treinta cursos, bajo su propio nombre y su propio dominio.
La ley de impuestos cambia cada año. O sea que cada descripción, cada precio y cada título tiene que cambiar cada año, en cada tienda.
Cómo funcionaba antes: entrar a una tienda, buscar un producto, abrirlo, editarlo, guardar, repetir unas treinta veces, y luego entrar a la siguiente tienda y empezar otra vez. En toda la red eso son más de mil ediciones manuales por ciclo de actualización. Se llevaba días. Y nadie podía prometer que la tienda número treinta dijera lo mismo que la primera, porque a ese volumen la consistencia deja de ser cuestión de disciplina y se vuelve cuestión de aritmética.
El lado de los reportes estaba peor. Cada socio gana un rebate sobre lo que vende, lo cual significa que alguien tiene que cuadrar las órdenes de decenas de tiendas separadas para saber cuánto se le debe a cada quien y cuánto se queda realmente el programa. A esa escala eso no es trabajo de hoja de cálculo. Era adivinar.
Lo que construimos
Co-Brand Hub, una sola aplicación que es dueña del catálogo y trata a las tiendas como copias.
La dirección de la autoridad es todo el diseño. Los productos se editan en un solo lugar y se empujan hacia afuera. Las órdenes entran hacia adentro. El hub es la fuente de verdad y las tiendas van río abajo, y eso es lo que hace que una actualización de un clic se pueda correr sin miedo contra decenas de tiendas en vivo al mismo tiempo.
Control del catálogo
- Un catálogo maestro en el hub. Un push actualiza nombre, descripción, precio, estado e imágenes en cada tienda conectada usando la API REST de WooCommerce
- El costo de mayoreo queda fuera del push a propósito. Es el número sobre el que corre el cálculo de margen y nunca sale del hub
- Precios de venta personalizados por tienda, protegidos por defecto. Al socio que ya puso su propio precio no se lo pisa una actualización general, y cuando sí se empuja precio, sale el precio de la tienda, nunca el maestro encima de él
- Detección de desviación, para que el hub pueda decirte qué hay realmente en cada tienda contra lo que él cree que mandó
Sincronización de órdenes y el dinero
- Las órdenes completadas entran desde cada tienda y alimentan un solo libro financiero
- Rebate por línea, ganancias, contabilidad de costos por tienda entre cuota web, plataforma y dominio, y utilidad como porcentaje de lo que realmente se pagó por producto, no del ingreso bruto con impuesto y envío revueltos adentro
- Estados de rebate en PDF, un reporte financiero que se filtra y se ordena con exportación a CSV, gráficas de ingreso por nivel y resúmenes por representante
- Las líneas sin mapear se muestran como un número de primer nivel y no como una falla silenciosa, porque una línea que nadie puede costear es justo lo que hace que cada cifra de margen quede mal sin avisar
El resto del panel
- Niveles de tienda como tablero que se arrastra, donde el nivel define los supuestos de costo en los reportes
- Un panel de preparación que condiciona los reportes financieros a que los datos existan de verdad: registro de tiendas, catálogo maestro, mapeo de productos, libro de órdenes
- Una lista de siguientes acciones ordenada por impacto financiero, para que quien abre el hub reciba qué hacer en vez de que le pregunten qué quiere
El copiloto con IA
Un asistente que lee la red y actúa sobre ella conversando. Qué tiendas no tienen cierto curso. Subir un producto a un precio nuevo en todas menos en una. Corre sobre el AI SDK de Vercel con AI Gateway hacia Claude de Anthropic, y está construido contra una interfaz de cliente y no contra un backend específico, para que la capa de herramientas sobreviva si el hub se vuelve a implementar por debajo.
Una regla no se negocia: leer es libre, escribir se aprueba. Consultar catálogo, órdenes, desviación y finanzas no necesita permiso. Cualquier cosa que cambie una tienda en vivo se propone como un cambio concreto y espera a que una persona lo apruebe. El borrado por lote de WooCommerce es permanente, no hay papelera de dónde recuperarlo, y un producto borrado deja huérfano el registro con el que se cuadra el historial de rebates. Un agente con permiso de escribir sin confirmación sobre toda una red de tiendas en vivo no vale la pena construirlo.
Cómo funciona hoy
La actualización anual por cambios en la ley deja de ser una semana entrando a tiendas y se vuelve una edición y un push. El rebate y el margen por socio son un reporte y ya no un estimado. Dar de alta una tienda nueva es un proceso y no un proyecto.
Y la parte que no sale en una lista de funciones: el catálogo es consistente en toda la red porque la arquitectura lo hace consistente, no porque alguien tuvo cuidado treinta veces seguidas.