Ein Bonusprogramm, dessen Zahlen der Buchhaltung nicht widersprechen
Geschäftskunden sehen im Portal ihren laufenden Monatsumsatz, das daraus entstandene Bonusguthaben und wie weit es bis zur nächsten Stufe ist. Einlösen können sie selbst, ohne jemanden anzurufen.
Ausgangslage
Das Bonusprogramm gab es vorher auf Papier: ein Bonusheft, in dem gesammelt wurde, und ein Innendienst, der auf Anfrage nachgesehen hat, wie weit ein Kunde ist. Der Kunde musste also fragen, um zu wissen, wo er steht, und der Innendienst bei jeder dieser Fragen nachrechnen.
Ziel
Kunden sollen jederzeit selbst sehen, wie viel Umsatz sie im laufenden Monat gemacht haben, was daraus geworden ist, was ihnen bis zur nächsten Stufe fehlt, und ihr Guthaben ohne Rückfrage einlösen können.
Die harte Vorgabe ist, wem der Umsatz gehört: dem ERP. Das Portal liest dort und schreibt nichts zurück.
Lösung
Beim Öffnen zeigt das Portal den laufenden Monat: Nettoumsatz, die daraus errechneten Punkte, der Euro-Gegenwert, ein Fortschrittsbalken bis zur nächsten Stufe und einer für die verbleibenden Tage im Monat. Daneben die Stufenleiter, damit sichtbar ist, was als Nächstes kommt. Der Hinweistext richtet sich nach der Umsatzhöhe und sagt auch, wenn die erste Stufe noch nicht erreicht ist.
Im Wallet stehen verfügbares Guthaben und Gesamtsumme, im Bonusheft die gewohnte Sammelansicht aus dem Papierheft. Beim Einlösen wählt der Kunde den Shop, schiebt den Betrag in festen Schritten bis zu seinem verfügbaren Guthaben, sieht eine Vorschau, was danach übrig bleibt, und bestätigt die Bedingungen. Das legt den Vorgang an und benachrichtigt den Innendienst.
Der Innendienst arbeitet im gleichen Dashboard, sieht dort aber einen zusätzlichen Bereich mit den offenen Einlösungen, trägt den Gutscheinlink ein und verschickt ihn. Der Kunde bekommt eine gestaltete Mail mit dem Betrag, einem Einlöse-Button und dem Link als Fallback im Klartext.
Ergebnis
Wo es knifflig wurde
Zwei Wahrheiten über denselben Betrag
Der Umsatz gehört dem ERP, das Guthaben dem Portal, und beide naheliegenden Auswege scheitern. Alles live aus dem ERP zu rechnen geht nicht, weil eine spätere Gutschrift auch vergangene Monate verändert und damit bereits eingelöstes Guthaben rückwirkend entwerten würde. Alles ins Portal zu kopieren geht genauso wenig, weil dann jede Korrektur im ERP am Portal vorbeiläuft und der Kunde einen Stand sieht, den die Buchhaltung nicht kennt. Dazu kommt, dass die Bedingungen ausdrücklich auf das Rechnungsdatum abstellen und der laufende Monat sich bis zum Monatsende noch nach unten bewegen kann. Die Grenze zwischen „laufend und veränderlich“ und „abgeschlossen und festgeschrieben“ ist damit die wichtigste Stelle im ganzen System.
Ein Dashboard, drei Rollen
Kunde, Außendienst und Innendienst arbeiten in derselben Oberfläche, sehen aber unterschiedlich viel und dürfen unterschiedlich viel. Rollenabfragen in jedes Modul zu streuen hätte jede spätere Änderung an drei bis fünf Stellen erzwungen, und es ist genau die Art Code, in der man eine Berechtigungsprüfung vergisst. Dazu eine Anforderung, die sich fast widerspricht: der Außendienst soll wirklich sehen, was der Kunde sieht, ohne dadurch handeln zu dürfen. Einlösen im Namen eines Kunden ist ausgeschlossen. Die angezeigte Identität wird deshalb an einer zentralen Stelle aufgelöst und die Rollen getrennt davon geführt, sodass die fachlichen Module von Rollen nichts wissen müssen.
Was heißt eigentlich „verfügbar“?
Im Guthaben stecken vier verschiedene Dinge: erarbeitete Punkte aus abgeschlossenen Monaten, der laufende Monat, ein gesperrtes Startguthaben und offene Einlösungen. Ein einziger Kontostand kann das nicht ausdrücken. Das Startguthaben soll sichtbar sein und motivieren, sich aber nicht ausgeben lassen, und es wird erst frei, wenn der Kunde selbst etwas beigetragen hat. Reservierte Punkte müssen aus dem verfügbaren Betrag verschwinden, ohne aus der Gesamtsumme zu verschwinden. Die naive Umsetzung, den Bonus einfach dazuzuzählen, führt direkt zu einem Kunden, der Guthaben einlöst, ohne je bestellt zu haben.
Technische Umsetzung
Zwei Datenquellen, klar getrennt. Aus dem ERP kommen Rechnungen und Gutschriften, read-only über einen Connection Pool. Die eigene Datenbank hält nur den State des Portals selbst: welche Zugangsadresse zu welcher Kundennummer gehört, die festgeschriebenen Monatssummen und die Einlösungen. Diese Datensparsamkeit ist Absicht: was nicht im Portal liegt, kann dort auch nicht veralten.
Die Rechenregeln des Programms liegen als benannte Konstanten an einer Stelle, und die Texte in der Oberfläche werden aus denselben Werten gebildet. Bei einem Programm mit verbindlichen Teilnahmebedingungen zählt das: wer die Schwelle anpasst, ändert Rechnung und Beschriftung in einem Zug.
Login und Rollen kommen vom vorgeschalteten Proxy als Request-Header; eine eigene Benutzerverwaltung gibt es nicht. Ist eine Adresse noch nicht mit einer Kundennummer verknüpft, sieht der Nutzer statt des Dashboards einen Hinweis auf seinen Ansprechpartner.
Die Oberfläche ist von Anfang an fürs Handy gebaut, weil die Kunden sie dort benutzen. Das heißt Breakpoints, ausreichend große Tap-Targets und einen Ersatz überall dort, wo auf dem Desktop ein Hover-Effekt sitzen würde. Die Icons sind die Bilddateien des Kunden statt einer Icon-Bibliothek, damit das Corporate Design exakt bleibt.
Betrieb und Weiterentwicklung
Das Portal läuft im Container auf der Infrastruktur des Kunden, hinter ShinyProxy. Ein Push auf
main baut das Image und deployt die neue Version.
Das Portal läuft seit dem Frühjahr 2026 und wird weiter ausgebaut, jeweils dort, wo im Alltag noch jemand eingreifen muss. Derzeit ist das vor allem das Verschicken der Gutscheine.