Capability 01 · Operating model

Process Architecture

Design the operation before automating it.

I analyse how work moves through the organization—stages, decisions, ownership, handoffs, exceptions and controls—before defining which technology should execute it.

See the approach Browse the reference cases

One lifecycle · five layersThe same seven stages, read five ways. Choose a layer to bring it forward.

Read the lifecycle by layer

Lead to active customer: each stage with its owner, system, decision, exception and SLA
Stage	01Decision: Lead	02Human action: Qualification	03Human action: Opportunity	04Approval gate: Approval	05System action: Customer creation	06Human action: First order	07Lifecycle state: Active customer
Owner	Marketing	Sales (handoff)	Sales	Sales manager (handoff)	Finance (handoff)	Sales · Finance (handoff)	Commercial ops (handoff)
System	CRM	CRM	CRM	CRM	ERP (authority transfers)	ERP	ERP → CRM (authority transfers)
Decision	Worth sales time?	New organization, or one we know?	Terms within policy?	Commit on these terms?	Can this entity transact?	Within terms and credit?	Which event means ‘active’?
Exception	Existing customer → account team	Probable duplicate → match review	Outside policy → approval	Rejected → back to opportunity	Invalid data → field-level return	Credit hold → finance review	Cancelled → stays ‘ordering’
SLA	Acceptance clock	No clock	No clock	Decision clock · escalates	Validation clock	No clock	No clock

01LeadMarketing · CRM
Owner
Marketing
System
CRM
Decision
Worth sales time?
Exception
Existing customer → account team
SLA
Acceptance clock
02QualificationSales · CRM
Owner
Sales
System
CRM
Decision
New organization, or one we know?
Exception
Probable duplicate → match review
SLA
No clock
03OpportunitySales · CRM
Owner
Sales
System
CRM
Decision
Terms within policy?
Exception
Outside policy → approval
SLA
No clock
04ApprovalSales manager · CRM
Owner
Sales manager
System
CRM
Decision
Commit on these terms?
Exception
Rejected → back to opportunity
SLA
Decision clock · escalates
05Customer creationFinance · ERP
Owner
Finance
System
ERP
Decision
Can this entity transact?
Exception
Invalid data → field-level return
SLA
Validation clock
06First orderSales · Finance · ERP
Owner
Sales · Finance
System
ERP
Decision
Within terms and credit?
Exception
Credit hold → finance review
SLA
No clock
07Active customerCommercial ops · ERP → CRM
Owner
Commercial ops
System
ERP → CRM
Decision
Which event means ‘active’?
Exception
Cancelled → stays ‘ordering’
SLA
No clock

Seven stages. Five layers. One process architecture—and each layer is a design decision.

01What process architecture meansNot a flowchart

Not a flowchart. The operating logic behind the work.

Process architecture is not documenting today’s flow and handing it to a developer. It is deciding how the work should run—and what every person, rule and system is responsible for.

It is not

~~“Draw the current process and automate it.”~~

That automates today’s assumptions—including the wrong ones.

It is

StagesDecide which stages should exist.
Entry & exit criteriaDefine what must be true to enter and leave each one.
OwnershipGive every stage one accountable owner.
Decision rightsSay who decides, and on what evidence.
Failure pathsDesign what happens when things go wrong.
System boundariesDecide which system acts—and which is authoritative.
AutomationChoose what should be automated.
Human judgementKeep what must remain a person’s decision.
MeasurementDefine how the process itself is measured.

InputBad processInputGood technologyOutputFaster bad process

Technology amplifies the operating model it is given. If the process is unclear, automation scales the confusion.

02My approachEight steps · automation last

From observed work to a designed process.

Eight moves that take a process from how it is described to how it should run. Each one produces an artefact the next one depends on—and automation comes last.

01Understand the current state

Step 01 · The question

What actually happens today?

Not what the procedure says should happen.

Identify

Manual work and re-keying
Hidden workarounds
Duplicated effort
Disconnected tools
Approval bottlenecks
Exceptions
Unofficial ownership

ProducesCurrent-state map & assumption register

Second-orderA workaround is evidence of a missing decision or a missing state

