Panel klienta VulCode

VulCode ist unsere eigene Marke, also haben wir dieses Panel für uns selbst gebaut, und das erwies sich als der schwierigste denkbare Kunde. Wenn man etwas für sich selbst baut, gibt es niemanden, hinter dem man sich verstecken kann: jede Abkürzung, jede Zahl, die nicht aufgeht, fällt direkt auf einen selbst zurück. Deshalb sollte dieses Projekt von Anfang an die Vorlage dafür sein, wie ein Kundenpanel bei uns überhaupt aussieht, und keine Behelfslösung für den internen Gebrauch.

Die Aufgabe klang einfach: dem Kunden einen einzigen Ort zu geben, an dem er alles sieht, was ihn betrifft, und Angelegenheiten selbst erledigt, die früher eine E-Mail erforderten. In der Praxis bedeutete das, mehrere Welten auf einmal zu verbinden - den Projektstatus, Rechnungen, Support-Tickets und ein Partnerprogramm, das mit echtem Geld rechnet - zu einem zusammenhängenden Bildschirm, der auf dem Schreibtisch und in der Hosentasche gleich funktioniert. Diese Fallstudie zeigt, wo die echten Fallen lagen und wie wir sie umgangen haben.

Vor dem Panel endete jede Frage nach einer Projektphase oder einem Dokument in einer E-Mail, und die Antwort hing davon ab, wer sie gerade las und ob er sich an den Kontext erinnerte. Das skaliert nicht einmal bei einem Dutzend Kunden: dieselbe Information lebte im Postfach einer einzigen Person, und der Kunde wartete, statt einfach hinzuschauen.

Das Panel dreht das um. Der Kunde loggt sich ein und hat sofort seine Projekte mit dem Arbeitsstatus vor sich, eine Liste der Rechnungen mit dem, was bezahlt und was offen ist, sowie die Historie aller Tickets, die er je eröffnet hat. Nichts muss aus E-Mails herausgesucht werden, denn die Quelle der Wahrheit ist eine einzige Ansicht und nicht das Gedächtnis von jemandem.

Die Wirkung ist auf beiden Seiten spürbar. Der Kunde wartet nicht mehr auf einen Menschen, um Dinge zu erfahren, die das System ohnehin kennt. Das Team beantwortet dieselben Fragen nicht mehr zum hundertsten Mal, weil die Antwort schon auf dem Bildschirm steht, bevor sie überhaupt jemand tippt.

Ein Partnerprogramm sieht harmlos aus, bis man anfängt, Provisionen auf Beträgen mit Grosze zu berechnen. Hier beginnen die klassischen Dramen: zehn Prozent von 19.99 zł auf einer Gleitkommazahl berechnet können drei leicht unterschiedliche Ergebnisse in der Provisionsliste, in der Wallet und auf der Auszahlung ergeben, und dann gehen die Salden nicht mehr auf und niemand traut dem Panel.

Deshalb halten wir das Geld im gesamten Panel als ganze Zahlen in Grosze und berechnen jede Provision auf Integern. Es gibt hier nie einen Bruchteil eines Złoty, der sich einmal in die eine und einmal in die andere Richtung runden könnte. Eine Operation, eine Abrundungsregel, dasselbe Ergebnis überall, wo dieser Betrag auftaucht.

Ein Kundenpanel zeigt Geld und Dokumente, also ist die Frage "wer darf das sehen" nicht kosmetisch. Der Kunde soll ausschließlich seine eigenen Daten sehen, das Team nur das, wozu es berechtigt ist, und die Grenze zwischen ihnen darf nicht davon abhängen, ob das Frontend gerade einen Button versteckt hat.

Wir haben das auf rollenbasierter Zugriffskontrolle und sicherer Authentifizierung aufgebaut, aber die entscheidende Wahl ist architektonisch: den Umfang dessen, was man sehen und tun kann, prüft das Backend am Eingang zur API, nicht die Oberfläche. Das Frontend kann zeigen oder verbergen, was es will, aber wenn eine Anfrage fremde Daten betrifft, weist die API sie ab, bevor sie überhaupt die Datenbank erreicht.

Es ist dasselbe Prinzip, das wir überall anwenden: man bewacht die Grenze dort, wo Daten von außen hereinkommen, also an der API, und verlässt sich nicht darauf, dass der Nutzer keine Kennung in der Adresse austauscht.

Der Kunde sitzt nicht die ganze Zeit am Computer. Die Rechnung prüft er in der Straßenbahn, auf eine Ticket-Benachrichtigung reagiert er vom Telefon. Dafür eine separate mobile App zu bauen würde einen zweiten zu pflegenden Code bedeuten und die Gewissheit, dass die beiden Versionen früher oder später auseinanderdriften.

Stattdessen ist das Panel eine Web-App, die sich als PWA auf dem Telefon installiert, mit einem Manifest und einem Service Worker. Derselbe Code, dasselbe Backend, dieselbe Provisionslogik. Auf dem Computer ist es ein voller Desktop, auf dem Telefon ein Icon auf dem Startbildschirm und ein Fenster ohne Browserleiste, das sich wie eine native App verhält.

Am einfachsten ist es, ein Panel zu bauen, das auf im Voraus vorbereiteten Zahlen gut aussieht. Es sieht gut aus, bis jemand klickt und sich herausstellt, dass darunter nichts ist. Wir sind den umgekehrten Weg gegangen: das Panel steht vom ersten Tag an auf einem echten Backend, und jeder Bildschirm zeigt das, was tatsächlich in der Datenbank steht.

Diese Wahl kostet am Anfang mehr, weil man eine funktionierende API braucht, bevor überhaupt etwas gezeichnet wird. Sie zahlt sich aber sofort aus, weil es keinen Moment "die Daten hängen wir später an" gibt, in dem üblicherweise all die Annahmen auftauchen, die den Kontakt mit der Realität nicht überlebt haben. Was man im Panel sieht, ist das, was das System wirklich weiß.

Der Kunde bekommt einen einzigen Ort, an dem er seinen Stand sieht und Angelegenheiten selbst erledigt, die früher eine E-Mail an das Team erforderten. Er kommt herein, prüft ein Projekt, lädt eine Rechnung herunter, antwortet in einem Ticket, schaut auf den Provisionssaldo aus dem Partnerprogramm, und wenn er gerade unterwegs ist, macht er dasselbe vom Telefon aus, weil es dieselbe App ist. Nichts davon hängt davon ab, ob jemand aus dem Team gerade am Postfach sitzt.

Auf unserer Seite ist der Gewinn ebenso konkret. Das Partnerprogramm läuft, ohne dass jemand etwas von Hand nachrechnet, weil es von Code auf ganzen Zahlen bewacht wird und nicht von einer Tabelle, die jemand abstimmen muss. Die Salden stimmen, weil es keine Stelle gibt, an der ein Rundungsfehler entstehen könnte. Das Team gewinnt die Zeit zurück, die früher in die Beantwortung derselben Fragen floss.

Am wichtigsten ist jedoch, dass dieses Panel zu unserer Vorlage wurde. Der Kern, auf dem es steht - Rollen, Wallets, Provisionen, Tickets, i18n, App-Modus - ist sauber genug, dass er sich auf weitere Marken übertragen ließ, ohne von Grund auf neu geschrieben zu werden. Wir haben mit dem schwierigsten Kunden angefangen, uns selbst, und heraus kam eine Architektur, die wir später nur noch in neue Farben gekleidet haben.