Pick one task. Prove it worked. Then repeat.

Start with a task, not a technology

Start by picking a single task. It should repeat, follow rules you can describe, and produce a result a person can check. If you cannot explain the task in a few sentences, it is too broad to automate well.

Write down how the task is done today, step by step. Include who does it, what they touch, and where the output goes next. That short description is the start of your baseline.

Example: a landscaping business gets quote requests by text, email, and web form. Each is copied by hand into a spreadsheet, then a follow-up goes out a day later. It repeats, the steps are clear, and a person can still check the result.

• Choose one repeating task, not a whole department
• Write the current steps in plain language
• Note who does it and where the output goes

Score the candidate honestly

Run the task through five questions. Does it repeat often enough to matter? Does it follow rules you can describe? Can you see the result and tell if it is right? Can you undo it if it goes wrong? Is there a safe place for a person to step in?

A task that repeats weekly but follows no clear rules is a poor first choice. A task with clear rules but no way to check the result is worse, because you will not know when it breaks.

Example: a dental office confirms appointments. Reminders follow a clear rule, the result is visible, and a person can call if something looks odd. That scores well. Deciding who gets an urgent slot does not, because it needs judgement.

• It repeats often enough to matter
• It follows rules you can describe
• You can see and check the result
• You can reverse it if it goes wrong
• There is a safe human fallback

What not to automate yet

Some work should stay with people. Anything that needs judgement about a person's situation, anything that could cause harm if it is wrong, and anything you cannot observe are poor candidates.

Also skip tasks you are about to change. Automating a process that is already being redesigned means building it twice. Fix the process first, then automate the stable version.

Example: a law office considers automating first replies to new enquiries. The reply depends on conflict checks and the type of matter, so a scripted answer could mislead. Better to automate the intake form and let a person write the reply.

• Keep decisions that need human judgement
• Avoid work that could cause harm if wrong
• Wait until a process is stable
• Do not automate anything you cannot observe

Set a baseline before you change anything

A baseline is how you know whether the change helped. Record it before you build. Keep it simple: how many items, how long each takes, how often something goes wrong, and how long people wait.

Measure for a fixed period, such as two or four weeks, so one busy day does not distort the picture. Write down how you measured, because you will want to repeat the same method later.

Example: a retail shop tracks how many order questions arrive weekly and how long staff spend answering them, for three weeks. After a change, it measures the same way. No baseline means no evidence, only opinion.

• Count items per week
• Note the time each one takes
• Record how often it goes wrong
• Measure over a fixed period
• Write down how you measured

Measure after, then decide

Once the change is live, measure the same way for a similar period. Compare the numbers. Look for what improved, what did not, and what new problems the change introduced.

A first automation should reduce one clear cost or delay. If it does not, adjust it or stop. Small, checkable steps beat a large project you cannot evaluate.

Example: a property manager automates maintenance request logging. Lost requests drop, but staff now correct bad entries. The fix is a clearer form, not a bigger system. The baseline is what makes that visible.

• Measure the same way after launch
• Compare against the recorded baseline
• Watch for new problems created
• Adjust or stop if it did not help

Keep the first step small

The best first automation is boring. It handles one task, runs on clear rules, and fails in a way a person catches. That keeps the risk low and the lesson useful.

Write the task down, score it, set a baseline, and pick the smallest version that helps. When it works, you have both a result and a method you can repeat on the next task.

• Pick the smallest useful version
• Keep the first project bounded
• Plan the second project from what you learn