What Should You Automate First in Your Business?

Why am I still doing this manually?

Think about the task you did yesterday that made you say, “Why am I still doing this manually?”

That might be a better starting point for automation than a video showing an AI system running an entire company.

You don't need to connect every tool you own. You need to find a repeated job where a small change would be useful, then make sure the automated version works when the inputs aren't perfect.

The first win can be quite boring. I think that's fine.

Start with a task you can explain

Write down what happens now, from the moment the job begins to the point where it's finished.

For example: a website enquiry arrives, someone copies the details into a spreadsheet, then sends a notification to the person responsible for replying.

That's a process we can look at.

“Automate our marketing” is much harder to assess. It contains decisions and several different jobs, some of which may not be clearly defined yet.

If you struggle to explain what should happen, slow down. Automating an unclear process tends to make the confusion happen more quickly.

Look at frequency as well as irritation

An annoying job isn't always a valuable first automation.

Something that takes ten minutes once a year probably doesn't deserve weeks of development. A small task repeated throughout the day may be a much stronger candidate.

You can do a rough calculation. If a task takes four minutes and happens twenty times a week, that's eighty minutes of manual work. That is an illustrative example, not a promised saving: checking the output and dealing with exceptions will still take some time.

Estimate the useful saving against the cost of setting it up and keeping it running. Include subscription costs if the proposed tools require them.

The answer doesn't need to be perfect. It needs to be honest enough to avoid automating something simply because it can be automated.

Favour rules you already understand

A good first candidate often has a clear trigger and a predictable outcome.

When a valid enquiry arrives, create a record and notify the right person. When a project reaches an agreed stage, prepare the next internal task.

These jobs don't necessarily need AI. If the rule is exact, an ordinary workflow may do it well.

AI becomes more relevant when the input needs interpretation, such as suggesting a category for a free-text message or drafting a short summary. Even then, you need to decide what happens when the suggestion is wrong.

I'd rather use a simple rule where one fits than add a model that makes the result less predictable.

Choose a mistake you can catch

For a first project, I would favour something whose output can be checked before it causes a problem.

Preparing a draft response is different from sending it automatically. Flagging a message for review is different from deciding a customer doesn't matter and hiding it.

Start with a review step where judgement matters. You can consider reducing manual checking later if there is enough evidence and the consequences are understood.

That isn't a reason to make every workflow cumbersome. It's a way to avoid handing over a decision before you know whether the system handles it well.

Follow one enquiry through the proposed workflow

Take the enquiry example. The form receives a submission, the workflow checks the required information and creates a record in the place your team uses.

Then a notification tells someone there's a new enquiry waiting. If a summary would help, it can be drafted alongside the original message, so the person replying can check the source.

Now ask the less interesting questions.

What happens if the submission is sent twice? What if the destination system is unavailable? Who gets told if the record wasn't created?

Those details are part of building the automation. A demonstration with one perfect submission doesn't prove the process is ready for normal use.

Keep the data and access proportionate

The workflow should use the information it needs and the access required to do the job.

Before connecting services, understand where the information will go and whether those tools are appropriate for it. Customer messages may contain details you didn't expect, which matters if you're considering sending them to another service for processing.

Someone also needs to own the workflow. If an account connection expires or a form changes, who checks it? A small automation still needs a person who knows it exists.

Write a modest first brief

Try completing this sentence: “When this happens, I want the system to do this, and tell this person if it can't.”

Then add where the information starts, where it needs to end up and what still needs a human decision.

That gives a developer something concrete to assess. We can work out whether the connection is possible, what the awkward cases look like and whether the likely benefit justifies the work.

After it's running, compare the real process with the old one. Count the checking and fixing as well as the time saved. If it helps, build from there.

You don't have to automate the whole business to stop copying the same information between two screens.

A modest first brief

When this happens, I want the system to do this, and tell this person if it can’t.

Trigger

A valid enquiry arrives.

Desired action

Create a record and notify the right person.

Exception owner

Who gets told if the record was not created.

Human review

What still needs a person before anything is sent.