Recommendation on where Sales places orders; a Sales-owned thin surface backed by a Revenue API, never a direct write, with one load-bearing design question for Revenue to settle first

Why

The operator is weighing whether the Sales team should place orders by working inside the Revenue app directly, or whether Sales should have its own ordering surface backed by Revenue. The choice touches the Sales and Revenue domain boundaries and the order-creation path, so Platform is surfacing a recommendation and naming the one design question that has to be settled before anyone builds.

This is a UI-placement question on its face, but the load-bearing part is the backing, not the screen.

What

The single-writer constraint comes first

Revenue is commercial truth. The invariants that protect real money live in Revenue and must be enforced server-side in exactly one place: the append-only ledger rule, the writeback-separation rule (the one that came out of the Square double-charge incident, where a provider success plus a writeback failure got collapsed into a single failed result and the customer was charged twice on retry), the funding-state external-reference rule, and idempotency. Any action that mints an order or takes a payment has to pass through Revenue's enforcement of those rules.

So the constraint, independent of the UI decision: there is one writer of orders, and it is Revenue. Whatever surface Sales uses must call a Revenue-owned API that enforces those invariants. A Sales surface that wrote Revenue's tables or ledger directly would have to re-implement the invariants and would drift from them. That is the failure mode to design out.

Given that, the UI question resolves toward a Sales-owned surface

Because the backing must be a Revenue API either way, the screen question reduces to workflow and blast radius, and both point the same direction.

The Revenue app is an operations and finance surface: refunds, ledger, funding sub-states, payment-method management. Putting sales reps inside it is the wrong shape for a conversion moment and over-exposes controls reps should never touch. A scoped Sales surface exposes only the take-first-payment or create-first-order path, shaped around the Lead and the cadence where the rep is already working.

The precedent already exists twice in our own contracts. Sales reads Person from Platform's identity service by API and never shadow-copies it. And the sales-scheduling-surface contract was created precisely because Sales used to reach into Delivery's lesson surface through ad-hoc paths that bypassed the lock state machine in some flows; the fix was a Delivery-owned transactional surface that Sales calls, and in that same flow Sales already submits its reservation request through Revenue's credit-reservation-lock surface rather than minting the reservation itself. The ordering question is the same pattern: a Revenue-owned surface that Sales calls.

The one design question Revenue has to settle first

"Place an order" does not map cleanly onto the current model, and this is the part to resolve before building. Today an Order is largely a byproduct of the credit-reservation-lock state machine. The order-flow contract lists created_via values of portal, cli, webhook_provider_invoice, webhook_growth_lead_close, and backfill, and order creation on first lock confirmation per Person is internally coupled to the state machine, not exposed as a subscription. The same first credit.locked is what emits customer.handoff, which is what closes the originating Lead.

So Revenue needs to decide what the Sales motion actually is:

Option A, point-of-sale order mint: Sales triggers a Revenue API that mints an Order directly at conversion time (likely a new created_via: sales_portal value).

Option B, reservation-request: Sales submits a reservation request through Revenue's existing credit-reservation-lock surface, and the order plus customer.handoff fall out of the state machine as they do today.

Option B keeps a single path to order creation and avoids order-creation and lock or handoff drift. Option A is more direct for the rep but introduces a second way an Order can come into existence, which has to be reconciled against the lock and handoff path so a Lead is not left open or double-closed. Platform's lean is toward B for exactly that reason, but the call is Revenue's to make as the owner.

Asks

Revenue: settle the order-mint versus reservation-request question above, then define the Revenue-owned API contract for the Sales surface and confirm that the lock and customer.handoff path stays the single source of order truth. This is the decision the rest of the work gates on.

Sales: confirm the conversion-moment requirements the surface has to cover (what the rep needs to do at close, what payment or reservation action is in scope) so the contract is shaped to the real motion, and confirm the surface stays scoped with no ledger access.

If Revenue judges the change load-bearing on order creation, Platform will steward a coordination ADR and help draft the contract. Flag it on this thread and Platform will pick it up.

References

• coordination/domains/sales.md, coordination/domains/revenue.md (domain scope and the does-not-own boundaries).
• coordination/contracts/order-flow/README.md (created_via values; order creation coupled to the state machine).
• coordination/contracts/sales-scheduling-surface/README.md (precedent: owning-domain transactional surface that Sales calls; Sales submits reservation requests through Revenue).
• coordination/contracts/credit-reservation-lock/README.md (first credit.locked emits customer.handoff, which closes the originating Lead).