Somebody has asked you for an operating model. Nobody has told you what one is, and the examples you can find are either a diagram with no words or a hundred pages nobody has read since it was signed off.
An operating model answers one question: how does this service actually run, and who does what when it does not? Everything that answers that belongs in it. Everything else is padding.
The parts that earn their place
What the service is, in a sentence somebody outside it would recognise. Not "the provision of end user compute capability". Something closer to "the laptops, the phones and the software people need to do their jobs, and getting them working again when they stop". If the people doing the work do not recognise their own jobs in the description, nothing below it will be true either.
What it includes, and what it does not. The second half is the one that gets skipped and the one that settles arguments. A service with no stated edge absorbs every request that arrives near it.
Who owns it. One named role, not a committee. The person who decides what the service does next and answers for it when it fails.
Who does the work. Teams, suppliers, and the split between them. Where a supplier is involved, which decisions are theirs and which are yours.
The handovers. Almost every failure in a service happens at a boundary: between teams, between you and a supplier, between the day shift and whoever is on call. Name every handover and say what crosses it. A handover nobody has written down is a handover that works only while the people who invented it are still there.
Escalation that works at three in the morning. Not a diagram of who reports to whom. A list of what to do, who to ring, and what authority that person has when they answer.
What people can reasonably expect. How quickly things happen, when the service is available, what happens when it is not. Written as a promise the people delivering it believe they can keep, and measured by somebody. A service level nobody measures is a wish.
How it changes. Who may ask for something new, who decides, and how long that takes.
The parts that do not belong
Tooling. Which ticket system you use is an implementation detail. An operating model that names a product in every section becomes obsolete the day you change the product, and people stop trusting the rest of it.
Org charts. Roles belong in it. Names and reporting lines do not: they change every reorganisation, and a document that goes stale twice a year is a document nobody opens.
Anything aspirational. If the model describes how you would like it to work, it is a plan, not a model. Write what happens today, then write what you want to change and when. The gap between them is the useful part and it disappears the moment you write only the second one.
How to tell when it is finished
Give it to somebody who does the work and ask them to find themselves in it. Then give it to somebody who is on call and ask what they would do at three in the morning. Then give it to whoever pays for the service and ask them what they are getting.
If all three can answer from the document, it is finished. If any of them says "it depends who you ask", you have found the part that is missing.
The most common failure
Most operating models are written for the person who asked for one, as evidence that the work was done. They are accurate, complete, and never opened again.
The test is not whether it passes review. It is whether somebody reaches for it in the middle of an incident, or when a supplier says something is not their job. If it is not useful on the worst day, it was decoration.
This is part of what we do under Service design. See the services, or tell us what is not working.