Skip to content
Codivine
Automation

How to Find Automation Opportunities in Your Own Business

Practical techniques for spotting automatable work — process shadowing, the copy-paste audit, the holiday test and the exception log.

Oskar Szymczak3 min read

The hardest part of automation isn’t building it. It’s noticing what to build, because the best candidates are invisible — they’ve been part of the job so long that nobody registers them as work.

Here are five techniques that surface them reliably.

1. Shadow one case from end to end

Pick a single unit of work — one order, one enquiry, one new client — and follow it through the business. Sit with each person as it reaches them. Write down every system it touches, every message sent, and every time information is retyped.

You’ll usually find:

  • the same data entered two or three times;
  • steps that exist because of a system limitation that was removed years ago;
  • approvals nobody remembers requesting;
  • a handover that only works because two people sit near each other.

An hour of this beats a day of workshops, because you’re watching what happens rather than hearing what’s supposed to happen.

2. The copy-paste audit

Ask everyone to note, for one week, every time they copy information from one place to another. Just a tally.

Copy-paste is the purest signal of a missing integration. Every instance is data that exists in one system and is needed in another, with a human acting as the connector. That’s a job for an integration, and it’s usually cheaper to fix than people expect.

3. The holiday test

Ask: what stops working when a specific person is away?

If the answer is "invoicing", "getting orders to the warehouse", or "checking the shared inbox", you’ve found both an automation candidate and a genuine business risk. Processes that depend on one person’s memory are the ones most worth making explicit.

4. The exception log

For two weeks, log every time someone says "that’s weird" or has to redo something. Note what happened and how long the fix took.

This finds the errors that have been normalised — the ones nobody reports because they’re routine. They’re often the strongest financial case for automation, because everyone has stopped counting them.

5. Follow the reports

Every recurring report is a process. Ask who makes it, how, and how long it takes.

The usual answer involves exporting from two systems, pasting into a spreadsheet, and manually fixing formatting. That’s several hours a month producing something that’s slightly out of date by the time anyone reads it.

Reports are also a good starting project politically: highly visible, low risk, and the output is identical every time.

Where to look first, by function

  • Sales: lead capture, assignment, follow-up reminders, quote generation, CRM data entry.
  • Operations: order processing, scheduling, status updates, stock checks, supplier communication.
  • Finance: invoice creation, payment matching, chasing, expense handling.
  • Customer service: ticket routing, canned responses, status notifications, escalation.
  • HR: onboarding checklists, document collection, leave requests.
  • Marketing: reporting, list synchronisation, campaign setup, publishing.

What to write down for each candidate

Before you take anything to a supplier — us or anyone else — capture:

  • what triggers it;
  • the steps, in order, with who does each one;
  • the systems involved;
  • how long each step takes, roughly;
  • how often it happens;
  • what goes wrong, and how often;
  • what happens today when it does.

That last one matters more than people expect. Any automation has to handle failure, and the current human answer to failure is the specification for it.

The trap to avoid

The most enthusiastically nominated candidate is often the most complex one — the interesting problem, the thing that would be impressive. Start with the boring, frequent, stable process instead. It’ll be finished sooner, it’ll work more reliably, and it’ll earn you the internal credibility to attempt the interesting one.

If you’d rather have someone run this exercise with you, it’s exactly how our automation projects begin — and the map is yours regardless of whether we build anything.

Oskar Szymczak

Founder & Software Engineer

Leads the technical side of every project — architecture, development and the decisions that are expensive to change later.

More about the team

Want help with this?

This is the kind of work we do. These pages explain how.

Got a version of this problem?

Describe it in your own words. We'll tell you what we'd do about it — and whether it's worth doing at all.

No specification needed. A description of the problem is enough to start.