Why your operating model document is already out of date
When did anyone last open your operating model document for a reason other than an audit, a partner's due diligence request or a board pack? If the honest answer is some time last year, it is describing an organization that has moved on without it.
The document was probably accurate when it was signed off. Since then a team lead left and her queues were split between two people. A KYC vendor was replaced, and the new one sends escalations to a shared mailbox that appears nowhere in the RACI. Out-of-hours cover changed after a reorganization. None of those felt big enough to reopen a forty-page document, and together they mean it no longer tells anyone who does what.
That matters at the moments people reach for it: a new joiner learning who approves what, or a sponsor bank asking you to show who owns a control. A stale document is worse than no document, because people act on it.
Why it drifts
Most operating model documents are written as project deliverables. A transformation team or an advisory firm produces one, a steering group approves it, and the project closes. We have written some of these ourselves, so we say this with sympathy: the document ends up with an author who has moved on and no owner who is expected to change it.
The second reason is that operations change in small steps. Nobody reorganizes a payments operation in a single move. Someone shifts one queue, adds one partner, asks one analyst to cover a second role for a month that turns into a year. Each step is too small to justify a document update, and no mechanism adds them up. Six months of small steps is a different operation.
The parts worth keeping current
A RACI that matches reality gets built from observed work. Look at who actually approves refunds above the manual limit in the system's audit log, who replies on the thread when a settlement file is late, who the sponsor bank's operations desk calls first. Write rows at the level an analyst would recognize, such as "release a held merchant payout" or "change a cut-off time in the payment hub". A row called "manage customer operations" tells nobody anything. Give each row one accountable role.
If a row in your RACI has two accountable names, you have found the subject of a future incident review.
The service catalog is the list of what the operations team delivers and to whom: the requests it receives, the channel they arrive through, the expected turnaround and the owner. It earns its place by catching work that never made it onto an org chart. The monthly safeguarding report one analyst builds by hand, the weekly file the sponsor bank expects on Sunday evening, the extra merchant checks the sales team asks for as a favor. Work like that is invisible in headcount planning until the person doing it takes leave.
Decision rights are the part most teams write last and need most. Who can pause a merchant, extend a partner's cut-off, release a large payment held by fraud rules, declare an incident, and up to what threshold. Write the out-of-hours version explicitly. When money moves in seconds around the clock, the 2am table matters as much as the daytime one, and if your shifts run across time zones the decision rights have to travel with the handover.
How to keep it alive
Keep it short enough to review. Our rule of thumb is that an operating model nobody can read in half an hour will not be reviewed by anybody. Store it where the team already works, next to the runbooks, with a named owner and a change log at the top so people can see what moved since they last looked.
Then split the review by cadence. The service catalog is a light monthly check by the operations lead: anything new being asked for, anything nobody does anymore, any turnaround that has drifted. The RACI and the decision rights go quarterly, and again after any incident where someone was unsure whether they could decide. The organizational picture at the front changes rarely, so leave it alone between structural changes.
Name the owner at the top of the first page, and make it someone who runs the operation. A document owned by a project office describes the operation a project office can see, which is the version presented in steering meetings. The operations lead hears about the shared mailbox and the analyst covering two roles within a week of it happening.
There is a quick test for whether the document is current. Pick five recurring decisions, ask three people separately who makes each one, and compare the answers. If they differ, the document is out of date whatever its version number says. Run the test a few weeks before the annual review, while there is still time to fix what it finds.
A full rewrite is a bigger job and should have a trigger. We would start one when:
- a new product, market or license brings a new regulator or a new partner into the picture
- the sponsor bank, processor or another partner whose contract defines your duties changes
- a quarterly review changes more rows than it leaves alone
- the team has grown or turned over enough that most names in the RACI are new
- a function moves to another location, another entity or an outsourcer
Between those, patching is better than rewriting. A document with a visible change history and slightly uneven formatting is a sign that someone maintains it.
If you do one thing this quarter, run the five-decision test. It takes an afternoon, the answers are usually uncomfortable, and they point at the section to fix first.
Discuss your operations
