Which tasks should you automate first?

Look at what your team actually did last month, not at the org chart. Shared inboxes, calendars, ticket queues and spreadsheets tell you where the repetition is.

Then check each candidate against four questions:

1. Does it run at least weekly?
2. Would two people handle it the same way?
3. Does it start from a clear event? A form, an email, a date, a status change.
4. Can a system reach the data? CRM, inbox, booking system, accounting tool.

Four yeses make a strong first task. If the task fails on question two, agree the rule before automating. If it fails on question four, it may need a small data fix first.

Appointment reminders. Trigger: booking created → steps: send confirmation, send reminder the day before with a reschedule link, update the booking if they change it → output: fewer no-shows, no reminder calls.

Invoice chasing. Trigger: invoice passes due date → steps: polite reminder, second reminder a week later, alert the account owner after the final one → output: chasing happens without anyone remembering to do it.

Enquiry logging. Trigger: new form or email → steps: create or update the CRM record, tag the source and service, acknowledge, assign → output: no enquiry lives only in someone's inbox.

The weekly report. Trigger: Monday morning → steps: pull numbers from two or three tools, calculate, post a summary → output: the report arrives before anyone asks.

These are boring on purpose. Boring tasks have clear rules, which is why they automate cleanly and why nobody has got round to fixing them.

The biggest problem is usually big because it is tangled: exceptions, several departments, inputs in ten formats, a few people who each do it differently. Automating it first means a long build, a rocky launch and a team that loses faith.

A first project should be narrow enough to describe in one sentence: "Every booking gets a reminder the day before." It should succeed quickly and visibly. It also lays down the plumbing (connections to your CRM, inbox and calendar, data mappings, alerting) that the bigger project will need anyway.

Expand along two lines.

• Next step in the same process. After automating invoice logging, match invoices to purchase orders. After that, flag only the mismatches for a person.
• Same pattern elsewhere. If reminders work for appointments, use the same pattern for document deadlines or contract renewals.

Keep a ranked list of candidates and rescore after each build. Each new connection lowers the effort score of everything that touches the same system.

• Automating a broken process. A messy process becomes a fast messy process. Fix the rule first.
• Running several pilots at once. When something goes wrong, you cannot tell which change caused it. One at a time until stable.
• No owner for alerts. The automation fails on a Tuesday and nobody notices until Friday. Every workflow needs a named person who gets the alert.
• Skipping the parallel run. Switching off the manual process on day one leaves no safety net. Run both briefly and compare.

Say you run an interior design studio in New York with eight designers. Candidates the team suggests:

• An AI tool that generates mood boards from a client brief. Exciting, but the output needs heavy design judgement and the input varies wildly.
• Chasing suppliers for delivery dates on ordered furniture. Weekly, clear rule, data in a purchase tracker and email.
• Sending clients a weekly project update. Weekly, clear format, data in the project board.
• Logging client enquiries from Instagram, email and the website. Daily, clear rule.

Enquiry logging goes first (daily, simplest, protects revenue). Supplier chasing goes second (saves the most designer hours). Client updates go third, drafted automatically from the project board and approved by the lead designer before sending. The mood board idea stays on the list for later, once the studio has seen the simpler ones work and knows what it wants from it.

In our audits, every repeated process gets an hours figure and a score on return against effort. We name the first project, define success in one sentence and scope how it would be built. We also say what to leave alone for now.

When we build it, we start on real data, run it alongside the manual process until the outputs match, then switch over. Every workflow has an owner, an alert and a plain-English document. The connections built for the first project are designed to be reused for the second. For examples of where this sequencing leads, see the case studies, including an AI chief of staff built from connected calendar, inbox and meeting automations.