B2B-Treueprogramm: Händlerprämien automatisieren

Ein Händler sieht die versprochene Prämie in der E-Mail seines Kundenbetreuers, kann sie aber bei der Bestellung nicht einsetzen. Die Buchhaltung berechnet den Umsatz nach Abzug der Retouren, die Website hingegen anhand angelegter Warenkörbe. Ein B2B-Treueprogramm braucht in dieser Situation keinen weiteren Newsletter, sondern einheitliche Regeln für die Gutschrift, Nutzung und Prüfung von Prämien. Erst die Regeln, dann das Modul.

Ein Hersteller oder Distributor muss festlegen, wem die Prämie zusteht und was nach einer Änderung der Bestellung geschieht. Betrachten wir, wie sich ein Prämiensystem mit einem B2B-Portal und der Buchführung verbinden lässt, ohne unkontrollierte Rabatte zu gewähren.

Zuerst Empfänger und Wirtschaftlichkeit der Prämie festlegen

Bei einem Firmenkunden können ein Einkäufer, ein Abteilungsleiter und ein Finanzmitarbeiter beteiligt sein. Das Benutzerkonto einer Person ist nicht mit dem Unternehmen gleichzusetzen, das den Vertrag abschließt. Halten Sie deshalb in den Programmbedingungen ausdrücklich fest, wer teilnimmt: eine juristische Person, eine bestimmte Niederlassung oder eine andere vereinbarte Einheit. Legen Sie fest, ob die Umsätze der Niederlassungen zusammengeführt werden und wer die angesammelten Prämien einsetzen darf.

Eine Prämie für das Unternehmen und ein persönliches Geschenk an dessen Mitarbeiter sind unterschiedliche Modelle. Die zweite Variante kann den Einkaufsrichtlinien des Kunden widersprechen und darf daher nicht stillschweigend an die Stelle der ersten treten. Prämienform, Unterlagen und buchhalterische Behandlung müssen mit den zuständigen Finanz- und Rechtsexperten abgestimmt werden. Ein technisches Prämienmodul ersetzt diese Abstimmung nicht.

Wählen Sie das gewünschte Verhalten: regelmäßige Einkäufe, ein breiteres Sortiment oder einen vereinbarten Umsatz. Prüfen Sie das finanzielle Ergebnis nach Prämien, Logistik und Retouren und berücksichtigen Sie dabei bereits gewährte vertragliche Rabatte.

Welcher Mechanismus sich tatsächlich zu automatisieren lohnt

Punkte sind kein zwingender Bestandteil eines Treueprogramms. Manchmal ist ein transparenter Quartalsbonus für Kunden und Buchhaltung einfacher als ein komplexes Stufensystem. Vergleichen Sie die Mechanismen danach, welche Handlung sie fördern und welche Daten für eine faire Berechnung erforderlich sind.

Beginnen Sie mit einem Mechanismus. Legen Sie fest, wie Rabatte, Aktionscodes und Prämien kombiniert werden dürfen. Dokumentieren Sie bei vom Kundenbetreuer genehmigten Ausnahmen die verantwortliche Person und den Grund.

Gutschrift, Einlösung und Historie richtig aufbauen

Die Erfassung von Punktebuchungen sollte als Änderungsjournal angelegt werden, nicht als einzelnes bearbeitbares Feld „Saldo“. Jede Buchung benötigt einen Teilnehmer, einen zugrunde liegenden Beleg, die Art der Änderung, die Punktezahl, den Zeitpunkt und die Regelversion. Der aktuelle Saldo muss sich aus dieser Historie erklären lassen. Auch eine manuelle Korrektur wird als eigene Buchung mit Begründung erfasst.

Gutschrift nach einem vereinbarten Ereignis

Eine angelegte Bestellung ist noch kein bezahlter Einkauf. Legen Sie fest, wann die Prämie lediglich vorgemerkt ist und wann sie verfügbar wird: nach Zahlung, Versand oder einer anderen vereinbarten Bestätigung. Bei Teillieferungen ist eine entsprechende Berechnungsgrundlage erforderlich. Unterscheiden Sie im Portal zwischen vorgemerkten, verfügbaren und reservierten Punkten, damit der Käufer eine Prognose nicht für einen bereits einlösbaren Betrag hält.

Nach einer Störung kann ein Ereignis erneut eintreffen. Die Prüfung einer eindeutigen Kennung muss eine zweite Prämiengutschrift verhindern. Bewahren Sie die Version der Bedingungen auf, um frühere Berechnungen nachvollziehen zu können.

Einlösung mit Reservierung und Retouren

