The B2B customer model

Before you create a single record, be precise about who your customer is. In B2B the answer is almost never the person typing in the shop. Shops that get this wrong end up giving one buyer the contract price and their colleague the list price.

The question a B2C shop never has to answer

A consumer shop has one kind of customer: a person with an address and a credit card. The price, the discount, the order history and the payment method all hang off that person.

Now take an ordinary B2B situation. A company runs a workshop in Bochum and a second site in Erfurt. Four people order from you:

• the workshop manager, who orders whatever is missing, up to a few hundred euros
• an apprentice, who is allowed to fill a cart but not to send it
• the purchasing department, who negotiated the framework agreement and want to see everything that has been ordered against it
• the managing director, who signs off anything over €5,000 and orders nothing himself

Ask "who is the customer" and only one answer holds: the company. The contract price is the company's. The credit limit is the company's. The customer number in your ERP is the company's. The four people are four ways into the same account, with four different sets of rights.

That is the whole model in one paragraph. Everything below is the detail.

Two levels: the organization and the contact

The rule that follows from the table: commercial facts attach to the organization; permissions attach to the contact. If one person at a company sees a different price than their colleague, you are almost certainly looking at a modelling mistake.

Status and lifecycle stage are two axes

The single most useful thing to internalise here: "state" is never one column. Both levels split it deliberately.

On the organization:

• status is active or blocked. An access decision. Blocked means this company may not trade.
• lifecycle_stage is lead, prospect, customer or churned. A pipeline stage. It grants nothing at all.

They are separate because merging them produces a question with no answer: "prospect, so may they log in?" A prospect who is allowed to browse a shop with prices, and a long-standing customer who has been shut off for non-payment, are both entirely ordinary states. One column cannot express both.

On the contact:

• status is invited, active or blocked: whether this person may sign in.
• registration_status is pending, approved or rejected: how this person came to have an account, and whether you said yes. See Self-registration.
• role is the permission ladder. See below.

Roles are a permission ladder

role is one of five values, ordered from least to most privileged:

"Werkstattleiter", "Leiter Einkauf" or "Innendienst" are job titles. They go in job_title, which is free text and grants nothing. This distinction looks pedantic until the day permissions are enforced: a role column full of job titles un-grants everybody at once.

The role decides what a person may do. order_approval_limit, an amount on the contact, decides how far. Empty means no ceiling.

What this buys you

Once the model is right, four things become possible that a flat customer list cannot do.

One contract price, many buyers. The price list is on the organization, so every person at the company sees the negotiated price the moment they sign in. See Contract prices for a customer.

Credit control. Payment terms, a credit limit and a delivery block sit on the company, where the receivable is. See Credit control in B2B.

The customer's own approval process. A requester submits, an approver signs. That is the buying company's procurement rule, reproduced in your shop, and usually the reason they will use the shop at all. See How procurement governance works.

A shared order history. Purchasing can see what the workshop ordered, because both are the same account. Buyers ask for this constantly, and it is impossible if every person is their own customer.

How this works in the Revenue Cloud

The Customers app holds all of it:

• CRM › Organizations holds the companies: name, customer_number, vat_id, branche (industry, free text), status, lifecycle stage, and the commercial terms.
• CRM › Contacts holds the people, each optionally pointing at an organization.
• CRM › Roles holds the five roles and the permissions each one grants.
• CRM › Segments holds named groups of organizations, by hand or by rule.
• Addresses belong to an organization, a contact, or both.

Two things happen behind the scenes, and both matter when something looks off:

• Sign-in is not stored here. Every contact is mirrored as a platform user and every organization as a platform team, so sessions, password recovery and SSO stay platform features. The mirror is rollback-safe: if it fails, the write here is undone, so the two sides cannot drift.
• What a company bought is a local projection. Revenue and order counts are pulled from the Orders app on a schedule into organization_metrics, and that is what revenue-based segment rules read. It is a copy with a timestamp, not a live join. That matters when a rule looks wrong. See Customer data hygiene.

Next

• How procurement governance works — cost centres, budgets and approvals, and what they protect.
• Organizations and hierarchies — create the companies, and model a group with several sites.