Workflow · Aug 15, 2026 · 5 min read
Design the workflow around the decision, not the data
A report that made 2,800 requests a week to answer one question a day. Start from what the operator decides, then work backwards.
An agency client’s reporting flow was making about 2,800 requests a week to a call-tracking API. The report it fed was read once a day. An empty client key in the data could break the whole run.
Nothing about this was unusual. The workflow had been built from the data outward: pull everything, store everything, then build a view. It worked until the volume and the edge cases caught up with it.
Start from the decision
The question I now ask before building any operational workflow is: what does the operator decide when they look at this, and how often? For the scorecard, the answer was a weekly conversation per client about whether performance was on target. Everything else is supporting detail.
- 1Fetch at the cadence of the decision, not the cadence of the data source.
- 2Keep unknown values unknown. A blank is more honest than a zero.
- 3Keep modeled numbers visibly separate from measured ones. Qualified calls are not revenue.
- 4Fail loudly on bad input. An empty key should stop one client’s row, not the whole report.
“A workflow is a tool for a person making a decision. If you cannot name the decision, you are not ready to build it.”
This is also why I stay close to the people who will use the system. The decision is never written down anywhere. You find it by sitting with them.