An operating model is a set of written answers about who decides what, and most businesses discover they have never written them down when a decision takes three weeks and five minutes of work.
This guide covers how to time one recurring decision honestly, why moving authority down a level usually beats any system on the roadmap, and what has to travel with the decision once it is made. None of this requires a new system to start, which is why it is worth doing before anybody writes a requirements document for one.
Key takeaways
- Time one decision, signal to response: Most of the elapsed time sits at an authority boundary rather than in the work itself.
- Move one decision down a level: A clear limit on what may be settled changes elapsed time more than any system on the roadmap.
- Check whether the record travels: If the next team cannot see what was decided without being told, that gap is the integration requirement.
- Review the rule, not just the case: An operating model with no review point hardens into procedure, and procedure is what people work around.
Look for the business signal behind the technology
The signal that the operating model is the problem is a decision that takes three weeks and five minutes of actual work. When the delay is almost entirely waiting for authority, no system on the roadmap will shorten it, because the system is not what is slow.
Not every delay should be removed. Some decisions are slow because they are consequential and several people genuinely need to look. The distinction is whether the waiting is deliberate or simply the result of nobody having decided who may decide.
Take one recurring decision and record when the signal arrived, who it reached, how long it waited and when the customer felt the result. Most of the elapsed time will sit at one boundary, and that boundary is the finding.
Use four lenses to understand the opportunity
Customer Signal
Work out what tells you something has changed outside the business, how it reaches you, and how late it usually is. Most operating models are slow because the signal arrives through a monthly report rather than through the people who saw it happen.
Team Decision
Decide who is allowed to respond without asking and where the authority currently stops. Moving one decision down a level, with a clear limit, usually changes the elapsed time more than any system on the roadmap.
Shared System
Check whether the next team can see what was decided without being told. If the answer is no, that gap is your integration requirement, stated in terms of one real decision rather than as a diagram nobody can cost.
Outcome Review
Set the point at which you check whether the decision was right and what happens to the rule if it was not. An operating model without that step hardens into procedure, and procedure is what people work around.
Assess the current state without buying software first
Time three instances of the same decision rather than describing the process. Descriptions produce the version everybody agrees on, and the timings produce the version that happens, and the gap between them is the work.
Decide what useful measurement looks like
Measure elapsed time from signal to response. That single figure is what an operating model exists to shorten, and it is visible to the customer in a way that internal throughput measures are not.
Add a quality check so speed does not simply mean deciding with less information. A faster decision that is reversed twice as often has moved the cost rather than removed it.
When software is likely to help
Systems help once the responsibilities are clear: routing work to the right person, making the decision visible to the next team, recording what was decided and why. All three are mechanical once somebody has settled who decides what.
Software applied before that produces a faster route to the same bottleneck. A workflow tool that escalates everything to the one person who was already the constraint has automated the queue in front of them.
For a worked example of connecting customer-facing and internal systems, see E-Commerce App Development: A Practical Planning Guide.
Start with a bounded improvement
Delegate one decision a level down with a written limit on what may be settled, and watch for a month. The limit matters more than the delegation; an unbounded one is withdrawn after the first uncomfortable case and the experiment is over. Tell the level above what the limit is at the same time, since the delegation collapses the first time somebody escalates a case that was inside the boundary.
Build a measurement map before a dashboard
A dashboard is a presentation layer, so begin with the chain of meaning underneath it. For a digital operating model, write the business question at the top of a page. Under it, list the decision owner, the action available, and the evidence required. Only then identify measures related to customer signal, team decision, shared system, and outcome review.
The measurement map is useful even if the next step is not software. It clarifies whether the business can connect roles, workflows, systems, data, and management decisions in one practical model with existing information or whether a product must improve capture, quality, connection, and response.
Risks to make visible
| Lens | Common risk | Early response |
|---|---|---|
| Customer Signal | The signal arrives through a monthly report | Find out how the business first hears, and how late that usually is. |
| Team Decision | Authority is unclear rather than absent | Write the limit down, including what must still come up, and tell the level above. |
| Shared System | The decision is not visible to the next team | Check whether they can see the outcome without being told. |
| Outcome Review | Nobody checks whether it was right | Set the review point and say what happens to the rule if the answer is no. |
A 30-day validation plan: Digital operating model
Days 1 to 5: time one decision from signal to response. Pick a recurring decision the business already finds slow, such as approving an exception or responding to a customer complaint. Record when the signal arrived, who it reached, how long it waited for authority, and when the customer felt the result. The waiting at the authority boundary is usually most of the total. Pick one that crosses two teams, because a decision inside a single team is usually already as fast as the people in it want it to be.
Days 6 to 15: move the decision down one level. Give the team closest to the work the authority to decide it, with a written limit on what they may settle and what must still come up. Watch what they decide for two weeks. The limit matters more than the delegation, because an unbounded one gets withdrawn after the first uncomfortable case. Tell the level above what the limit is, since the delegation collapses the first time somebody escalates a case that was within the boundary.
Days 16 to 30: check whether the record travels. Find out whether the next team can see what was decided without being told. If they cannot, that gap is the shared system requirement, stated in terms of one real decision rather than as an integration diagram nobody can cost. Check it with the team that receives the work rather than the one that sends it, as only the receiving side knows what they had to ask for.
A practical worksheet: Digital operating model
An operating model is a set of answers about who decides what, written down. Complete these rows for one recurring decision your business already finds slow.
| Decision area | What to record |
|---|---|
| Customer Signal | What tells you something has changed outside the business, how it reaches you, and how late it usually is |
| Team Decision | Who is allowed to respond without asking, and where the authority currently stops |
| Shared System | Where the decision is recorded, and whether the next team can see it without being told |
| Outcome Review | When you check whether the decision was right, and what happens to the rule if it was not |
| Measurement | Elapsed time from signal to response, which is the figure an operating model exists to shorten |
Most of the delay sits at the authority boundary rather than in the work. Moving one decision down a level, with a clear limit on what may be decided, usually changes the elapsed time more than any system in the list.
Related guides
- The next practical step is described in Digital Transformation Roadmap: A 7-Step Business Guide.
- Much of this depends on what is in Paperless Workflow: How to Digitize Paper-Based Processes.
If How to Build a Digital Operating Model for Your Business is the start of a roadmap someone has to own, Discuss Your Digital Roadmap.
Ali Boran Gazel