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. Er hält Ihr Verhältnis zum Unternehmen fest: ob Sie es gesperrt haben. Der Status steht am Datensatz und in der Organisationsliste.
• 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, ist der also gesperrt?“ Ein Interessent, um den Sie sich bemühen, und ein langjähriger Kunde, den Sie wegen offener Rechnungen gesperrt haben, sind beide gewöhnliche Zustände. Eine Spalte kann nicht beides ausdrücken.

Am Kontakt:

• status ist invited, active oder blocked: wo das Konto dieser Person steht. invited heißt: Sie haben die Person eingeladen, und sie ist noch nicht beigetreten.
• 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

Fünf Rollen sind eingebaut, geordnet von der geringsten zur höchsten Berechtigung. Die Liste gehört Ihnen: Unter CRM › Rollen laden Sie die eingebauten Rollen und können eigene ergänzen.

„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. Bis wohin sie allein gehen darf, regelt ein persönliches Limit, angelegt unter Procurement und wirksam über Freigaberegeln. Der Kontakt trägt außerdem ein order_approval_limit, einen gespeicherten Betrag, den Freigaberegeln nicht lesen. Siehe So funktioniert Procurement Governance.

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 eine Bestellanforderung ein, ein approver gibt sie 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 Rollen und die Berechtigungen, die jede gewährt. Die eingebauten Rollen laden legt die fünf von oben an; eigene ergänzen Sie daneben.
• CRM › Segmente enthält benannte Gruppen von Organisationen, von Hand oder per Regel.
• Adressen gehören einer Organisation, einem Kontakt oder beiden.
• Belegempfänger an der Organisation legen fest, wohin jeder Beleg geht: Rechnungen, Auftragsbestätigungen, Versandbenachrichtigungen und Mahnungen, jeweils an eine eigene E-Mail-Adresse oder Telefonnummer.
• Offene Posten an der Organisation zeigen Saldo und überfälligen Betrag, wie Ihr ERP sie gemeldet hat, mit dem Zeitpunkt der letzten Bestätigung. Sie sind eine Kopie, keine Live-Zahl.

Zwei weitere Dinge entscheiden, wie Personen hereinkommen:

• Einladungen. Einen Kontakt anzulegen teilt niemandem etwas mit. Laden Sie den Kontakt ein, bekommt er im Namen der Organisation einen Link in den Shop per E-Mail.
• Anmeldeverfahren. Der Shop legt fest, welche Verfahren es gibt: Passwort, ein zugesendeter Link, ein zugesendeter Code, und ob ein zweiter Faktor optional oder Pflicht ist. Eine Organisation kann diese Regeln für ihre eigenen Leute verschärfen, nie lockern.

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.