An approval step is not a decision model
Adding a step is easy. Defining the decision, its evidence, its owner and what happens after ‘no’ is the actual design work.
Independently created. Contains no employer or client implementation detail, internal names or figures.
00The thesis
Most approval steps are added to reassure someone, not to make a decision. That is why they slow the process without reducing risk.
01Argument
Name the decision
‘Approve customer’ usually hides several decisions: whether to commit commercially, whether the legal entity can transact, whether the credit exposure is acceptable. Each has a different owner and needs different evidence. Merged into one step, every approver signs for things they cannot judge.
02Argument
Design the ‘no’ before the ‘yes’
A rejection should carry a reason code, return the work to the stage that can fix it, and leave the record in a state that is true. When rejection has no designed path, it moves into email—and the process stops being observable.
03Argument
Give silence a destination
Every approval needs an SLA with a clock start, a clock stop and an owner—and an explicit rule for what happens when nobody responds. Approving on timeout is a policy decision; so is escalation. Neither should happen by accident.
What part of the problem is the organization asking technology to conceal?
04Where the argument is applied
Process Architecture- Process case / 02Designing a quote-to-order process with clear ownershipBinding approvals to quote versions, moving ERP validation forward and giving rejected orders an owner.
- Architecture case / 002Designing a global lead-to-customer operating modelA process-first case for a fictional global B2B company: stages, decision rights, approvals, exceptions and measurement—designed before any system is configured.