Wenn zwei Einkäufer gleichzeitig Bestellungen aufgeben, dürfen sie denselben Saldo nicht doppelt ausgeben. Sehen Sie eine Reservierung der Prämie, die endgültige Abbuchung nach einer festgelegten Bestätigung und die Freigabe der Reservierung bei Stornierung vor. Bleibt eine Bestellung hängen, muss die Reservierung eine klare Frist und einen kontrollierten Abschlussweg haben.

Bei einer Warenretoure sind zwei getrennte Entscheidungen nötig: Was geschieht mit den für diesen Einkauf erworbenen Punkten, und was mit den zur Bezahlung eingesetzten Punkten? Diese Vorgänge dürfen nicht verwechselt werden. Ein anschauliches Beispiel für Einstellungen zu Historie, Gültigkeitsdauer und Rückerstattungen bietet die offizielle Adobe-Commerce-Dokumentation zu Prämienpunkten. Diese Dokumentation allein belegt jedoch nicht, dass Ihre Lösung einen gemeinsamen Punktesaldo für ein B2B-Unternehmen unterstützt.

Hypothetisches Beispiel: Einkauf, Retoure und erneute Einlösung

Angenommen, ein Distributor vereinbart mit einem Firmenkunden folgende Regel: ein Punkt je 100 UAH der festgelegten Berechnungsgrundlage eines bezahlten Einkaufs. In diesem hypothetischen Beispiel sind Versandkosten und andere ausgeschlossene Positionen bereits aus der Grundlage entfernt; abgerundet wird je Beleg. Dies ist weder eine GL.ua-Fallstudie noch eine Empfehlung für einen bestimmten Umrechnungskurs.

Bei einer bestätigten Berechnungsgrundlage von 80 000 UAH schreibt das System 800 Punkte gut. Eine Teilretoure verringert diese Grundlage um 10 000 UAH: Eine separate Buchung storniert 100 Punkte, es bleiben 700. Für eine neue Bestellung reserviert der Käufer 300 Punkte. Bis zu ihrer Bestätigung sind 400 Punkte verfügbar, weitere 300 sind reserviert. Wird die neue Bestellung storniert, wird die Reservierung aufgehoben und es sind wieder 700 Punkte verfügbar.

Trifft die Meldung zur ursprünglichen Zahlung ein zweites Mal ein, ändert sich das Ergebnis nicht. Erfolgt die Retoure hingegen erst, nachdem alle Punkte verbraucht wurden, ist eine vorab vereinbarte Regel nötig: etwa ein kontrollierter negativer Punktesaldo, der durch künftige Gutschriften ausgeglichen wird. Verdecken Sie ihn nicht durch eine Null und ändern Sie den Preis einer abgeschlossenen Bestellung nicht ohne festgelegten Prozess.

Der Geldwert der Punkte, der maximal damit abdeckbare Anteil einer Bestellung und die Vereinbarkeit mit einer individuellen Preisliste sind gesondert abzustimmen: Das Beispiel legt diese nicht fest.

Wo Regeln und Zugriffsrechte angesiedelt sein sollten

Eine ERP-Integration ist dort erforderlich, wo das buchführende System Zahlungen, Lieferungen und Retouren bestätigt. Das CRM kann Vereinbarungen und das Partnersegment speichern, das Portal Bedingungen und verfügbare Aktionen anzeigen. Allerdings darf nur eine festgelegte Komponente die maßgebliche Quelle für den endgültigen Prämiensaldo sein. Mehrere unabhängige Berechnungen führen zu strittigen Beträgen.

Ein integriertes Modul ist sinnvoll, wenn es Ihre Regeln abdeckt. Einen separaten Dienst sollten Sie bei mehreren Kanälen erwägen, eine Eigenentwicklung bei nicht standardisierten Verträgen und Rollen. Prüfen Sie Lizenz, Kompatibilität, Export der Historie und Wartungskosten, nicht nur die Optik des Widgets.

Verknüpfen Sie das Unternehmen, seine Niederlassungen und die Benutzer über stabile Kennungen. Ein Einkäufer kann Leserechte erhalten, während nur eine freigegebene Rolle Punkte einsetzen darf. Das Ausscheiden eines Mitarbeiters darf weder die Unternehmenshistorie löschen noch ihm weiterhin Zugriff ermöglichen. Verwandte Regeln zur Annahme von Konditionen sollten zusammen mit der Freigabe von B2B-Angeboten und der Auftragsübergabe betrachtet werden; das Prämienjournal bleibt jedoch ein eigenständiger Prozess.

Das Programm vor der Freigabe für Händler prüfen

