An hour, maybe two.
Clean execution, no errors. A couple of fixes and everyone is happy.
You think: great client, clean processes. This is what it is supposed to feel like.
The next task sounds just as simple.
Different object, same energy. You walk in easy.
Until you have spent half a week just trying to understand how their systems talk to each other.
Nobody knows which system is responsible for what.
Nick knew, apparently. But Nick was let go, and no one is in touch.
The keys to that other system? Tom has them.
Better not call Tom. He left badly.
And who set this up in the first place?
Mary.
Mary is on maternity leave.
How does any of this actually work?
“It works. We want to keep it working. So… be careful.”
And now you are moving through the dark.
On one side: errors from one system.
On the other: a black box that processes something, somehow, set up wrong, but fixing it means rebuilding the entire environment around it.
Nobody is ready for that.
So you run from room to room.
And every room has more questions than the last.
This is what real business process analysis looks like.
Not a diagram.
Not a workshop.
Rooms.
And questions.
And someone named Nick you will never get to talk to.
Three nearby posts worth opening next.

Apr 28, 2026
A debugging day inside a CRM, payment, and accounting chain where every failed hypothesis still narrows the search.

Apr 28, 2026
Messy processes are the ones worth mapping first: hidden exceptions, tribal knowledge, and the point where automation should wait.

Apr 13, 2026
The most important parts of a process are often the invisible pauses between visible triggers. That is where delays, distractions, and real dependencies usually live.
If you have a manual workflow between tools, I can help map the logic, design the system, and automate it in a way your team can actually use.