Benefits als Umsatzquelle für Plattformen
· Roland Völkel
Zusammenfassung
- Embedded Benefits sind für eine Plattform eine Umsatzposition: Module werden als API-Leistung eingekauft, unter eigenem Namen verkauft, die Differenz bleibt als Marge beim Partner.
- Der Einkauf hat zwei Positionen – eine monatliche Fee für den API-Zugang und eine Fee pro aktiviertem Modul und Nutzer. Den Endkundenpreis setzt der Partner selbst.
- Der Umsatz entsteht auf der bestehenden Nutzerbasis. Es braucht keine neuen Endkunden, sondern Aktivierung in Accounts, die bereits zahlen.
- Mehrere Module addieren sich pro Nutzer. Die Marge skaliert mit aktiven Nutzern, nicht mit verkauften Accounts.
- Der Business Case kippt an drei Stellen: Aktivierungsrate, Vertriebsaufwand und 1st-Level-Support. Alle drei liegen beim Partner, nicht beim Infrastruktur-Anbieter.
Für eine Plattform sind Embedded Benefits eine Umsatzposition, kein Zusatzfeature. Die Plattform kauft einzelne Benefit-Module als API-Leistung ein, verkauft sie unter ihrem eigenen Namen an die eigenen Endkunden und behält die Differenz. Weil Benefits monatlich laufen, wiederholt sich diese Differenz – sie landet im MRR, nicht in einem Einmalerlös. Was Embedded Benefits als Kategorie sind, steht im Überblick unter Was sind Embedded Benefits; hier geht es um die kommerzielle Seite.
Wie aus einem Benefit-Modul eine Umsatzposition wird
Die Mechanik hat drei Teile: Einkauf, eigener Preis, Marge.
Der Einkauf besteht aus zwei Positionen. Eine monatliche Plattform-Fee deckt den Zugang zur API, die Sandbox, das Enablement und den laufenden Betrieb. Dazu kommt eine Fee pro aktiviertem Modul, Nutzer und Monat. Die erste Position bleibt konstant, die zweite wächst mit der Nutzung.
Den Verkaufspreis setzt die Plattform selbst. Es gibt keine Preisbindung und keinen vorgegebenen Endkundenpreis. Bei den gängigen Modulen – Mahlzeit, Gutschein, Mobilität – liegt der marktübliche Endkundenpreis grob beim Doppelten des Einkaufspreises.
Die Marge bleibt vollständig beim Partner. Sie ist kein Provisionsanteil und keine Umsatzbeteiligung, sondern die Differenz aus einem Wiederverkauf.
| Position | Wer setzt sie | Verhalten |
|---|---|---|
| Plattform-Fee für den API-Zugang | Infrastruktur-Anbieter | fix pro Monat, unabhängig von der Nutzerzahl |
| Modul-Fee | Infrastruktur-Anbieter | variabel, pro aktiviertem Modul und Nutzer |
| Endkundenpreis | Plattform | frei, im eigenen Preismodell |
| Marge | Plattform | Endkundenpreis minus Modul-Fee, monatlich wiederkehrend |
Warum die Rechnung auf der bestehenden Nutzerbasis aufgeht
Der Umsatz kommt nicht von neuen Logos, sondern aus Accounts, die schon zahlen. Die Akquisitionskosten für diese Kunden sind bezahlt, der Vertragsrahmen steht, die Stammdaten der Mitarbeitenden liegen im System. Was fehlt, ist die Aktivierung eines Moduls.
Damit verschiebt sich die Größe, an der der Umsatz hängt. Er skaliert nicht mit verkauften Accounts, sondern mit aktivierten Nutzern:
aktivierte Nutzer × Marge pro Nutzer und Modul × Module pro Nutzer × 12 = zusätzlicher ARR
Die Basis ist dabei nicht die Zahl Ihrer Accounts, sondern die Zahl der Mitarbeitenden in diesen Accounts. Bei einem Kunden mit 400 Beschäftigten trägt ein aktiviertes Modul 400-mal, nicht einmal. Daran hängt der Unterschied zwischen einer Preisposition pro Account und einer Marge pro Nutzer: Die eine wächst mit Ihrem Vertrieb, die andere mit dem Personalbestand Ihrer Kunden.
Rechnen Sie die Formel an Ihrer eigenen Basis durch, nicht an einer Modellplattform. Zwei Faktoren sind dabei größer als der Preis: die Aktivierungsrate und die Zahl der Module pro Nutzer. Ein zweites und drittes Modul erhöht die Marge pro Nutzer ohne zusätzliche Integration und ohne neuen Verkaufsprozess – das ist der Unterschied zu einem Feature, das einmal Umsatz bringt und dann im Paketpreis verschwindet.
Was Sie dafür nicht bauen
Der Umsatz entsteht ohne eigenes Benefit-Engineering. Beim Infrastruktur-Anbieter liegen:
- die Prüfung der eingereichten Belege,
- die Auszahlungs- und Guthabenlogik pro Modul,
- die lohnsteuerliche Bewertung und die abrechnungsfertigen Reporting-Dateien,
- die jährliche Anpassung der Steuerwerte. Der amtliche Sachbezugswert etwa wird jedes Jahr neu festgesetzt, üblicherweise im Oktober oder November für das Folgejahr – wer die Logik selbst baut, pflegt sie auch jedes Jahr nach.
Ein Punkt gehört präzise gesagt: Hrmony übernimmt die steuerrechtliche Haftung beim Modul Mahlzeit, und zwar für die im Rahmen der Einzelbelegprüfung geprüften Belege. Bei den übrigen Modulen bleibt die steuerliche Verantwortung im Einzelfall beim Arbeitgeber. Wie sich Aufwand und Risiko zwischen Eigenbau und Einkauf verteilen, ist in Make or buy bei der Benefits-Infrastruktur durchgerechnet.
Drei Wege, Benefits im eigenen Preismodell zu verankern
Die Mechanik gibt die Marge her – wo sie sichtbar wird, entscheidet Ihr Preismodell.
Als Add-on pro Nutzer. Das Modul steht mit eigenem Preis neben dem Kernprodukt. Die Marge ist direkt messbar, die Adoption läuft langsamer, weil jeder Endkunde eine eigene Kaufentscheidung trifft.
Gebündelt in ein höheres Tarifpaket. Benefits werden Teil eines größeren Pakets und heben dessen Preis. Die Marge verschwindet in der Paket-Marge, treibt dafür Upgrades aus niedrigeren Stufen.
Ohne Aufpreis im Paket. Keine direkte Marge, dafür ein Argument gegen Abwanderung. Wie belastbar dieser Effekt ist, behandelt Plattform-Churn senken.
Für den ersten Business Case ist der Add-on-Weg der belastbarste, weil er die Marge isoliert messbar macht. Bündeln lässt sich später immer noch.
Wo die Marge wieder verschwindet
Drei Stellen, an denen die Rechnung nachgibt – alle drei liegen bei Ihnen:
Aktivierung. Verkauft ist nicht aktiviert. Ein Endkunde, der das Modul im Vertrag hat, es aber nicht ausrollt, erzeugt keine Marge, weil die Modul-Fee an aktive Nutzer gebunden ist. Die Aktivierung gehört ins Onboarding, nicht in den Vertrag. Zwei Hebel wirken früh: das Modul im Onboarding-Flow des Endkunden platzieren, statt es in den Einstellungen zu verstecken, und von den Mitarbeitenden kein separates Konto verlangen.
Vertrieb. Ihr Team verkauft ein Produkt, das es nicht gebaut hat, und wird zu Steuerfragen gefragt. Enablement, Playbooks und der 2nd-Level-Support kommen vom Anbieter, das Gespräch mit dem Endkunden führen Sie.
Support. Belegfragen einzelner Mitarbeitender landen zuerst bei Ihnen. Ohne saubere Eskalationsstufe frisst dieser Aufwand die Marge der ersten Kohorte auf.
Was vor dem Business Case zu klären ist
- Wie viele Ihrer Endkunden beschäftigen Mitarbeitende in Deutschland? Die Steuerlogik der Module ist national, die Marge entsteht nur dort.
- Welche Module passen zu Ihrer Nutzerbasis – und welche Daten haben Sie dafür schon? Für Personalstammdaten-Systeme gilt das anders als für Abrechnungssysteme, siehe Embedded Benefits für HRIS.
- Wie viele Module pro Nutzer sind in zwölf Monaten realistisch?
- Wer verkauft: Bestandsvertrieb, Customer Success oder Self-Serve im Produkt?
- An welcher Stelle Ihres Preismodells landet die Position – Add-on, Paket oder Retention-Argument?
Wenn Sie die Rechnung an Ihrer eigenen Nutzerbasis durchspielen wollen: Module, Integrationsweg und Ansprechpartner stehen auf der Embedded-Landingpage.