Why FIWB Solutions maps a workflow by hand before writing any automation code, and what that step catches before it becomes an expensive fix.
by FIWB Solutions
This week at FIWB Solutions, most of our client time went into something that looks like it should take an afternoon: writing down, step by step, how a process actually works before touching any code.
It sounds basic. It is not the step most teams skip on purpose, they skip it because nobody in the room can fully describe the process either. The person who does the work daily has never had to explain it out loud. The person requesting the automation has a mental model that's two or three years out of date. Both are confident. Both are missing pieces.
When a client comes to us wanting to automate a workflow, custom operations software or otherwise, the request usually arrives as a summary: "we need the invoices to route automatically" or "the dispatch board should update itself." That summary hides the actual decision points: who overrides the default, what happens when a field is blank, which exceptions get escalated and to whom.
This week, that meant sitting with a client's team and walking the workflow end to end, screen by screen, decision by decision, before proposing anything. We ask people to show us, not tell us. Screen sharing beats a whiteboard for this because the tool itself surfaces steps nobody thought to mention: the spreadsheet tab nobody talks about, the manual double-check someone added after a mistake two years ago, the workaround that's become load-bearing.
The mapping session also tends to surface disagreement between roles. A manager describes the process one way; the person who runs it daily describes something adjacent but different. Neither is wrong. They're each describing the parts of the process visible from where they sit. Getting both descriptions on the same page, literally, is often the first time anyone has seen the whole thing at once.
A few things consistently show up once a workflow is on paper instead of in someone's head:
Each of these looks small in isolation. Together, they're usually the difference between an automation that fits how the business actually runs and one that technically works but gets routed around within a month because it doesn't handle the case that comes up every Friday.
Skipping this step doesn't save time. It moves the discovery to after launch, when the fix is more expensive and the client has already committed budget to a system built on an incomplete picture. A change that would have been a conversation during mapping becomes a change request against a live system, with real users depending on the old behavior in ways nobody wrote down.
It's worth separating this from a project scope document. Scoping describes what the finished system should do. Mapping describes what currently happens, including the parts nobody would choose to design that way if they were starting fresh. A good map includes the workaround, the exception, and the step someone added out of caution after something went wrong, not because those things belong in the final design, but because the team needs to decide, on purpose, what to keep and what to drop.
That decision belongs to the client, not to us. Our job in the mapping phase is to make the invisible parts of the process visible enough that the client can make that call deliberately instead of by default.
If a workflow in your business feels like it should be automated but nobody can describe it in full without saying "it depends," that's the workflow worth mapping before it's worth automating. That gap between what people think happens and what actually happens is where custom software projects run into trouble months in, not at the start.
If you have a process like that and want a second set of eyes on it before committing to a build, reply to this post or book a call through our request a demo page and we'll walk through it with you.