An operating model is the answer to a simple question: how does this business turn a customer’s need into a delivered outcome, and who does what along the way? For most of business history that answer lived in people. It was written in job descriptions and handbooks, taught by whoever had been there longest, and enforced by managers. Changing it meant changing habits, which is slow, and structures, which is slower.
That is shifting. In a business that runs on its own systems, the operating model is not described by the software. It is the software. The record defines what the business knows. The workflow defines what happens next. The rules define who decides. Change the system and the operating model changes with it, the same day, for everyone.
What this makes possible
Models that can be tested. A change to how enquiries are routed, or how jobs are prioritised, used to be a reorganisation. Now it can be a change to a rule, tried for a month, measured, and kept or reversed. The operating model becomes something a business iterates on, rather than something it endures.
Roles defined by judgment. When the system carries the routine transitions, the roles that remain are the ones that need a person: deciding, selling, designing, caring. Job descriptions shrink to the parts that matter, and the parts that were really “keep the tools in sync” disappear.
Small teams with wide reach. A model where the system handles the coordination lets a team of six operate across functions that would once have needed six departments. Not because anyone works harder, but because the handoffs between functions are automatic.
Agents inside the model. Models that read, draft and route can now be given a defined place in the operation, with clear limits: triage the inbox, draft the follow-up, flag the exception. They become part of the operating model, doing bounded work under human direction, rather than a novelty bolted onto it.
When the operating model is software, changing how the business works is an edit, not a reorganisation.
What a designed operating model contains
It is a short list, and each item maps onto something concrete in the system.
- The record. What the business knows about each customer, job and commitment, in one place.
- The transitions. The named moments where work moves from one stage to the next, and what triggers each.
- The rules. Who or what decides at each transition, and within what limits.
- The queues. Where work that needs a human lands, in what order, with what attached.
- The readouts. The few numbers that tell the owner the true state of the business, read from the system rather than assembled.
Write those down and you have an operating model. Build them and you have a business that runs on it.
Notice what is absent from the list. There is no org chart, no set of departments, no reporting line. Those can still exist, but they are no longer the description of how the business works. They are one arrangement of the people who work inside a system that already knows what happens next. When the arrangement changes, the system does not have to, which is why small businesses built this way reorganise so rarely and so painlessly.
The risk worth naming
A model encoded in software is only as good as the thinking that went into it. A bad process automated is a bad process that now runs faster and cannot be argued with. The discipline is to design the model as a business decision first, in plain language, with the people who do the work, and only then to build it. The system should express the business’s judgment, not replace the step where the judgment was formed.
Why this is new
Businesses have always had operating models. What is new is that a company of ordinary size can now own the system its model runs on, change it at will, and give parts of it to software that reads and reasons. The org chart is no longer the main description of how the business works. The system is. And unlike the org chart, the system can be improved every week by the people who actually run the business.