Think Build Implement Repeat
Business Automation

Start With the Task Everyone Complains About

Last updated:

Complaint is a reasonable signal

Analytical approaches to choosing automation are useful and slow. A quicker starting point: what does everyone complain about? Tasks people hate are usually hated for good reasons — repetitive, mechanical, and producing nothing anyone values.

That description is also the profile of a good automation candidate, which is why the instinct is worth taking seriously.

Check it against three numbers

  1. How often? Daily or more is strong; weekly is marginal; monthly rarely pays.
  2. How long each time? Timed for a week, not estimated.
  3. What does an error cost? If mistakes are expensive, the case improves substantially.

If the numbers do not support it, the complaint is about tedium rather than cost. That is still worth addressing — but through process change rather than a build.

The usual suspects

  • Copying data between two systems
  • Chasing people for information
  • Assembling the same report from the same sources
  • Formatting documents
  • Reconciling two lists that should match
  • Answering the same question repeatedly
Every one of these is high-frequency, low-judgement work that a computer does better. If your most-complained-about task is on this list, you have your first project.

The morale return is real

Automation business cases are written in hours and pounds. The return that clients mention a year later is usually different: the team stopped dreading Mondays, or the person doing the worst job got to do something better.

That is difficult to put in a spreadsheet and it affects retention, which is expensive when it fails.

Ask the people who do it

Whoever does the task knows where it goes wrong, which cases are awkward, and what the workarounds are. They are also the ones who will use whatever replaces it.

Involving them early converts potential resistance into ownership, and it produces a far better specification than a manager's description of the same process.

Keep the first one small

One task, one path, four to eight weeks. Prove it, measure it, and let the result fund the next. A first automation that visibly removes a hated job is the best argument for a second.

Frequently asked questions

What if the hated task is not automatable?

Then look at whether it needs doing at all, whether it can be simplified, or whether it can be redistributed. Not every problem is a software problem.

How do we time a task honestly?

Have the person tally it for a week rather than estimating. Estimates are wrong in both directions and the tally settles the argument.

Will people worry about their jobs?

Some will, and it is worth addressing directly. In our projects the usual outcome is that a role stops being 70% data entry and becomes something more valuable, and saying that plainly early prevents a lot of anxiety.

What if two tasks are equally hated?

Pick the one with more repetition and less judgement. It will be faster to deliver and more likely to succeed, which matters more for a first project.

Keep reading

Know exactly which task everyone hates?

Tell us what it is and roughly how often it happens. We will tell you whether the numbers support automating it.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

Business AutomationCustom Software Development