Automation projects in smaller businesses usually fail in the same way: something impressive gets built for a process nobody minded doing, while the process that actually consumes the week carries on untouched. The technology is rarely the problem. The selection is. This is how to decide what to automate first, and how to tell the difference between a process that will pay back and one that will quietly cost you more than it saves.
The wrong way to choose, and why it is so common
Most automation shortlists in an MSME are assembled from whoever complained loudest, whatever the software demo made look easy, or whichever department has a manager comfortable with technology. None of these correlates with return.
The demo problem deserves particular attention. Vendors demonstrate the processes that showcase their product, not the processes that are costing you money. A polished workflow builder will make approval routing look transformative — and approval routing may not be anywhere near your biggest drain. You end up automating the demo rather than the business.
The four numbers that actually decide it
Before anything reaches a shortlist, get four figures for each candidate process. None requires software to obtain, and gathering them takes a morning per process.
- Frequency. How many times a month does this run? A task performed twice a year is almost never worth automating, however painful it is each time.
- Duration and headcount. How long does one instance take, and how many people touch it? Multiply by frequency. This is your annual hours figure, and it is usually a surprise to everyone.
- Error rate and cost of error. How often does it go wrong, and what does one error cost to fix or to absorb? A process that runs cleanly 99 per cent of the time but costs a great deal on the exception can be worth more to automate than a frequent, forgiving one.
- Stability. Has this process changed in the last year? Will it change in the next? Automating a process that is about to be redesigned means paying twice.
The fourth is the one most often skipped and the one that most often kills a project. Automation encodes a process; if the process is unsettled, the automation becomes the thing preventing you from changing it.
The four-box test
Plot each candidate on two axes: how much time it consumes, and how stable and rule-based it is. Where it lands tells you what to do — and three of the four boxes are not “automate”.
| Where it lands | Typical examples | What to do |
|---|---|---|
| High volume, stable, rule-based | Payroll input collection, leave accrual, attendance consolidation, statutory return preparation, invoice matching | Automate first. This is where the return is |
| High volume, but judgement-heavy | Appraisal conversations, hiring decisions, customer escalations, pricing exceptions | Assist, do not automate. Automate the paperwork around it and leave the decision with a person |
| Low volume, stable | Annual policy renewals, statutory filings that happen once a year | Leave it. Write a checklist instead. The build cost will never be recovered |
| Low volume, unstable | New product launches, one-off projects, anything still being invented | Do not touch it. You would be encoding a guess |
Most MSMEs discover that their genuine automation candidates all sit in the same place: the administrative work surrounding HR, payroll and compliance. It is high-frequency, rule-based, legally consequential when it goes wrong, and almost entirely invisible to the people running the business, because it is absorbed by staff who simply get on with it.
Fix the process before you automate it
The oldest rule in this field still holds: automating a broken process gives you a faster broken process, and makes it harder to see that it is broken because the mess is now happening inside software.
Before automating anything, walk the process end to end and ask three questions.
Does every step still have a reason?
Processes accumulate steps. A form gets a second signature because of something that went wrong in 2019, and the signature stays long after the person who required it has left. Remove the steps that no longer earn their place before you encode them permanently. In most MSME processes, something between a fifth and a third of the steps turn out to be historical.
Is anyone re-keying data that already exists?
The clearest automation signal in any organisation is a person typing information into one system that is already sitting in another. Attendance into payroll, appraisal ratings into a spreadsheet, candidate details into three places. This is pure waste and usually the fastest thing to remove.
Is this a process problem or a role problem?
If a task is slow because nobody is sure who owns it, automation will not fix that — it will formalise the ambiguity. That is a definition problem, and it belongs with your performance framework, not your automation project.
Where automation quietly costs more than it saves
- Processes that change every quarter. Each change becomes a rebuild, and the rebuild cost is invisible in the original business case.
- Anything where the exception is the norm. If sixty per cent of cases are handled as exceptions, automating the forty per cent adds a second parallel process to maintain rather than replacing one.
- Work that only one person understands. Automate it and you encode their assumptions without ever examining them. Document it first, and often you find the process itself was the problem.
- Anything nobody has costed. If you cannot state the annual hours a process consumes, you cannot know whether the build is worth it. This is the most common reason automation projects cannot show a return afterwards.
A sequence that works
- Count first. One morning per candidate process to establish frequency, hours, error rate and stability. Do this before talking to any vendor.
- Clean the top two. Remove the dead steps and the re-keying. Some processes stop being worth automating at this stage, which is a good outcome and a cheap one.
- Automate one process end to end rather than three partially. A half-automated process still needs the manual path maintained alongside it, so you now run two.
- Measure the same four numbers again after a full cycle. If hours have not fallen, find out where the time went before automating anything else. It has usually moved rather than disappeared.
- Only then widen. The second process is much cheaper than the first, because the plumbing and the habits already exist.
This is the sequence Process.ai follows. The counting step is deliberately first and deliberately unglamorous, because it is the step that determines whether everything after it was worth doing.
How this connects to the rest of the system
In most of the MSMEs BPro works with, the processes that pass the four-box test are clustered around people administration: attendance consolidation, leave accrual, payroll input, appraisal paperwork, statutory returns. That is not a coincidence — it is high-frequency, rule-based work with real legal consequences and no revenue attached, so it never gets attention.
Which means the automation conversation and the systems conversation are usually the same conversation. An HRMS removes the re-keying; Process.ai removes the routine transactions around it; and the point of both is to release the hours HR currently spends on administration into capability and retention work. If your team is still running this on spreadsheets, the switching thresholds are worth reading first.
Frequently asked questions
What is a realistic first automation for a 150-person business?
Usually attendance-to-payroll input. It runs monthly, it is rule-based, it is error-prone, an error is visible and expensive in goodwill, and the data almost always already exists in a system somewhere. It is rarely the process people nominate, but it is frequently the one that pays back first.
Should we automate before or after implementing an HRMS?
After, in most cases. The HRMS gives the automation a reliable data source; automating around spreadsheets means building on a foundation you intend to replace. The exception is a process that sits entirely outside HR and touches nothing you are about to change.
How do we know whether it actually worked?
Re-measure the same four numbers after one full cycle. Specifically check whether the hours left the organisation or simply moved to someone else — a genuinely common outcome where a new checking or reconciliation step quietly replaces the old manual one.
Is AI different from ordinary automation here?
The selection discipline is identical. What changes is that judgement-heavy, high-volume work — the second box above — becomes partly addressable, as assistance rather than replacement. It does not change the answer for unstable or low-volume processes, and it does not rescue a process that was never defined properly.
Where to go from here
If you can already name the process that consumes the most time and cannot say how many hours it takes, that is the place to start, and it costs a morning to find out. Process.ai covers how BPro approaches this, our case study shows where automation sits inside a wider engagement, and HR analytics is how you check afterwards whether the hours actually went away.
BPro is based in Kochi, Kerala and works with organisations across India. Call +91 80869 08876, email care@bpropms.com, or use the contact form.