Broad questions about productivity can lead to broad answers about staffing, tools, and priorities. Asking about one task someone repeated yesterday can make the discussion more concrete. Focus on the work and its purpose, without assuming that the person doing it chose the process or has authority to change it.

Copying customer details from the inquiry form into the CRM, and then into the accounting system. Downloading a report from one place to upload it to another. Chasing five people for the same status update and assembling it into a spreadsheet nobody reads carefully. Re-typing an address that already exists in three systems.

These small tasks can add up, but the amount of work and the value of improving it should be observed rather than assumed. A short record of frequency, handling time, and corrections gives the discussion a useful starting point.

Start with one task, not a strategy

The mistake is starting from the top. Someone decides the business should automate, a platform is chosen, and then the search begins for processes to put on it. That sequence puts the tool before the problem, and it can lead to a poor fit between the chosen tool and the actual need.

Start at the other end. Pick one task. Just one, and preferably one that somebody actually complains about, because the complaint is evidence that the pain is real rather than theoretical.

Rank candidates roughly by three things: how often it happens, how long it takes each time, and how often it goes wrong. Consider those measures together with risk and complexity. A frequent task with many judgment calls may be harder to automate than a less frequent but predictable one. Look at total effort and consequences, not frequency alone.

Watch it actually happen

Before designing anything, sit with the person who does it and watch. Ask them to explain the process and, with permission, observe an appropriate example. A demonstration can reveal details that are difficult to capture in a meeting.

Look for any differences between the documented process and the example. There will be a step where they check something that is not in the process. A case where they use judgment nobody has documented — this customer always wants it split into two invoices, that supplier's reference number needs a prefix. A workaround for a system limitation everyone has forgotten was a limitation.

Consider a hypothetical office administrator who copies weekly figures from a supplier portal into a spreadsheet. Described in a meeting, that is a five-minute task and an obvious candidate for automation. Watched in practice, four of those minutes are spent reconciling a category the supplier renamed and correcting two rows that always import wrongly. Automating the described version would have produced a fast, confidently incorrect spreadsheet.

The exceptions are not noise. They are the requirements.

Decide what "better" means

Not every repeated task should be automated. There are three honest outcomes and only one of them involves building something.

Eliminate it. One option is to remove a step that no longer serves a purpose. Some reports are produced because they always have been, and nobody currently reads them. Ask who consumes the output and what decision it drives. If the purpose is unclear, ask the process owner to confirm whether the output is still required. Check contractual, recordkeeping, and downstream needs before agreeing to stop.

Simplify it. Often a permission change, a saved view, a template, or a shared drive location removes most of the effort without any development at all. The effort depends on the required approvals and the systems involved.

Automate it. Right when the task is genuinely necessary, stable enough that the rules will not change every month, and either frequent enough or error-prone enough to justify the build and the ongoing maintenance.

That last clause matters. An automation is a small piece of software, and it needs an owner, a place to run, and someone who notices when it stops. Automating something nobody will maintain converts a manual chore into a silent failure.

A first pass you can run this week

  • Ask each person to name the task they repeat most often that they find least valuable.
  • For the top three, note frequency, minutes per run, and how often the result needs correcting.
  • Watch each one being done, once, without interrupting.
  • Ask who consumes the output and what decision it supports.
  • Sort them into eliminate, simplify, and automate.
  • Agree any removals or simplifications with the process owner, then test the change and confirm its effect.
  • Take the strongest automation candidate, and only that one, and scope it properly.

Where automation goes wrong

Two useful risks to consider are a flawed process and unclear ongoing ownership.

The first is automating a broken process. Speeding up something that produces the wrong answer just produces the wrong answer more often, and with more confidence, because a machine did it. Fix the process, then automate.

The second is the automation nobody owns. For example, a connected system might change its interface and cause a previously working automation to fail. Without an error signal or a routine review, the problem may go unnoticed. Every automation needs a name attached, a way to fail loudly, and a periodic check that it is still doing what it was built to do.

There is also a human dimension worth handling directly. Automating part of someone's job is fine; surprising them with it is not. The person who does the task is the person who knows where the exceptions are, and they are far more useful as a collaborator than as an audience.

Your next step

Choose one task this week. Watch it. Decide whether to eliminate, simplify, or automate it, and agree and test a bounded change before expanding the work.

Small improvements to processes people repeat compound quietly, and they are much easier to justify than a platform. ALCO USA Inc helps businesses work through exactly this kind of practical development and automation, alongside managed hosting and IT support.

Sources and further reading

ALCO USA Inc: https://alcohq.com/
ALCO services: https://alcohq.com/services