Panel sztabowy

Wenn Sie eine Marke führen, ist ein internes Panel einfach: ein Team, ein Satz Kunden, ein Satz Regeln. Wenn es zwei Marken sind und langfristig mehr, wird die Sache heikel. Am einfachsten ist es, ein zweites Panel neben das erste zu stellen, aber dann pflegen Sie dieselben Konten, dieselben Wallets und dieselben Provisionsregeln doppelt, und jede Korrektur muss an zwei Stellen landen, sonst driften die Versionen auseinander.

Das Staff-Panel ist unsere Antwort auf diese Spannung. Ein Dashboard fasst die Kunden von VulCode und Aphrodi zusammen, aus einer Ansicht betreut, aber mit einer harten Grenze: ein Mitarbeiter, der einer Marke zugeordnet ist, sieht die Kunden der anderen nicht. Dazu kommt eine Sache, nach der früher oder später jedes Support-Team fragt: wer hat wann dieses Flag am Konto geändert. Diese Fallstudie handelt davon, wie wir einen gemeinsamen Kern mit einer Trennung vereint haben, die wirklich halten muss und nicht nur so aussehen.

Zwei Marken aus zwei getrennten Panels zu betreuen sieht harmlos aus, bis Sie zählen, wie viel sich zwischen ihnen wiederholt. Das Kundenmodell ist dasselbe. Die Wallet ist dieselbe. Das Partnerprogramm und die Provisionsregeln sind dieselben. Rechnungen, Konto-Flags, die Berechtigungslogik - alles dasselbe, nur in zwei Kopien, die jemand von Hand in Einklang halten muss.

Das ist nicht nur doppelte Arbeit, es ist eine doppelte Chance auf einen Fehler. Eine Korrektur an einer Provisionsregel landet in einem Panel und im anderen nicht, weil jemand es vergessen hat. Ein neues Feld am Kundenkonto erscheint in einer Marke und fehlt in der anderen. Je länger das lebt, desto weiter entfernen sich die beiden Kopien voneinander, bis man am Ende nicht mehr sagen kann, welche die richtige ist.

Also haben wir entschieden: der Kern ist einer. Die Kunden beider Marken sitzen in einem Backoffice, auf einem Datenmodell, betreut von einer API. Den Unterschied macht nicht separater Code, sondern der Berechtigungsumfang, der über das gemeinsame Ganze gelegt wird.

Das Herz dieses Panels ist die pro Marke eingegrenzte Zugriffskontrolle. Die Rolle eines Mitarbeiters ist nicht global. Sie ist einer konkreten Marke zugeordnet, und die Reichweite seiner Berechtigungen endet genau an der Grenze dieser Marke. Jemand aus dem VulCode-Team sieht VulCode-Kunden und nur diese, obwohl sie physisch im selben Backoffice sitzen wie die Kunden von Aphrodi.

Entscheidend ist, wo diese Grenze geprüft wird. Wäre die Eingrenzung nur ein Filter in der Oberfläche, ließe sie sich umgehen, indem man eine fremde id an die Adresse anhängt. Deshalb sitzt die Umfangsprüfung am Eingang zur API und weist die Anfrage ab, bevor sie Daten berührt, unabhängig davon, was das Frontend zeigt oder verbirgt.

In einem Panel, in dem man ein Konto markieren, einen Provisionssatz ändern oder einen Wallet-Saldo bewegen kann, fällt die Frage "wer war das" unvermeidlich. Ohne Antwort bleibt nur Raten im Nachhinein und Schuldsuche aus dem Gedächtnis, was sowohl ungerecht als auch nutzlos ist.

Deshalb schreibt sich jede sensible Aktion in ein Audit-Log: wer sie ausgeführt hat, was sie betraf und wann sie geschah. Das ist kein technisches Protokoll für Entwickler, sondern eine lesbare Spur für das Support-Team. Wenn eine Frage zu einer Kontoänderung aufkommt, steht die Antwort im Log und nicht in irgendjemandes Kopf.

Derselbe Mechanismus spielt eine zweite, leisere Rolle. Das Bewusstsein, dass jede Operation eine Spur hinterlässt, ordnet die Arbeit von selbst. Es geht nicht um Misstrauen; in einem Team, das fremdes Geld verwaltet, ist Transparenz eine Bedingung für Vertrauen und kein Zusatz.

Diese ganze Konstruktion beruht auf einer einzigen Trennung: was gemeinsam ist und was getrennt. Gemeinsam ist der Kern, also die API, das Datenmodell, die Konten und Wallets der Kunden sowie das Audit-Log. Getrennt ist nur der Berechtigungsumfang und die daraus folgende Sichtbarkeit der Kunden. Mehr muss sich nicht verzweigen.

Die Konsequenz dieser Aufteilung ist praktisch und langfristig. Eine weitere Marke zum Staff-Panel hinzuzufügen ist eine Umfangskonfiguration und kein weiteres Panel zum Bauen und Pflegen. Eine neue Provisionsregel, ein neues Konto-Feld, eine neue Operation - all das landet einmal, im gemeinsamen Kern, und gilt sofort überall, nur dass jeder es innerhalb der Grenzen seiner Marke sieht.

Das Team arbeitet von einem Ort aus und nicht aus zwei Browser-Tabs, die es im Kopf behalten und beobachten muss, damit sie nicht auseinanderdriften. Die Kunden beider Marken sind dort, wo sie sein sollen, jeder Mitarbeiter sieht genau seinen Ausschnitt, und die Grenze zwischen den Marken hält auf API-Ebene und nicht auf dem guten Willen der Oberfläche.

Wenn eine Frage zu einer Kontoänderung aufkommt, steht die Antwort im Audit-Log und nicht in jemandes Gedächtnis oder in Vermutungen. Das verwandelt "wer war das"-Gespräche von einem Konflikt in eine simple Faktenprüfung, was in einem Team, das fremdes Geld verwaltet, der Unterschied zwischen Vertrauen und ständiger Spannung ist.

Am wichtigsten ist jedoch, dass die Architektur für die Zukunft bereit ist. Eine dritte Marke hinzuzufügen bedeutet kein drittes Panel, nur einen weiteren Umfang auf demselben Kern. Die Entwicklung des Backoffice multipliziert sich nicht mit der Zahl der Marken, weil das Gemeinsame gemeinsam bleibt und das Getrennte sich auf das beschränkt, was wirklich getrennt sein muss.