What to automate first in HR (and what to leave alone)

A business automated its leave approval workflow. Requests now routed to the reporting manager, escalated after two days, and updated balances automatically. It worked exactly as specified. Within a month, three managers had asked for a way to approve things outside the system, because the rule it encoded — that leave was approved by the reporting manager — was not how the business had actually operated. In practice, shift coverage was agreed between supervisors first, and the manager's approval was a formality afterwards.

The automation was not wrong about the rule. It was wrong that a rule existed. What had been a flexible arrangement became a rigid one, and the workaround that emerged was worse than the manual process it replaced.

Automation makes a process permanent

The core point, and the one that determines everything else: automating a process converts it from something people adjust informally into something that requires a change request to alter.

For a process that is well understood and agreed, that is the benefit — consistency, no drift, no dependence on who happens to be handling it. For one that is contested, undefined, or quietly working because people bend it, it is the cost. The disagreement does not disappear; it gets encoded, and then it gets worked around.

The test before automating anything: if you asked three people how this works today, would they give the same answer? If not, the work is to settle the process, not to automate it. That sequencing is the first thing any sensible HR process automation effort establishes, and skipping it is the most common reason these projects produce shadow spreadsheets.

The four conditions

  HIGH VOLUME
    Happens often enough that the effort pays back.
    A monthly task is rarely worth automating; a
    daily one usually is.

  STABLE RULES
    The logic has not changed in a year and is not
    about to. Rules in flux produce constant rework.

  FEW EXCEPTIONS
    If a quarter of cases need special handling, the
    automation handles three-quarters and someone
    still runs a manual process alongside.

  AGREED OWNERSHIP
    One person or role owns the rule and can change
    it. Shared ownership means no one can approve a
    correction, so errors persist.

  THREE OUT OF FOUR IS NOT ENOUGH.

Applied honestly, this list is more restrictive than it looks, and that is the point. Most disappointing automation projects satisfied two or three conditions and proceeded anyway, usually because the volume was high and the pain was real.

Where it usually pays

For most growing businesses, the candidates that satisfy all four are fairly consistent.

• Leave balance calculation and visibility. High volume, stable arithmetic, and it removes an entire category of query. Note that the calculation is a better candidate than the approval routing, which is where the judgement sits.
• Attendance capture and exception flagging. The capture is mechanical. The decision about what an exception means should stay with a person.
• Payroll input assembly. Not the payroll calculation itself, but collecting the inputs — the recurring monthly scramble to gather attendance, overtime, joiners and leavers is largely mechanical and error-prone by hand.
• Document generation. Offer letters, confirmation letters, experience letters. Same template, different fields, produced repeatedly with manual transcription errors.
• Reminders and status visibility. The cheapest wins in HR are often not workflow at all but simply making it visible who is waiting on whom.

The last item is worth emphasising because it is consistently undervalued. A large share of HR delay is not people failing to act but people not knowing that something is waiting for them. Visibility costs very little to build and frequently removes more delay than a full workflow would.

The shadow spreadsheet test

Six weeks after anything goes live, ask one question: is anybody still maintaining the old spreadsheet? The answer settles whether the automation worked more reliably than any usage statistic will.

A spreadsheet kept alongside means one of three things, and it is worth finding out which. The system does not handle a case that matters, so someone is tracking it separately. Or somebody does not trust the output and is reconciling it privately. Or the spreadsheet contained something the system was never designed to hold, which usually turns out to be the most interesting finding.

None of the three is solved by insisting the spreadsheet stops. It is being maintained because it is doing something necessary, and removing it without understanding what simply moves the work somewhere less visible.

What to leave manual

Some things should stay with a person, and the reasons are worth being explicit about rather than treating as a limitation to be overcome later.

1. 1

   Anything where the discretion is the point

   An exception granted because someone's circumstances warranted it is not a rule with missing conditions. Encoding it either removes the discretion or produces a rule so broad it means nothing.

2. 2

   Decisions with consequences for an individual

   Probation outcomes, disciplinary steps, performance ratings. Systems can hold the record and prompt the step; the decision should be visibly a person's, because the individual is entitled to know who decided.

3. 3

   Anything you do fewer than a dozen times a year

   The build and maintenance cost will not be recovered, and low-frequency automation is also the most likely to be quietly wrong because nobody exercises it often enough to notice.

4. 4

   Processes you are about to change

   Automating just before a restructure, a policy revision or a system migration means building twice. Wait, and run it manually in the meantime.

Measuring the return honestly

Automation is usually justified on hours saved, and hours saved is usually the weakest part of the case.

The three hours a month an HR executive spends assembling payroll inputs do not become three hours of new output; they get absorbed. The real returns are elsewhere and are less often counted: errors that do not happen, queries that are never raised because information is visible, and month-end that closes on the same date regardless of who is on leave.

The last is the one that matters most and is easiest to observe. A process that depends on a specific person knowing how it works is a risk as much as an inefficiency, and removing that dependency is frequently worth more than the time saved — particularly for anything in payroll input management, where a single person's absence can move a date the business cannot move.

A sensible order

For a business starting from spreadsheets and messages, the sequence that works is the same one that works for any system rollout, and it is dictated by dependency rather than by appetite.

Employee records first, because everything references them and automating on top of inaccurate data produces confidently wrong output. Then attendance and leave, because they are high volume and generate the most queries. Then payroll inputs, which is where the benefit becomes visible to management. Then self-service, once balances and records are trusted enough that people will not dispute what they see.

Anything else — performance, recruitment, training records, document workflows — comes after, in whatever order the business actually needs. There is no correct sequence beyond that point, and businesses that agonise over it are usually avoiding the harder work of settling the processes underneath.

Where the answer at each stage turns out to be that nobody agrees how the process works, that is the finding and it is more valuable than the automation would have been. Settling it is HR process consulting work, and doing it first is what separates an HR process automation project that reduces effort from one that adds a system alongside the spreadsheet everyone still maintains.