Usage Metering & Billing Pipeline  ·  View 03 of 22  ·  People and journeys

Actors and Their Core Journeys

Four groups, nine actors, and what each of them is actually trying to get done.

Editable source SVG draw.io All views
Customers Customer platform admin 1.5 M accounts Goal — Tell me today what this month will cost, and let me check your invoice against my own logs. Core journeys Predict this month's bill Reconcile an issued invoice Set a spend cap Customer finance owner procurement, audit Goal — Give me a line I can put in front of an auditor without opening a support ticket. Core journeys Export invoice evidence Dispute a line The business Pricing manager 2,000 plan versions Goal — Launch a meter and a tier without waiting for an engineering release. Core journeys Publish a plan version Preview a price change Finance controller monthly close Goal — Close the period on time, and never issue a number I cannot defend. Core journeys Review the draft run Issue or hold an invoice Authorise a credit memo Engineering and operations Billing engineer on call through close Goal — When a figure is wrong, let me replay the evidence instead of writing correction SQL. Core journeys Restate a wrong invoice Investigate a metering gap Product engineer ships new meters Goal — Instrument a meter and see within minutes whether my events are actually being billed. Core journeys Register a meter Verify acceptance Machines and third parties Product & edge services 250k events/s Goal — Hand off usage without ever waiting on the billing path. Core journeys Emit a usage event Payment, tax and ERP 3 systems Goal — Receive an issued invoice once, and the identical one on replay. Core journeys Consume invoice.issued External auditor annual Goal — Verify a figure independently, from evidence I can check myself. Core journeys Sample an invoice line Actors and Their Core Journeys Person or role Journey / task Application we own External / third party Goals are in each actor's own voice. Two journeys get their own map: predicting the bill, and putting a wrong one right. v 1.0 · owner Architecture Practice · date 2026-10

Decisions

  • The customer admin and the customer finance owner are modelled separately because they want different artefacts: one wants a forecast, the other wants evidence. Collapsing them produces a usage dashboard that no auditor can use.
  • The pricing manager is a first-class actor with a self-service path, which is what forces pricing to be versioned configuration rather than code.
  • The external auditor is in the cast. If verification by an untrusting third party is not a goal, most of the retention and provenance cost in this design is unjustified.

What this forces

  • A provisional figure must be labelled as provisional, because the admin's goal is prediction and the finance owner's is reconciliation.
  • Every invoice line must expand to its events, because three of the nine actors need that and none of them can be told to trust the number.
  • The product engineer's goal — see within minutes whether events are being billed — is why per-producer acceptance reporting exists at all.

Risks

  • Nine actors on one platform is a wide surface for authorisation mistakes; view 20 holds the answer and view 21 the mechanism.
  • Two of the three privileged actions belong to internal actors under month-end time pressure, which is exactly when a second approver is most resented and most necessary.