Look closely at any process in your company — a hiring approval, a purchase, a project report — and you will find two kinds of work braided together. One kind follows rules: collect the documents, route the file, remind the approver, update the status, compile the numbers. The other kind needs judgment: approve or reject, negotiate or hold, make an exception or enforce the line.
Most software trouble comes from treating the two as one. Automate everything and the system starts making calls it has no business making. Automate nothing and your managers spend their days doing the work of a routing engine — forwarding, chasing, reminding — with the actual decisions squeezed into whatever attention is left.
Stated plainly, the line is this: rule-following work belongs to the system, and judgment belongs to your people. Drawing that line accurately inside a real organisation is the actual craft of building business software, and it is worth seeing what sits on each side of it.
The work that follows rules
Rule-following work has a recognisable shape. The inputs are defined, the next step is known, and no discretion is involved — nobody is exercising wisdom when they forward a requisition to the next approver or type the same status into a Monday report. Policy decided the task in advance; a person is merely executing it.
This is the work software should absorb completely. A system does not forget to send the reminder on day three. It does not go on leave with the file in its drawer. It routes the request to the right person every time, because the routing rule was written once and is applied always.
It is also, in our experience, most of the elapsed time in a process. A decision that takes minutes of actual thought routinely takes days of calendar time, and the difference is busywork — the file waiting to be forwarded, the reminder waiting to be sent, the summary waiting to be typed by someone who had three better things to do.
Notice that none of this requires anything exotic — just reliability. The follow-up on WhatsApp, the escalation email, the compiled report: these are promises kept on schedule. Machines keep schedules better than people do, and there is no shame for anyone in that.
The work that needs judgment
Judgment work has the opposite shape. The inputs are never quite complete, the options carry trade-offs, and someone must own the outcome. Whether to approve a hire outside the budget, what salary to offer a strong candidate, whether a vendor's delay deserves patience or a penalty — these are calls, not calculations.
This work belongs to people, and not as a temporary concession until the software improves. Accountability is the point. An approval means something because a named person weighed it and put their name to it. A negotiation works because both sides know a human can respond to what the rules did not anticipate.
When systems cross this line — auto-approving, auto-rejecting, auto-deciding — trust drains fast. People stop believing the outputs, start working around the tool, and rebuild the real process in WhatsApp groups and corridor conversations. The software keeps running, but the organisation has quietly left it.
There is also work that looks rule-bound but hides judgment inside. Document verification seems mechanical until a certificate does not match a claim. The rules can flag the mismatch; deciding what it means for the candidate is a person's call. Good systems hand over at exactly that seam.
Two ways to draw the line wrong
Under-automation is the failure most companies are living with now. Senior people doing clerk work: chasing approvals, asking "any update on this?", assembling the same weekly report from the same four sources. It feels safe because humans sit in every loop — but the humans are busy being the loop, and decisions get whatever attention is left over.
Over-automation is the failure that gets sold in demos. It looks efficient on stage and fails on the first real exception — the urgent hire that must skip a step, the approval that genuinely needs a conversation first. If the system cannot express the exception, people go around the system, and every workaround takes a piece of the process with it.
Drawn properly, the line runs through the middle of each process, not around it. Within a single approval flow, the routing and reminding are automated while the deciding is not. Within hiring, the follow-ups are automatic while the offer remains a person's call. It is a scalpel, not a switch.
Automation should carry the file to the right desk — not sign it.
What the line looks like in practice
Vensar ATS, the recruitment platform we built for a multi-vertical construction company, is drawn along exactly this line. Manpower requisitions travel through the company's own approval chain — every approver a person, every approval a real decision — while the reminders are automatic, so no file sits forgotten on a desk.
Candidates are kept informed automatically over email and WhatsApp from first contact to joining day; nobody types those updates by hand. But screening judgments, salary negotiations and the offer itself belong to the team. Offers go out as private accept/decline links — trackable, revocable, fully audited — and deciding who receives one was never the system's job.
The result of drawing the line this way was 70% of time and effort saved in hiring. Read that carefully: what was saved was busywork. The judgment — who to interview, what to pay, whom to hire — sits exactly where it always did, with the same people, now with their attention undivided.
Attention is the scarce resource
The case for the dividing line is ultimately about attention. Your managers' capacity for careful decisions is the scarcest resource in the company, and every hour of chasing and compiling is drawn from the same account. Automating the busywork is not about replacing people — it is about refunding their attention to the work only they can do.
AI belongs on the same side of the line. Used well, it extends the rule-following work the system can absorb and prepares information so a decision arrives ready to be made. What it should not do is quietly cross over and make the call. The busywork runs itself; your people stay in control of the decisions.
This is why we start every build by mapping the rules your organisation actually runs on — who approves what, how people are informed, what each sector demands. That map shows precisely where the line falls in each of your processes. The software's job is simply to respect it.