Panel sztabowy

Cuando gestionas una marca, un panel interno es sencillo: un equipo, un conjunto de clientes, un conjunto de reglas. Cuando hay dos marcas, y a la larga más, la cosa se complica. Lo más fácil es levantar un segundo panel junto al primero, pero entonces las mismas cuentas, los mismos monederos y las mismas reglas de comisión se mantienen por duplicado, y cada corrección tiene que aterrizar en dos sitios, o de lo contrario las versiones divergen.

El panel del personal es nuestra respuesta a esa tensión. Un único panel reúne a los clientes de VulCode y Aphrodi, atendidos desde una sola vista, pero con una frontera dura: una persona asignada a una marca no ve los clientes de la otra. A eso se suma lo que todo equipo de soporte acaba preguntando: quién cambió esta bandera en la cuenta, y cuándo. Este caso de estudio trata de cómo conciliamos un núcleo común con una separación que tiene que sostenerse de verdad, y no solo parecerlo.

Atender dos marcas desde dos paneles separados parece inocente hasta que cuentas cuánto se repite entre ellos. El modelo de cliente es el mismo. El monedero es el mismo. El programa de afiliados y las reglas de comisión son los mismos. Las facturas, las banderas en las cuentas, la lógica de permisos - todo igual, solo que en dos copias que alguien tiene que mantener sincronizadas a mano.

Eso no es solo trabajo doble, es una doble oportunidad de equivocarse. Una corrección de una regla de comisión aterriza en un panel y en el otro no, porque alguien se olvidó. Un nuevo campo en una cuenta de cliente aparece en una marca y falta en la otra. Cuanto más vive, más se alejan las dos copias, hasta que ya no se puede decir cuál es la correcta.

Así que decidimos que el núcleo es uno solo. Los clientes de ambas marcas viven en un único back office, sobre un único modelo de datos, atendidos por una única API. La diferencia la hace no un código separado, sino el alcance de permisos superpuesto al conjunto común.

El corazón de este panel es el control de acceso acotado por marca. El rol de un empleado no es global. Está ligado a una marca concreta, y el alcance de sus permisos termina exactamente en la frontera de esa marca. Alguien del equipo VulCode ve clientes VulCode y solo a ellos, aunque esos clientes estén físicamente en el mismo back office que los de Aphrodi.

Lo que importa es dónde se comprueba esa frontera. Si el acotamiento fuera solo un filtro en la interfaz, se podría esquivar añadiendo el id de otro a la dirección. Por eso la comprobación del alcance está a la entrada de la API y rechaza la petición antes de que toque los datos, sin importar lo que el frontend muestre u oculte.

En un panel donde se puede marcar una cuenta, cambiar un tipo de comisión o mover un saldo de monedero, la pregunta "quién lo hizo" cae inevitablemente. Sin respuesta solo queda adivinar a posteriori y buscar al culpable de memoria, lo cual es tanto injusto como inútil.

Por eso cada acción sensible se registra en un registro de auditoría: quién la ejecutó, a qué se refería y cuándo ocurrió. No es un registro técnico para los desarrolladores, sino un rastro legible para el equipo de soporte. Cuando surge una pregunta sobre un cambio en una cuenta, la respuesta está en el registro, y no en la cabeza de nadie.

El mismo mecanismo desempeña un segundo papel, más silencioso. La conciencia de que cada operación deja un rastro ordena el trabajo por sí sola. No se trata de sospecha; en un equipo que gestiona el dinero ajeno, la transparencia es una condición de la confianza, no un añadido.

Toda esta construcción se apoya en una única separación: qué es común y qué es separado. Común es el núcleo - la API, el modelo de datos, las cuentas y monederos de los clientes, y el registro de auditoría. Separado es solo el alcance de permisos y la visibilidad de clientes que se deriva de él. Nada más necesita ramificarse.

La consecuencia de esa división es práctica y duradera. Añadir otra marca al panel del personal es una configuración de alcance, y no otro panel que construir y mantener. Una nueva regla de comisión, un nuevo campo de cuenta, una nueva operación - todo eso aterriza una sola vez, en el núcleo común, y aplica en todas partes de golpe, solo que cada uno lo ve dentro de los límites de su marca.

El equipo trabaja desde un solo lugar, y no desde dos pestañas de navegador que tiene que llevar en la cabeza y vigilar para que no diverjan. Los clientes de ambas marcas están donde deben estar, cada empleado ve exactamente su parcela, y la frontera entre las marcas se sostiene a nivel de API, y no sobre la buena voluntad de la interfaz.

Cuando surge una pregunta sobre un cambio en una cuenta, la respuesta está en el registro de auditoría, y no en la memoria de alguien ni en conjeturas. Eso convierte las conversaciones de "quién lo hizo" de un conflicto en una simple verificación de un hecho, lo cual en un equipo que gestiona el dinero ajeno es la diferencia entre la confianza y una tensión constante.

Lo más importante, sin embargo, es que la arquitectura está lista para el futuro. Añadir una tercera marca no significa un tercer panel, solo un alcance más sobre el mismo núcleo. El desarrollo del back office no se multiplica por el número de marcas, porque lo que es común sigue siendo común y lo que es separado se limita a lo que de verdad debe serlo.