Guide

How to get your business ready to automate anything

Automation projects rarely fail on technology. They fail because nobody wrote down what should happen in the awkward cases, or because the data was a mess, or because nobody agreed what success looked like. All three are fixable in a week, before you spend anything.

1. Map one workflow, end to end

Pick a single workflow and follow it from first contact to done and paid. Write down every step, every handoff, and every point where someone has to remember something.

Do it for real, not from memory. Most owners are genuinely surprised by the number of handoffs, and the surprise is the useful part.

What you are looking for: steps that happen every time, steps that only happen when someone remembers, and information that gets typed more than once.

2. Count how often things happen

Frequency times minutes is the whole business case, and memory is bad at frequency. A task that takes three minutes leaves no impression and can still be the biggest cost in the building if it happens forty times a week.

Keep a tally for one week. It does not need to be precise. It needs to be honest enough to rank things.

3. Write down the decisions nobody has written down

This is the step that actually determines whether a project ships on time.

Every workflow has awkward cases that experienced staff handle by instinct. What do we do when a request has no photos? When the job is outside our area? When someone asks for a discount? When it arrives at 11pm?

Nobody has written these down because nobody needed to. A system needs them written down, and waiting for the answers mid-build is the single most common cause of delay.

4. Find out where your data actually lives

List every place customer information is stored. Then answer, for each field, which system is the one that is right when they disagree.

That decision, which system is authoritative, is most of the work in any integration and almost never gets made explicitly. Making it before the build starts saves the argument later.

Also check the boring things: are there duplicates, are the fields consistent, does anything live only in one person's inbox.

5. Sort out access early

Credentials, admin rights, API access on the CRM, permissions on the ad account. This sounds trivial and routinely costs projects a week.

Do it in the first two days. It is the cheapest schedule improvement available to you.

6. Pick the number you will judge it by

Before anything is built, write down the current value of the thing you want to change. Response time. Hours spent on a task. No-show rate. Days to payment. Share of enquiries that get a reply at all.

Without a before, there is no after. And when the time comes to decide whether to do the next phase, that number is the entire conversation.

7. Decide what stays human

Draw the line deliberately rather than discovering it. Which decisions must a person make? Where does the system have to stop and escalate?

There are good commercial reasons to keep judgment with people, and in Québec there are legal ones too: a decision made exclusively by automated processing carries transparency and review obligations that a human-in-the-loop design simply avoids. The detail is in the Law 25 and AI guide.

What good preparation looks like

You are ready when you can hand someone one page per workflow that says: here are the steps, here is how often it happens, here is what to do in the awkward cases, here is where the data lives, here is who decides what, and here is the number we are trying to move.

That page is worth more to a build than any brief. It is also the first thing we produce with a client if it does not already exist, which is why the first days of an engagement are spent inside your operation rather than in a proposal.

FAQ

How long does this preparation take?
About a week of part-time attention for one workflow, and most of that is the tally in step two. It is not a project in itself.
Can we skip this and let you figure it out?
We will do it with you if it does not exist, and that is normal. But the answers in step three can only come from you, and how fast they arrive is usually what decides whether a build takes two weeks or five.
What if our data is a mess?
Nearly everyone's is, and it is not disqualifying. What matters is knowing where the mess is, so the build can clean it in one place rather than working around it in five.
Do we need to fix our processes first?
No, and trying to usually stalls everything. Automating a slightly messy process that exists beats waiting for a perfect one that does not. What you do need is clarity about what the messy process actually is.
What if we only have one person doing everything?
Then this is faster, because there is nobody to reconcile with. Small operations usually complete the whole exercise in an afternoon.