Operating model · 5 min read
Your operating model is the part of the service customers feel most and see least.
Customers never ask to see your operating model. They feel it anyway: every time they’re transferred, asked to repeat themselves or told “that’s a different department”.
You know where you need to go but get lost. There are so many ways to get there.
In a large service model redesign for a business bank, the early journey maps looked good. As prototyping started, the same questions kept coming back. Who shows up for the client? Through which channel? With what authority? What happens at the handover?
Our lesson from that work: journey maps alone aren’t enough. If the front stage is left vague, the concept looks good in a prototype and fails in delivery.
When we assessed an ERP change at a mine, users had built their own shortcut: Excel and a reporting connector instead of entering data directly into the system. The official process was impractical, so they designed a better one.
In the same work, foremen had no direct system access, so planners acted as go-betweens. A single access decision had created a manual handover loop that nobody had designed on purpose.
Workarounds are real workflows. Design for them, don’t delete them.
Most service failures happen between teams, not inside them. Before you redesign a screen or a role, answer four questions for every handover:
One client put it well at the start of their redesign: “blank page thinking instead of trying to sticky tape stuff together.” The teams that get the most value treat roles, handovers and capacity as design material, not as fixed constraints to design around.
The Promise-to-Proof Diagnostic shows where your promise holds, where it breaks and what to change first.
