Request
A customer asks for a renewal exception. The account lead records the request, rationale, deadline, and commercial impact.
CASE 03 / DECISION OWNERSHIP
WORKFLOW DESIGN · ROLE CLARITYTracing a request
Tracing a request
to a real decision.
When several requests are moving at once, knowing something is pending is not enough. The record should show what decision is needed, whose input is complete, who has authority to approve it, and who carries it through to completion.
Build the Decision Path Brief ↓ScenarioFictional renewal exception
QuestionWho provides information, decides, and owns what happens next?
OutputInteractive Decision Path Brief
THE DECISION PATH
Five moments are shown separately so input is not mistaken for approval, and approval is not mistaken for completed work.
Input
Finance checks margin, Legal reviews terms, and Customer Success adds relationship context—without implying that any of them has approved it.
Authority
The sales director is identified as the one person authorized to approve or decline the exception.
Execution
The assigned operational owner carries out the approved change. A recorded decision is not treated as completed work.
Closure
The request records who completed the work, when it was finished, what was communicated, and whether anything remains open.
THINGS WORTH CONSIDERING
Approval is only one part of the path.
- Who is most affected if approval is delayed?
- Who records the decision?
- Who actually completes the task?
- How is completion confirmed, communicated, and closed?
THE AMBIGUITY
The request has input, but no recorded decision.
Finance validated the numbers, Legal reviewed the language, and Customer Success explained the relationship. Those inputs define the request, but they do not show whether it was approved or who owns the next action.
A fictional operating scenario designed to explore decision ownership. It models roles and handoffs without presenting invented performance results.