Panel sztabowy

Quando gestisci un marchio, un pannello interno è semplice: un team, un insieme di clienti, un insieme di regole. Quando i marchi sono due, e col tempo di più, la cosa si fa delicata. La cosa più facile è mettere un secondo pannello accanto al primo, ma allora gli stessi account, gli stessi portafogli e le stesse regole di commissione vengono mantenuti in doppio, e ogni correzione deve atterrare in due posti, altrimenti le versioni divergono.

Il pannello dello staff è la nostra risposta a questa tensione. Un unico dashboard riunisce i clienti di VulCode e Aphrodi, gestiti da un'unica vista, ma con un confine netto: una persona assegnata a un marchio non vede i clienti dell'altro. A questo si aggiunge ciò che ogni team di supporto prima o poi chiede: chi ha cambiato questo flag sull'account, e quando. Questo caso di studio racconta come abbiamo conciliato un nucleo comune con una separazione che deve reggere davvero, non solo sembrarlo.

Gestire due marchi da due pannelli separati sembra innocuo finché non conti quanto si ripete tra loro. Il modello cliente è lo stesso. Il portafoglio è lo stesso. Il programma di affiliazione e le regole di commissione sono gli stessi. Le fatture, i flag sugli account, la logica dei permessi - tutto uguale, solo in due copie che qualcuno deve tenere allineate a mano.

Non è solo doppio lavoro, è una doppia possibilità di sbagliare. Una correzione a una regola di commissione atterra in un pannello e nell'altro no, perché qualcuno se n'è dimenticato. Un nuovo campo su un account cliente appare in un marchio e manca nell'altro. Più a lungo vive, più le due copie si allontanano, finché non si riesce più a dire quale sia quella giusta.

Abbiamo quindi deciso che il nucleo è uno solo. I clienti di entrambi i marchi vivono in un unico back office, su un unico modello di dati, serviti da un'unica API. La differenza la fa non codice separato, ma l'ambito dei permessi steso sopra l'insieme comune.

Il cuore di questo pannello è il controllo degli accessi ristretto per marchio. Il ruolo di un dipendente non è globale. È legato a un marchio preciso, e la portata dei suoi permessi finisce esattamente al confine di quel marchio. Qualcuno del team VulCode vede i clienti VulCode e solo loro, anche se questi clienti stanno fisicamente nello stesso back office di quelli di Aphrodi.

Ciò che conta è dove questo confine viene verificato. Se la restrizione fosse solo un filtro nell'interfaccia, si potrebbe aggirare aggiungendo l'id altrui all'indirizzo. Per questo la verifica dell'ambito sta all'ingresso dell'API e respinge la richiesta prima che tocchi i dati, indipendentemente da cosa mostra o nasconde il frontend.

In un pannello in cui si può contrassegnare un account, cambiare un tasso di commissione o muovere il saldo di un portafoglio, la domanda "chi è stato" cade inevitabilmente. Senza una risposta resta solo tirare a indovinare a posteriori e cercare il colpevole a memoria, cosa che è al tempo stesso ingiusta e inutile.

Per questo ogni azione sensibile si registra in un log di audit: chi l'ha eseguita, cosa riguardava e quando è avvenuta. Non è un registro tecnico per gli sviluppatori, ma una traccia leggibile per il team di supporto. Quando arriva una domanda su una modifica di un account, la risposta è nel log, e non nella testa di qualcuno.

Lo stesso meccanismo svolge un secondo ruolo, più silenzioso. La consapevolezza che ogni operazione lascia una traccia mette ordine nel lavoro da sé. Non si tratta di sospetto; in un team che gestisce il denaro altrui, la trasparenza è una condizione della fiducia, non un'aggiunta.

Tutta questa costruzione poggia su un'unica separazione: cosa è comune e cosa è separato. Comune è il nucleo - l'API, il modello di dati, gli account e i portafogli dei clienti, e il log di audit. Separato è solo l'ambito dei permessi e la visibilità dei clienti che ne deriva. Nient'altro deve ramificarsi.

La conseguenza di questa divisione è pratica e duratura. Aggiungere un altro marchio al pannello dello staff è una configurazione di ambito, e non un altro pannello da costruire e mantenere. Una nuova regola di commissione, un nuovo campo dell'account, una nuova operazione - tutto questo atterra una volta sola, nel nucleo comune, e vale ovunque all'istante, solo che ciascuno lo vede entro i confini del proprio marchio.

Il team lavora da un unico posto, e non da due schede del browser che deve tenere a mente e sorvegliare perché non divergano. I clienti di entrambi i marchi sono dove devono essere, ogni dipendente vede esattamente la propria fetta, e il confine tra i marchi regge a livello di API, e non sulla buona volontà dell'interfaccia.

Quando arriva una domanda su una modifica di un account, la risposta è nel log di audit, e non nella memoria di qualcuno o nelle congetture. Questo trasforma le conversazioni "chi è stato" da conflitto in una semplice verifica di un fatto, che in un team che gestisce il denaro altrui è la differenza tra la fiducia e una tensione costante.

La cosa più importante, però, è che l'architettura è pronta per il futuro. Aggiungere un terzo marchio non significa un terzo pannello, ma solo un altro ambito sullo stesso nucleo. Lo sviluppo del back office non si moltiplica per il numero di marchi, perché ciò che è comune resta comune e ciò che è separato si limita a quello che deve davvero esserlo.