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. It records your standing with the company: whether you have blocked it. The status is shown on the record and in the organization list.
• 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 are they blocked?" A prospect you are courting, and a long-standing customer you have blocked for non-payment, are both entirely ordinary states. One column cannot express both.

On the contact:

• status is invited, active or blocked: where this person's account stands. invited means you have invited them and they have not joined yet.
• 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

Five roles are built in, ordered from least to most privileged. The list is yours: on CRM › Roles you load the built-in set and can add roles of your own.

"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. How far they may go on their own is a personal limit, set under Procurement and enforced through approval rules. The contact also carries an order_approval_limit, a stored amount that approval rules do not read. See How procurement governance works.

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 a purchase request, an approver approves it. 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 roles and the permissions each one grants. Load the built-in roles creates the five above; add your own beside them.
• CRM › Segments holds named groups of organizations, by hand or by rule.
• Addresses belong to an organization, a contact, or both.
• Document recipients on the organization say where each document goes: invoices, order confirmations, shipping notices and dunning letters, each to its own e-mail address or phone number.
• Receivables on the organization show the balance and the overdue amount your ERP reported, with the time it last confirmed them. They are a copy, not a live figure.

Two more things decide how people get in:

• Invitations. Creating a contact tells nobody anything. Inviting the contact mails them a link into the shop in the organization's name.
• Sign-in methods. The shop decides which methods exist: password, a mailed link, a mailed code, and whether a second factor is optional or required. An organization can tighten these rules for its own people, never loosen them.

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.