Understand the current state
Step 01 · The question
What actually happens today?
Not what the procedure says should happen.
Identify
- Manual work and re-keying
- Hidden workarounds
- Duplicated effort
- Disconnected tools
- Approval bottlenecks
- Exceptions
- Unofficial ownership
ProducesCurrent-state map & assumption register
Second-orderA workaround is evidence of a missing decision or a missing state
Define the outcome
Step 02 · The question
What must the process actually achieve?
Before stages, agree what ‘done’ means—for the business, the customer and the operation.
Define
- Business outcome
- Customer outcome
- Operational outcome
ProducesOutcome statement
Second-orderAn outcome nobody can observe cannot be designed for
Design the lifecycle
Step 03 · The question
Which stages should exist, and what moves work between them?
Stages are states with exit criteria, not departments.
Define
- Stages
- State transitions
- Entry criteria
- Exit criteria
- Decision points
ProducesLifecycle & state model
Second-orderName states by what is true, not by who is working on it
Define ownership
Step 04 · The question
Who owns each stage—and who decides?
For every stage, one accountable owner.
Define
- Accountable owner
- Responsible role
- Decision authority
- Escalation path
ProducesRole model & decision-rights matrix
Second-orderConsulted is not accountable; merging them creates queues with no decision-maker
Design exception paths
Step 05 · The question
What happens when things go wrong?
Every failure needs a detector, an owner and a destination.
What happens when
- Information is missing
- Approval is rejected
- Integration fails
- The SLA expires
- Ownership changes
- Duplicate data exists
ProducesException model
Second-orderDesign the rejection path with the same care as the happy path
Map process to systems
Step 06 · The question
Which part of each step belongs to people, systems, data or automation?
Process boundaries and system boundaries rarely coincide.
Determine
- Human action
- CRM responsibility
- ERP responsibility
- Automation
- Integration
- Data platform
- External systems
ProducesProcess-to-system map
Second-orderMap both boundaries; the gaps between them are where work gets lost
Define controls and measurement
Step 07 · The question
How do we know it works—and who acts when it doesn’t?
Measure the process, not only the commercial outcome.
Define
- SLAs
- Auditability
- KPIs
- Process health
- Exception volume
- Throughput
- Cycle time
ProducesControl, SLA & KPI model
Second-orderAn SLA without a clock start and an owner cannot be monitored
Automate selectively
Step 08 · The question
Is the process coherent enough to automate?
Automate only after the process is coherent.
Decide per step
- Automate: deterministic, frequent, reversible
- Assist: prepare the decision for a person
- Keep human: judgement and accountability
ProducesAutomation boundary
Second-orderDo not automate ambiguity

03Typical problemsSymptoms, and what is usually missing

The symptoms arrive as system requests.

“The CRM should enforce this.” “We need another approval.” Underneath, something in the process was never decided.

Stages exist, but nobody agrees where one ends and the next begins.
Usually missingEntry and exit criteria
Several departments own the same decision.
Usually missingDecision rights
Approvals exist without clear decision criteria.
Usually missingA decision model behind the approval
Rejected cases have no explicit return path, and nobody owns exceptions.
Usually missingException paths with owners
CRM stages do not match the real operating process.
Usually missingA process-to-system map
Work jumps between CRM, ERP, email, spreadsheets and chat.
Usually missingOne system of action per step
SLAs are measured, but not owned.
Usually missingA clock owner and an escalation path
Subsidiaries run different versions of the same global process.
Usually missingA controlled variation model

04What I designTangible artefacts

Artefacts the organization can run, govern and configure from.

Each one answers a question that has to be settled before a system is configured.

StructureHow the work is shaped

End-to-end process architectureHow does work move from trigger to outcome?
Lifecycle & state-transition modelWhich states exist, and what moves a record between them?
Role & ownership modelWho owns each stage, and where does accountability transfer?
Decision-rights matrixWho decides, who is consulted, who is informed?

ControlHow it stays reliable

Approval architectureWhat is approved, by whom, on which evidence?
Exception modelWhere does work go when it fails, and who owns it?
SLA modelWhen does each clock start and stop, and who owns it?
Process governance modelWho may change stages, rules and thresholds?

ConnectionHow it meets systems and data

Process-to-system mapWhich system acts at each step—and which is authoritative?
Automation boundaryWhat runs automatically, what is assisted, what stays human?
KPI ownership modelWhich measures show process health, and who acts on them?

05Process → systemsPeople · systems · data · automation

Every stage, mapped to who and what runs it.

Pick a stage of the same lifecycle. The board shows what a system designer needs from the process—including where the ERP is deliberately not involved yet.

Stage 04 · mapped

Approval

Commit on these terms?

One stage, four answers. If one of them is blank, the stage is not ready to be configured.

People

Owner: Sales manager
Human action: Review the commercial conditions

Systems

CRM: Stores the approval state, evidence and policy version
ERP: Not yet involved

Data

Information the decision needs

Margin
Payment terms
Customer information

Automation

Notify the approver · SLA monitoring · escalation

Open the full operating modelSwimlane, stage anatomy, controls, exceptions and automation fit for the whole lifecycle

MarketingDemand & qualification

SalesRelationship & opportunity

Commercial mgmtTerms, approval & lifecycle policy

FinanceLegal, tax & credit validation

CRMSystem of action — commercial lifecycle

ERPSystem of record — legal customer

Lane / stage

Data authority

Marketing → Sales

Commercial → Finance

Legal identity: CRM → ERP

Lead scored & routedAccount · prospectParty index lookupOpportunity & quoteApproval & audit recordValidation pendingValidation rulesNumber receivedOrder status visibleSales orderLifecycle · activeInvoice event

Human actionSystem actionDecisionApproval gateLifecycle stateSystem touchHandoffAuthority transferException return

Stage anatomy · 04 / 08

Commercial approval

Approval gateAssist — person confirms

Trigger
Proposal ready and a first order expected
Decision
Should we commit to this customer on these terms?
Owner
Sales manager — delegable within recorded limits
System action
CRM routes the request by policy and records the evidence, the decision and the policy version
Data state
Account · Commercially approved
Next stage
05 Financial validation