Die Abnahme muss belegen, dass sich der Saldo reproduzieren und ein Fehler ohne Verlust der Historie korrigieren lässt. Bereiten Sie Testunternehmen mit unterschiedlichen Rollen und Kontrollbelege vor.

1. Halten Sie die Regeln fest: Teilnehmer, Berechnungsgrundlage, Bestätigungsereignis, Rundung, Ausschlüsse, Gültigkeitsdauer und Einlöseverfahren.
2. Berechnen Sie die erwarteten Ergebnisse für Zahlung, Teillieferung, Retoure, Stornierung und Stufenwechsel manuell. Gleichen Sie jede Buchung mit dem System ab.
3. Wiederholen Sie Meldungen, ändern Sie deren Reihenfolge und unterbrechen Sie die Verbindung. Prüfen Sie, ob der Datenaustausch ohne doppelte Gutschrift wiederhergestellt wird.
4. Lassen Sie zwei Benutzer gleichzeitig Punkte einlösen. Prüfen Sie Reservierung, unzureichenden Saldo, Zugriffsverweigerung und Freigabe der Reservierung.
5. Stellen Sie den Ablauf der Gültigkeitsdauer und die Rückabwicklung einer bereits genutzten Prämie nach. Gleichen Sie Journal, Portal und die Daten der zuständigen buchführenden Komponente ab.
6. Starten Sie mit einer begrenzten Partnergruppe, benennen Sie eine für Abweichungen verantwortliche Person und prüfen Sie, ob sich neue Buchungen ohne Löschen der Historie stoppen lassen.

Gleichen Sie vor dem Pilotbetrieb eine parallele Berechnung ab, ohne Prämien auszugeben. Ergänzende Hinweise zur Bereitstellung von Änderungen bietet der Beitrag über sichere Releases für Onlineshops.

Risiken, Zeitrahmen und Kostenbestandteile

Die gefährlichste Abweichung besteht zwischen den Bedingungen für den Käufer und der tatsächlichen Systemlogik. Weitere Risiken sind doppelt angelegte Unternehmen, versteckte Rabattkombinationen, überfällige Reservierungen und unbegründete manuelle Änderungen. Beschränken Sie Befugnisse, protokollieren Sie Ausnahmen und legen Sie ein Verfahren zur Klärung von Streitfällen fest. Bei instabilen Kennungen oder ungeklärter Wirtschaftlichkeit sollte der Start verschoben werden.

Was die Dauer der Arbeiten bestimmt

Zuerst werden die Bedingungen abgestimmt und die Daten geprüft, dann Journal und Datenaustausch umgesetzt, anschließend Portal, Prüfszenarien und Pilotbetrieb. Die Dauer hängt von der Zahl der Systeme, der Verfügbarkeit einer Testumgebung, der Qualität der Historie und der Geschwindigkeit der Abstimmungen ab. Auch der Abschluss einer Prämienperiode muss geprüft werden: Ein erfolgreicher Betriebstag ersetzt das nicht. Eine kalendarische Schätzung sollte erst nach Prüfung der Integrationen und Ausnahmen erfolgen.

Planen Sie die Analyse der Regeln, Datenaufbereitung, Entwicklung oder Lizenz, Integrationen, Zugriffsrechte, Benutzeroberfläche, Tests und Schulung der Kundenbetreuer im Budget ein. Nach dem Start sind die Überwachung des Datenaustauschs, Abgleiche, Support und Anpassungen der Bedingungen erforderlich. Kalkulieren Sie die Finanzierung der Prämien selbst gesondert: Sie gehört nicht zu den Programmierkosten. Bewerten Sie den Erfolg anhand der Aktivität der Unternehmen, der Wiederholungskäufe und des finanziellen Ergebnisses nach den Anreizen, nicht anhand der Zahl ausgegebener Punkte.

Wo die Automatisierung beginnen sollte

Erstellen Sie vor der Plattformwahl eine Seite mit den Regeln und Kontrollbuchungen. Wenn das Team Retouren und Prämieneinlösungen unterschiedlich berechnet, beschleunigt die Automatisierung die Entstehung von Abweichungen. Beginnen Sie mit einem Mechanismus, der für den Partner verständlich und anhand des Journals überprüfbar ist.

Um die Umsetzung des Portals und des Datenaustauschs einzuschätzen, übermitteln Sie GL.ua (Glyanets) eine Programmbeschreibung, Beispielbelege und eine Systemliste im Rahmen eines Gesprächs über die Website-Entwicklung für Unternehmen. So entsteht eine konkrete Grundlage, um Arbeitsumfang, Integrationen und Abnahmekriterien festzulegen.