Most operations advice asks someone to describe how the work runs, then prescribes a fix against that description. The gap between what people say happens and what the records show is where most operational decisions get made wrong — and that gap is a finding, not an error to reconcile away.
Describing intent is not the same skill as reporting behavior, and almost everyone who's asked "how does this work?" answers with the first one. Not because they're hiding anything — because that's genuinely what a single conversation is good for. It tells you how the process was designed, or how the person answering wishes it ran, or how it ran the one time it went well enough to remember clearly. It rarely tells you what happened the last twenty times, including the ordinary ones nobody thought to mention.
This page is the deep dive on the method we use to close that gap before building anything on top of it. It gets a short section on the homepage and one paragraph on the methodology page; here's the version with enough detail that you can run a rough copy of it yourself, on one process, before you spend anything automating a process nobody has actually checked.
Four independent readings, not one interview
The mistake most operational assessments make is treating a single conversation as data. One conversation is one person's account, filtered through what they remember, what they think you want to hear, and how long they've been doing the job. The fix isn't a better interview script. It's four separate readings of the same process, gathered independently, then compared against each other.
01 Stated
What the team says about how the work runs, from the owner down to the newest hire. Ask the same questions, in the same order, of at least two or three people who touch the process at different levels — the person who designed it, the person who's run it longest, and someone who started recently enough that they haven't yet learned where the shortcuts are. Write down each answer close to verbatim. Don't smooth the versions into one story yet; the places they disagree with each other are data too, and you'll want them later.
On its own, stated is the least reliable of the four and the easiest one to gather — which is exactly why most process documentation stops here and calls itself done.
02 Observed
What's actually in the systems the work runs through — boards, ticket queues, shared files, ledgers, inboxes, whatever stack is already in place. Not a summary of the workflow someone configured once; the actual record of what happened. Pull the last fifteen or twenty real instances of the process — the last twenty tickets, jobs, invoices, whatever the unit is — and look at what fields actually got filled in, what order the steps actually happened in, and who actually touched each one. A configured workflow describes intent. A ticket history describes behavior, and those two things drift apart the moment the process meets its first exception.
03 Documentary
The artifacts the business has already produced about the process — org charts, SOPs, contracts, financial records, onboarding material. These are useful for a reason that has almost nothing to do with whether their content is still accurate: their age and their gaps tell you where attention has and hasn't gone. An SOP nobody has opened in two years is itself a finding, independent of what it says. Check the last-modified date before you check the content.
04 Operational
What actually happens once the process is running, captured continuously rather than reconstructed afterward from memory. This is the hardest of the four to gather without some instrumentation in place — a single day of direct observation, or a week of logging every deviation from the stated version, gets you a rough copy. It's also the one that resolves most disagreements between the other three, because it's the only source that isn't being reported by a person after the fact.
The gap is the finding
Lay the four readings side by side for the same process and they will not agree. That's not a data-quality problem to clear up before the real work starts — it is the real work. Where stated and operational disagree is where the business is quietly organized around a workaround nobody has said out loud, and it's usually the reason the operation feels harder to run than the documentation says it should be.
One shape this often takes, in the abstract: the stated version of a scheduling process names one person as the approver. The observed version — the actual assignment history in whatever system tracks it — shows someone else has been making that call for months, because the named approver usually isn't reachable at the moment the decision has to happen. Neither account is lying. The org chart is wrong about who decides, and the person actually deciding has no formal standing to be doing it. That's not a fact you get by asking "how does scheduling work?" It's a fact you get by checking who scheduling actually happens through.
Once you can see the gap, you have two things you didn't have before: a specific, checkable claim about who or what is actually driving the process, and a reason the fix has to change something more than the org chart.
A version you can run without us
The full version compares all four sources across every process that matters in the business, cross-checked and written up as a single reviewed report. You don't need the full version to get most of the value. A narrower one, run against a single process that already feels harder than it should, takes about an afternoon:
- Pick one process, not the whole operation — something with a clear start and end. Onboarding a client, dispatching a job, closing the books for the month.
- Write down the stated version from at least two people at different levels: the person who owns the process and the person who actually executes it day to day. Same questions, same order, close to verbatim.
- Pull the last 15–20 real instances from whatever system the process actually runs in. Not the workflow diagram — the ticket history, the file timestamps, the ledger entries.
- Find the document that's supposed to govern the process — the SOP, the checklist, the org-chart entry — and note when it was last touched.
- Watch or log one full real instance of the process happening, start to finish, without telling anyone in advance what they're "supposed" to do.
- Lay all four next to each other for that one process, and write down every place they disagree. That list is the finding — not a problem to explain away before you move on.
Run this once and you'll usually turn up at least one gap worth acting on. Run it across the handful of processes that actually carry the business, and you have the observed-reality half of an operating picture — the harder half to fake, and the half most automation projects skip straight past.
Where this fits
Inside a Mochlos engagement, this is step one of the five-step loop — see Document, Build, Govern, Audit, Improve for how the other four steps build on what these four readings turn up. If you'd rather have someone else run it — pulling the systems, holding the sessions, and writing up the comparison — that's the shape of the Operational Reality Snapshot: its observed-reality report and gap map are built from exactly this method, applied to your own systems instead of a hypothetical one.