1. Trigger
  Proposal ready and a first order expected
2. Decision
  Should we commit to this customer on these terms?
3. Owner
  Sales manager — delegable within recorded limits
4. System action
  CRM routes the request by policy and records the evidence, the decision and the policy version
5. Data state
  Account · Commercially approved
6. Next stage
  05 Financial validation
Information required
- Terms and deviation from policy
- Margin band
- Strategic rationale
- Known risk flags
Controls & SLA
- Approval limits by role; delegation recorded with dates
- No one approves their own proposal
- Decision stored with the policy version applied
- SLA Clock starts on submission. Reminder, then escalation one level up. Silence never approves.
Exceptions
- Rejected — Returns to Opportunity with a reason codeDetected: Approver · Owner: Sales · Returns to 03 Opportunity
- No response within SLA — Escalates to the next approval levelDetected: SLA clock · Owner: Commercial management · Escalates one level
Automation suitability
Assist — person confirms. Within-policy deals can be approved by rule and audited. Deviations need a named approver.

06Automation boundaryShould, not could

What should be automated?

Not “what can technically be automated?” Every step sits somewhere between a person deciding and a system running it—and the position is a design decision.

Human
Judgement, accountability or consequences that are hard to reverse
- Commercial negotiation
- Approving a deviation from policy
- Confirming a probable duplicate
Assisted
A person decides; the system prepares the decision
- Recommend the next action
- Assemble the approval evidence
- Propose account matches
Automated
Deterministic, frequent and reversible
- Routing and notifications
- Pricing and policy checks
- SLA reminders and escalation
Orchestrated
Stateful and cross-system: needs idempotency, recovery and an owner
- Multi-system lifecycle transitions
- Customer creation across CRM and ERP
- Reconciliation after an unknown outcome

How automation is designed

07Process healthDefinitions, not values

Measure the process, not only the outcome.

Commercial KPIs say whether the business grew. Process KPIs say whether the operation works: where work waits, fails, returns or needs a person.

Flow

Cycle time
Trigger to outcome — median and 90th percentile
End to end
Stage ageing
Time spent waiting in each stage
Between stages
Throughput
Work completed per period, by path
At the outcome

Quality

Rejection rate
Decisions that say ‘no’, by reason
At decision gates
Rework
Work sent back to an earlier stage
On return paths
Exception rate
Work leaving the happy path, by type
Where exceptions start

Control & automation

SLA breaches
Clocks that expired, by owner
Where clocks run
Manual intervention rate
Cases a person had to touch outside the design
Assisted stages
Automation coverage
Steps completed without a person, as designed
Automated stages

08Reference casesFictional & composite

Six processes, six architectural dimensions.

Synthetic global B2B scenarios built from recurring patterns. Each case opens into its own page with the swimlane, stage anatomy, decision rights, exceptions and KPIs.

Case 01Selected workLifecycle, identity & approval
Designing a global lead-to-customer operating model
Subsidiaries create customers in different ways, and nobody agrees when a prospect becomes a customer.
8 stages · 4 roles · 2 systems
CRMERPIntegrationConnects toSystems & CRM Architecture Digital Operating Model
Case 02Approval model & revision rules
Designing a quote-to-order process with clear ownership
Quotes change after approval, and the ERP rejects orders the customer has already accepted.
7 stages · 4 roles · 2 systems
CRMPricingERPIntegrationConnects toSystems & CRM Architecture Automation
Case 03Analytics → process → action
Designing a commercial performance recovery process
Underperforming accounts are visible every month—and nothing is obliged to happen next.
7 stages · 3 roles · 2 systems
Data platformCRMPlanningConnects toRevenue Operations Data & Integrations
Case 04Process first → AI second
Designing an RFQ intake process before introducing AI
An AI agent is proposed for RFQs before anyone has defined the process it would run.
8 stages · 2 roles · 2 systems
MailboxAI agentCRMProduct catalogueConnects toAI & Agentic Workflows Automation
Case 05Core process vs. controlled variation
Standardizing a global commercial process without breaking local operations
A global process is mandated; subsidiaries comply on paper and work around it in practice.
7 stages · 3 roles · 3 systems
Global CRM templateLocal ERPsVariation registerConnects toDigital Operating Model Change & Adoption
Case 06Entry point vs. process
Designing an inbound lead process beyond form submission
Every web form creates a CRM lead—and nobody owns what happens next.
8 stages · 3 roles · 2 systems
WebsiteCRMMarketing automationConnects toRevenue Operations Systems & CRM Architecture

09Questions that change the designThe second layer

Every request has a second layer.

The visible request is where the design starts, not where it ends.

Start from a request

Visible requirement

“Add an approval.”

First layer

~~Insert an approval step before the order.~~

That is a step. It is not yet a decision.

4 of 7 questions surfaced

Second layer — what the request leaves unsaid

An approval without a named decision becomes a formality people learn to click through.

10Connected capabilitiesWhere process design leads