Every company that has abandoned a software tool remembers the moment it happened. The system insisted on a flow the organisation simply doesn't have — an approval level that doesn't exist, a form that ignores how the work actually moves — and someone found a way around it. A WhatsApp message here, a spreadsheet there, a signature on paper.
From that day the tool is a formality. People update it after the fact, if they update it at all. The real process runs somewhere else, invisible to the dashboards that were supposed to show it, and everyone quietly knows.
The failure gets blamed on adoption, or training, or attitude. It is almost always something simpler: the tool assumed a company shaped like its template, and your company is not that shape.
The company the template was built for
Off-the-shelf tools have to generalise — that is what makes them products. So they are built for a notional company: one clean hierarchy, one approval chain, tidy roles, no history. Requester submits, approver approves, done. The demo looks convincing, because the demo company really is shaped like the template.
Your organisation grew differently. Approval limits vary with designation and department, and some decisions need finance and a director in a fixed order. One business unit follows rules the others don't, for reasons that made sense when they were written. None of this is dysfunction — it is the accumulated judgement of years of actually running the business.
To a generic tool, all of that is friction. You either flatten your rules to fit the template, or you fight the settings screen until someone senior says to just get on with the work — outside the system.
Configuration options do not rescue the template, either. Settings can rename fields and add a step or two, but the deep assumptions — who reports to whom, what an approval means, how an exception is handled — are baked into the product's bones. When your structure disagrees with those assumptions, no checkbox will reconcile them.
Exceptions are not edge cases
Ask an operations head where work really gets stuck and they will not describe the standard flow. They will describe the exceptions: the approver travelling with no laptop, the urgent hire that cannot wait for the weekly cycle, the requisition that changed after it was raised, the cost shared across two departments.
Generic software handles the standard flow and shrugs at the rest. But the exceptions are exactly where a process needs software most — they are where files stall, where rules bend, where nobody is quite sure who decides. A tool that only automates the easy path has automated the part that already worked.
When we built Vensar ATS for a multi-vertical construction company, the brief was the opposite of a template: five verticals, every designation tier, every exception, mapped before a single screen was designed. Requisitions move through the company's own approval chain — not a generic one — with automatic reminders so no file sits on a desk. The exceptions were not obstacles to the design. They were the design.
What routing around actually costs
The cost of a bypassed tool is not the subscription. It is that your data stops being true. The dashboard says a requisition is pending; it was approved three days ago on a phone call. The system shows a handful of candidates; the real pipeline lives in somebody's inbox.
Once that gap opens, every report becomes a negotiation. Managers keep private trackers because they trust their own spreadsheet over the official system. New joiners are taught the documented process and then, quietly, the real one. You are paying for software and still running the company on memory and follow-up calls.
There is a compliance cost as well. Approvals given on calls and recorded later — or never — leave you unable to show who decided what, and when, on exactly the decisions where you may one day need to show it. A system people bypass is not just inaccurate; it is an audit trail with holes in it.
And the gap only widens. Each workaround creates the next, because once one step lives outside the system there is less reason to keep the neighbouring steps inside it.
Map the organisation before designing the software
We start every engagement the same way — not with screens, but with a map. Who approves what, in what order, with what limits. How people are informed, and of what. What each sector demands of the process, and which exceptions are genuine policy rather than habits the organisation would happily retire if someone asked.
Only then do we design, around the map rather than around a template. That is why our products differ so much in shape. Professors360, our academic hiring platform for colleges and universities, has separate workspaces for management, HR, HODs and subject experts, because that is how academic hiring actually divides. A project tracking system we build for field teams pairs a mobile app on site with a dashboard for management, because field and head office need different windows onto the same truth.
Same approach every time; different software every time. The organisations are different shapes, so the systems must be. What stays constant is the discipline of asking, before anything is designed, how the work actually moves today — and refusing to assume the answer.
Software people don't route around is software that actually runs the process.
Walk it through your three ugliest scenarios
There is a practical way to evaluate any system you are considering, ours included. Ignore the demo script and walk the tool through your three ugliest real situations. The urgent hire raised on a Sunday, the rejected requisition that comes back changed, the approver unreachable for a week while files pile up. If the vendor cannot show you those, you have your answer early, at the cheapest possible moment.
If the tool bends to your rules, your people will use it — and then the data inside it is the truth about your business, and every report drawn from it can be trusted. If your rules must bend to the tool, you already know how it ends: with the moment somebody routes around it, and everything afterwards is formality.
Different industries, one approach: build around the client's real rules, automate the busywork, keep people in control of decisions. That is the whole argument against templates — and it is the only way we build.