The documented process is never the real process

Every automation project starts the same way: someone walks me through a process. They're helpful, they know the work, and the description is clear. Step one, step two, step three.

The description is also, more often than not, wrong. Not because anyone is lying - because people describe the job as it was designed, not as it's lived. And a system built from the designed version automates a workflow that nobody actually runs.

The clean version and the real one

Take something as ordinary as lead intake. The clean version: "a lead comes in, we enter it in the CRM, a salesperson follows up."

The real version, once you sit next to the person doing it: leads come from two portals, the website form, a shared inbox and WhatsApp. The portals send duplicates when a listing is updated, so those get recognized by eye and skipped. One portal sends the phone number but no email; those get a different follow-up. Inquiries mentioning a specific project go straight to one particular salesperson, because he asked for them once, two years ago. Anything arriving after 17:00 on Friday waits until Monday - except when it looks urgent, and "looks urgent" is a feeling, not a rule. And two or three times a week something arrives that fits no pattern at all, gets forwarded to a colleague with "you know what to do with this?", and disappears into a thread.

None of that is in the SOP. All of it is the job.

It's not one workflow either. The second step - "we enter it in the CRM" - hides its own iceberg: which fields actually get filled, which get re-keyed from the email because copy-paste mangles them, which dropdown value everyone picks because the correct one doesn't exist. The deeper you go, the more of the process turns out to be exceptions handled from memory.

Why asking doesn't get you there

The obvious fix is to ask better questions. It doesn't work - not fully.

Book a one-hour meeting and you get the clean version, because that's the version that fits in an hour and the version people carry in their heads as "the process." The exceptions don't come up, and not because anyone hides them. The person handling them doesn't experience them as exceptions. Recognizing a duplicate portal lead at a glance isn't a rule they can recite; it's a reflex they've had for years. They will not think to tell you, the same way you wouldn't think to explain how you decide which emails to answer first.

Try it on yourself: write down every exception in your own job. Every judgment call you made this week that isn't written anywhere. You'll give up before lunch - and you're the person who understands your job best.

That knowledge usually lives with one or two specific people, unwritten and unrequested. The only reliable way to get it out is time: sit with them while they work. In a meeting, you hear about the job. Next to their desk for a day, you watch the job happen - including the moment something goes wrong that no document mentions, and they fix it on autopilot.

What happens when you skip this

A system gets built from the clean version. It demos well, because demos follow the clean path. Then it meets reality: the duplicate leads it dutifully creates, the phone-only leads it can't process, the urgent Friday inquiry it happily queues until Monday.

The team starts working around it. First the exceptions get handled manually "for now." Then someone keeps a parallel spreadsheet "just to be safe." Within a few months the old shadow process is back, running alongside the automation, and the verdict internally is "the automation doesn't work." The software was fine. It just automated a fiction.

This is the quiet reason behind so many failed AI pilots. The model was never the problem. The input was a process description that had been polished for a slide, handed to people who built exactly what it said.

How to dig out the real process

What works, in practice:

• Observe, don't just interview. Meetings produce the designed process. Sitting with people while they work produces the real one. The longer you sit, the more exceptions you see happen live.
• Get into the systems. The CRM, the ERP, the shared inbox. The data tells you things nobody says out loud - fields that are always empty, statuses nobody uses, the workaround column someone added in 2021.
• Treat exceptions as the deliverable. The happy path takes an afternoon to map. The exception list is the actual asset, because the exceptions are what the system will meet in production.
• Expect the knowledge to be spread out. It's rarely one person. Three people "do the same thing" and handle the edge cases three different ways. All three versions matter.

This stage is where most of the time in a project should go, and it's the part that looks least like progress - no code, no demo, just questions and notes. It's also the difference between software that fits your operation and software your team quietly routes around. It's the first thing I do on every project of this kind, before any tooling gets discussed.

If you're planning to automate a workflow and the process description fits on one page: that page is the clean version. Finding the real one is the work - and it's work I can help with.