Somewhere in your company a request moves through several hands before it is approved — a purchase, a new hire, a discount, a contract, a change to a customer account. It waits in inboxes, gets forwarded, stalls when someone is on holiday, and nobody can say where it is without asking around. The urge to build a tool that automates this is right. The mistake is building the tool before you understand the process, because automating a broken process does not fix it — it just makes the mess run faster and harder to see.
Map the real process first
Every company has two versions of its approval process: the one in the policy document and the one that actually happens. The official version is clean and linear. The real one has a step everybody skips, an approval that is really rubber-stamped, a manager who quietly re-does the analysis because they do not trust the form, and a shortcut for urgent cases that has become the normal path. If you automate the official version, people will reject the tool because it does not match reality; if you automate the real version as-is, you cast today's dysfunction in software.
So mapping is not a formality. It is sitting with the people who live the process and drawing what genuinely happens, including the ugly parts. This is where the value is created, before a line of code exists, and it is the step most automation projects rush past on their way to the fun part.
Expect the map to be uncomfortable. It exposes the manager whose approval is theatre, the team that quietly re-does another team's work, the queue where requests go to age. That discomfort is the point — you cannot automate what you refuse to look at squarely. The companies that get the most from automation are the ones willing to see their own process honestly before they encode it.
Fix the process before you automate it
Mapping almost always surfaces steps that exist for no good reason — an approval added years ago after one incident, a sign-off from someone who always says yes, a form field nobody reads. The temptation is to automate all of it faithfully. Resist. The cheapest improvement is usually deletion: removing a redundant approval is faster and safer than automating it, and every step you keep is one the software has to model, maintain, and route around when it breaks.
The right sequence is to fix the process on paper first, get the people who own it to agree the leaner version, and only then build. Automation should encode a process you have already improved, not preserve one you have not. A good automation project often ships fewer steps than it started with, and that is a sign it worked.
There is a reason this order matters beyond tidiness. Every step you automate becomes expensive to change later, because now it is code, configuration, and a habit people have formed. Deleting a redundant approval on paper costs a conversation; deleting it after it is wired into the tool costs a change request and a retraining. Cheap decisions are the ones you make before the software sets them in place.
States, approvals, and handoffs
Once the process is honest and lean, the tool has a clear shape. At its core a workflow is a set of states a request moves through — submitted, in review, approved, rejected, returned for changes — with rules for who can move it from one to the next. Making these states explicit is most of the battle. It replaces I emailed it to Jana, I think with a request that is visibly in a known state, owned by a known person.
The handoffs are where the real design happens. What information must be present before a request can advance? Who is allowed to approve at each threshold? What happens on rejection — does it die, or return with comments to the sender? Getting these transitions right is what makes the tool feel like it understands the work rather than fighting it. A workflow tool is, at bottom, a shared and enforced agreement about how a decision gets made.
Visibility is a benefit people underrate until they have it. When every request sits in a named state with a named owner, the question that used to eat a manager's week — where is this, and who is holding it up — answers itself. Half the value of a workflow tool is not that it moves work faster, but that it ends the search for where work is stuck.
Notifications, SLAs, and the human exceptions
A workflow tool earns its keep by making sure nothing sits silently. When a request lands in someone's queue, they should know. When it has sat too long, someone should be nudged, and if it sits longer still, it should escalate. Service-level expectations — this approval within two days — turn a vague hope into something the system tracks and surfaces, and they are often the single biggest reason cycle times drop.
But the exceptions are what separate a tool people use from one they resent. Real processes have the urgent case that must skip a step, the approver on leave whose authority must delegate, the request that does not fit any category. If the tool has no graceful path for these, people go around it — back to email — and the automation quietly dies. Design the exceptions deliberately: a defined fast path, delegation, and an override that is logged rather than forbidden. A workflow tool that cannot bend to reality gets abandoned by it.
The design instinct that works is to treat the exception as a first-class part of the process, not an embarrassing edge. Ask the people who run it what they do when things go sideways today, and build those answers in: the emergency path, the stand-in approver, the request that needs a human to judge it. A tool that only handles the happy path is a tool that handles the easy half of the work and abandons you for the hard half.
It has to fit the systems you already run
An approval rarely lives alone. A purchase touches finance, a new hire touches HR, a discount touches the CRM. If the workflow tool is a sealed box where people re-enter data that already exists elsewhere and then re-key the outcome into another system, it adds work even as it adds visibility. The integrations are what make it a genuine improvement: pulling the request context from the source system, and pushing the decision back so the approved purchase order, the created account, the updated record happens without a human retyping it.
These integration points also decide the tool's real boundary. Deciding early what the workflow owns and what it merely coordinates keeps it from swelling into a second copy of every system it touches — which is a common way these projects quietly balloon in scope.
Integration is also the honest test of whether the workflow is worth automating at all. If a process is entirely self-contained and touches no other system, a shared document and a habit might serve it. The workflows worth building a tool for are usually the ones that span systems and teams — precisely because that is where things fall between the cracks, and where a tool that carries context across the gaps earns its cost.
Someone has to own the rules
A workflow encodes decisions about who approves what and when, and those decisions age. Thresholds change, a new role appears, a step that made sense last year becomes a bottleneck this year. If no one owns the rules, the tool slowly drifts from how the business actually wants to work, and people start routing around it again — back to the email chains it was built to replace.
So a workflow tool needs a named owner on the business side, not just in IT — someone empowered to change a rule when reality changes and accountable for whether the process still serves the company. The tools that keep earning their cost are the ones treated as a living process, adjusted deliberately as the business learns. The ones that fail are treated as a project that shipped and then went untouched until it no longer matched anything.
No-code, or a build that lasts
For simple, low-stakes workflows, no-code platforms are genuinely good, and it would be dishonest to pretend otherwise. A capable person can assemble an approval flow in one of them in an afternoon, and for a process that is not central to the business, that is the right answer. Start there, and do not pay for custom software to route a stationery request.
A frequent middle path is to prototype the workflow in a no-code tool first, precisely to learn it cheaply. Running the real process through a throwaway version for a few weeks teaches you where it bends, which exceptions are common, and what the volume really is — and that knowledge makes the decision to keep it or rebuild it a fact rather than a guess. Treating the first version as a way to learn, not a monument, is often the shrewdest move.
The case for a custom build appears when the workflow is durable and central — a core process you will run for years, with rules specific enough that you spend more time fighting a generic tool than using it, deep integration with your own systems, volume that makes per-action pricing painful, or compliance requirements a platform cannot meet. The honest tradeoff: no-code is faster to start and cheaper until the workarounds and per-seat costs pile up, at which point owning the tool pays off. Whichever way it goes, measure cycle time — how long a request takes from submission to decision — before and after, because that number is the whole point, and a workflow tool that does not move it is not working. Start with one painful workflow, get it genuinely right, and let the win earn the next one, beginning with a short assessment that maps the process, fixes it on paper, and returns a costed plan.