Das B2B-Kundenmodell

Bevor Sie einen einzigen Datensatz anlegen, klären Sie, wer Ihr Kunde ist. Im B2B ist die Antwort fast nie die Person, die im Shop tippt. Shops, die das falsch abbilden, zeigen einem Einkäufer den Vertragspreis und seinem Kollegen den Listenpreis.

Die Frage, die sich ein B2C-Shop nie stellt

Ein Verbrauchershop kennt eine Sorte Kunde: eine Person mit Adresse und Kreditkarte. Preis, Rabatt, Bestellhistorie und Zahlungsart hängen an dieser Person.

Nehmen Sie dagegen eine gewöhnliche B2B-Situation. Ein Unternehmen betreibt eine Werkstatt in Bochum und einen zweiten Standort in Erfurt. Vier Personen bestellen bei Ihnen:

• der Werkstattleiter, der nachbestellt, was fehlt, bis zu ein paar hundert Euro
• ein Auszubildender, der einen Warenkorb füllen, aber nicht abschicken darf
• der Einkauf, der den Rahmenvertrag verhandelt hat und sehen will, was darauf bestellt wurde
• der Geschäftsführer, der alles über 5.000 € freigibt und selbst nichts bestellt

Fragen Sie „Wer ist der Kunde?“, hält nur eine Antwort stand: das Unternehmen. Der Vertragspreis gehört dem Unternehmen. Das Kreditlimit gehört dem Unternehmen. Die Kundennummer in Ihrem ERP gehört dem Unternehmen. Die vier Personen sind vier Zugänge zum selben Konto, mit vier verschiedenen Rechtesätzen.

Das ist das ganze Modell in einem Absatz. Alles Weitere ist Detail.

Zwei Ebenen: Organisation und Kontakt

Aus der Tabelle folgt die Regel, die Sie sich merken sollten: Kaufmännische Fakten hängen an der Organisation, Berechtigungen am Kontakt. Sieht eine Person im Unternehmen einen anderen Preis als ihr Kollege, liegt fast sicher ein Modellierungsfehler vor.

Status und Lebenszyklusphase sind zwei Achsen

Der nützlichste Gedanke in diesem Kapitel: „Zustand“ ist nie eine einzelne Spalte. Beide Ebenen trennen ihn mit Absicht.

An der Organisation:

• status ist active oder blocked. Eine Zugangsentscheidung. Gesperrt heißt: Dieses Unternehmen darf nicht handeln.
• lifecycle_stage ist lead, prospect, customer oder churned. Eine Pipeline-Phase. Sie gewährt nichts.

Die beiden sind getrennt, weil eine gemeinsame Spalte eine Frage ohne Antwort erzeugt: „Interessent, darf der sich also anmelden?“ Ein Interessent, der im Shop mit Preisen stöbern darf, und ein langjähriger Kunde, den Sie wegen offener Rechnungen abgeschaltet haben, sind beide gewöhnliche Zustände. Eine Spalte kann nicht beides ausdrücken.

Am Kontakt:

• status ist invited, active oder blocked: ob diese Person sich anmelden darf.
• registration_status ist pending, approved oder rejected: wie diese Person zu ihrem Konto kam, und ob Sie Ja gesagt haben. Siehe Selbstregistrierung.
• role ist die Berechtigungsleiter. Dazu gleich mehr.

Rollen sind eine Berechtigungsleiter

role hat einen von fünf Werten, geordnet von der geringsten zur höchsten Berechtigung:

„Werkstattleiter“, „Leiter Einkauf“ oder „Innendienst“ sind Funktionen. Sie gehören in job_title, ein Freitextfeld, das nichts gewährt. Die Unterscheidung wirkt pedantisch, bis Berechtigungen tatsächlich durchgesetzt werden: Eine role-Spalte voller Funktionsbezeichnungen entzieht allen auf einen Schlag die Rechte.

Die Rolle entscheidet, was eine Person darf. order_approval_limit, ein Betrag am Kontakt, entscheidet, bis wohin. Leer heißt: keine Obergrenze.

Was Sie damit gewinnen

Stimmt das Modell, werden vier Dinge möglich, die eine flache Kundenliste nicht kann.

Ein Vertragspreis, viele Einkäufer. Die Preisliste hängt an der Organisation, also sieht jede Person im Unternehmen ab der Anmeldung den verhandelten Preis. Siehe Vertragspreise für einen Kunden.

Kreditkontrolle. Zahlungsbedingungen, Kreditlimit und Liefersperre sitzen am Unternehmen, dort, wo die Forderung ist. Siehe Kreditkontrolle im B2B.

Der Freigabeprozess des Kunden. Ein requester reicht ein, ein approver gibt frei. Das ist die Einkaufsregel des kaufenden Unternehmens, in Ihrem Shop nachgebildet, und meist der Grund, warum der Kunde den Shop überhaupt nutzt. Siehe So funktioniert Procurement Governance.

Eine gemeinsame Bestellhistorie. Der Einkauf sieht, was die Werkstatt bestellt hat, weil beide dasselbe Konto sind. Einkäufer fragen ständig danach, und es ist unmöglich, wenn jede Person ihr eigener Kunde ist.

So funktioniert es in der Revenue Cloud

Die App Kunden hält alles davon:

• CRM › Organisationen enthält die Unternehmen: Name, customer_number, vat_id, branche (Freitext), Status, Lebenszyklusphase und die Konditionen.
• CRM › Kontakte enthält die Personen, jede optional mit Verweis auf eine Organisation.
• CRM › Rollen enthält die fünf Rollen und die Berechtigungen, die jede gewährt.
• CRM › Segmente enthält benannte Gruppen von Organisationen, von Hand oder per Regel.
• Adressen gehören einer Organisation, einem Kontakt oder beiden.

Zwei Dinge laufen im Hintergrund, und beide sind wichtig, wenn etwas seltsam aussieht:

• Die Anmeldung wird nicht hier gespeichert. Jeder Kontakt wird als Plattform-Benutzer gespiegelt, jede Organisation als Plattform-Team. Sitzungen, Passwort-Wiederherstellung und SSO bleiben damit Plattformfunktionen. Die Spiegelung ist rollback-sicher: Schlägt sie fehl, wird der Schreibvorgang hier zurückgenommen, die beiden Seiten können nicht auseinanderlaufen.
• Was ein Unternehmen gekauft hat, ist eine lokale Projektion. Umsatz und Bestellzahlen werden nach Zeitplan aus der App Bestellungen nach organization_metrics gezogen, und genau das lesen umsatzbasierte Segmentregeln. Es ist eine Kopie mit Zeitstempel, kein Live-Join. Das zählt, wenn eine Regel falsch aussieht. Siehe Kundendaten-Hygiene.

Weiter

• So funktioniert Procurement Governance — Kostenstellen, Budgets und Freigaben, und was sie schützen.
• Organisationen und Hierarchien — die Unternehmen anlegen und eine Gruppe mit mehreren Standorten abbilden.