The operator's workspace and a customer's

The same product, reached by two paths#

A customer's browser asks for a different set of URLs from the operator's. A small adapter in the front end rewrites each operator path into its customer equivalent, and the back end keeps an allowlist of what a customer session may call at all. Behind both, the code that answers is the same code.

What is genuinely operator-only#

Verifying a customer's payment

Confirming that money arrived is the operator's business, not a capability of the product a customer uses.

JBRH's own pricing

What Connect costs is the operator's commercial data. A workspace's own plan and usage are visible to that workspace; the pricing behind them is not.

Enquiries sent to JBRH through the public website

These are addressed to the operator and sit outside every workspace by design, which is why they are not a customer feature that happens to be hidden.

That is the complete list, and the shortness of it is the point. Everything else — phone, email, messaging, prospecting, relationships, knowledge, memory, autonomy, files, the data grid, the Assistant — is one implementation serving both audiences.

How the claim is kept honest#

Parity here is enumerated rather than asserted. A test reads the route table out of the running application and compares every operator capability against every customer one. Where the customer surface renames something, the rename is recorded explicitly — a customer's *people* are the operator's *relationships*, and *knowledge sources* are the *knowledge bank* — so a different name never reads as a missing feature.

Capabilities a customer genuinely cannot reach yet are listed with a reason, and the list is allowed to shrink and never to grow. A new capability that arrives for one audience only fails the check, which means the asymmetry has to be argued for at the time rather than discovered by a customer months later.

• A feature that works for the operator and refuses for a customer is a routing gap, not a product decision, until somebody writes down that it is one.
• A screen that renders a smaller version of itself for a customer is the same failure wearing different clothes.
• The check runs against the live route table rather than a document, so it cannot pass by describing an intention.

What this means for you#

1. Read any page in this documentation as applying to you, whichever audience you are, unless it says otherwise in its own words.
2. Where a page names an allowance or a limit, that is the commercial difference showing: the same capability, bounded differently.
3. If something works for somebody at JBRH and not for you, report it as a defect rather than assuming it is a tier you are not on. There are no tiers of capability.
4. If a page describes a screen you cannot reach at all, check the short list above before anything else — those three are the deliberate cases.

Questions#

Related#

• Account and access
• Which workspace you are in
• Your plan
• The customer facade
• Routing a request for the Owner or a customer
• Autonomy for the Owner and for a customer
• One implementation, two audiences