Read the account, contact, deal, and next action without turning status into a story.

The object model

An organisation is the account; adults are contacts; a proposed purchase is the deal.

The account holds the durable organisation relationship. In the current studio workflow, a school is the account, joined to a national-directory row when that link exists. The district sits above it and is resolved from that directory’s local-education-agency identifier. Nobody needs to type and maintain a second parent-account string. An independent organisation can resolve as independent rather than as an error.

Contacts are plural because an organisation rarely acts through one person. The day-to-day user, contract signer, programme lead, and business-office contact may be different adults with different reasons to participate. Contact records belong to the account and carry roles that preserve those differences. The CRM model described here is adult organisation context; it is not a customer roster.

The deal describes the proposed commercial relationship: amount in integer cents, owner, stage, close period, probability source, tasks, and catalog-backed line items. A client cannot declare its own line-item price; the server re-reads the referenced catalog value. A deal may exist before a customer workspace exists. Winning through the explicit conversion path provisions the customer and makes that deal immutable.

Status and outcome

A stage helps organise work; an outcome needs its own transition and evidence.

Open stages describe the studio’s process and may carry default probability and rot days. Moving a deal can be useful without changing the external world. Won and lost deals leave the forecast because they are no longer probable future revenue. A deal with no stage has no probability basis and is skipped rather than assigned an invented default.

The advertising workflow has a stricter document ladder. A proposal is assembled from the organisation’s rate card and can be sent, accepted, or declined only through legal transitions. Acceptance creates the insertion order. Creative and fulfillment campaign attachment are refused until that order is signed. The refusal includes the actual status so the operator knows which evidence is missing.

Conversion is not merely a green label. It provisions the customer workspace, after which the original deal cannot move backward. Likewise, the tear-sheet route creates a record rather than merely moving a stage. When the placement has a linked order, at least one paid invoice for that order is required; without a linked order, that invoice branch does not run. Record creation does not establish that this route renders a document. The distinction keeps reporting from asserting that a real event occurred merely because a user edited a field.

Money documentation

An offline settlement record documents an event elsewhere; it does not transport payment.

The live-payments switch defaults off. When it is off, provider credentials are not used. The reachable path can record an attested offline settlement with the method, reference, and server-resolved staff actor. A request without the required evidence is refused without mutation. This preserves an audit account of what an authorised person says occurred outside MyClient.

That record does not charge a card, pull a bank account, send funds, confirm provider settlement, issue a refund, or reconcile a bank feed. An invoice should never claim a provider payment that did not happen. If an operator needs payment transport, provider dispute handling, or live balance confirmation, those belong to a separate operational system.