A good share of the self-employed who would gain from automating don't, for a very human reason: they don't know what to expect. The word suggests a technical job — long, obscure, where you sign a cheque without quite understanding what you are buying. The reality is far more down to earth. Automating a task always follows roughly the same steps, and none of them requires you to be an expert in anything. Here is the full sequence, from the first question to the day the system runs on its own — so you know, before you start, exactly what you are getting into.
Step 1: choosing the right task
It all starts not with the technical part, but with a choice: which task to automate first. The good candidate is repetitive, stable, and takes your time without adding anything for anyone — data entry, filing, reminders. Ruled out from the start is anything that calls for judgement, anything that changes every month, and anything that happens three times a year. This choice is the most important step of all, because a good task badly automated remains useful, whereas a bad task perfectly automated remains a bad idea. It is also where an outside eye helps most: people often assume the tedious task is the right one, when the real candidate is another, quieter one. Choosing this first task well is the difference between an automation that wins you over and one that disappoints at the first bill.
Step 2: putting numbers on it
Before building anything, you price it. How many times a day the task comes back, how long it takes each time, what your hour is worth. Three numbers and a multiplication give its real annual cost. You add an estimate of what the automation would cost, build and upkeep included, and compare. This is where the project's fate is decided: if the numbers don't add up, you stop there, and that is already a useful result — you have just avoided a pointless expense. This step is exactly what our free diagnostic does, in two minutes, before any commitment. No later step makes up for skipping this one: without numbers, everything else is a bet.
Step 3: writing the process as it is really done
If the numbers are good, you move to the most underrated step: describing the task as it actually unfolds. Not as it should be done in theory — as it is done, with its exceptions, its special cases, its "except when". It is joint work: you know the task, we know which questions to ask. Often, this exercise turns up surprises — pointless steps repeated out of habit, or on the contrary an exception that changes everything and was forgotten. You cannot automate what has not first been made clear, and that is where half the work is done, before a single technical line. It is the step most people skip and the one that sinks the most projects: what isn't clarified before is paid for after.
Step 4: building a first simple version
Then comes the building, and it is faster than imagined because you don't try to do everything at once. You first build the core of the task, the simplest version that already adds value, without the rare cases or the frills. This first version is not the finished product: it is a working base you will be able to try on real cases. Building small first lets you check quickly that you are on the right track, and correct course before investing in the details. It is the opposite of the big project you discover finished and that doesn't do what you wanted. Seeing a first small version work, even a basic one, is also what gives the confidence to carry on.
Step 5: trying it on real cases
An automation is not judged on paper, but on real cases. You let it run on real data — your real orders, your real clients — and watch what happens. It is the moment when the unforeseen exceptions surface, and that is normal: no process lets itself be fully described on the first try. You adjust, add the missing cases, refine. This testing phase is what separates an automation that holds up in real life from one that worked only in the example. It asks for a little patience, and it is worth every minute spent on it. We have never seen a process that doesn't reveal at least one surprise at this stage; that is why it is not skipped.
Step 6: going live, and watching over it
Once the version is proven, you go live: it now runs on its own, for real. But going live is not the end — it is the beginning of the system's life. You set up a way to know if something goes wrong, so as not to rely on chance, and agree on who handles maintenance when the world around shifts. It is the step from "it works today" to "it will work a year from now". An automation delivered without that safety net always ends up failing in silence; delivered with it, it serves you for years without a thought. On the day it goes live, you don't celebrate the end, you launch something that will still have to work tomorrow.
A complete example, from start to finish
A concrete example ties all the steps together. Picture a physiotherapist who loses time every day confirming appointments by phone. Step one: the task is repetitive, stable and calls for no judgement — a good candidate. Step two: it takes about twenty minutes a day, which over the year adds up to many hours; the numbers add up. Step three: in describing how they do it, they uncover a key detail — some first-time patients need directions to find the practice, and that cannot be a generic message. Step four: the simple reminder for regular patients is built first. Step five: it is tried for a week on real appointments, and the case of the patient who replies to change the time surfaces — it is added. Step six: it goes live with an alert that reaches them if something fails, and they agree to review the system every few months. Result: twenty minutes a day recovered, a special case handled, and a physiotherapist who never touched a phone to confirm again. None of the steps was technical for them: they only answered questions and validated the result.
How long all this takes
For a simple, well-chosen task, the whole thing is counted in days, not months. The choice and the pricing take a few minutes each. Writing the process, a conversation. The building and the testing, the bulk of the timeline, depend on complexity — from a few hours for a single-piece automation to a handful of days for something more substantial. The projects we accept are almost all settled quickly, precisely because we turn down the ones that would become endless jobs. Small and fast is not a limitation: it is the format where automation delivers most.
What is asked of you
Your part is lighter than people think, but it is essential, and concentrated on two steps. When writing the process, you are the only source: nobody knows the task better than the person who does it. During testing, your eye decides: you are the one who says whether the result is right, because it is your trade. The rest — the building, the technical adjustments, going live — asks nothing of you but to be reachable for a few questions. You don't need to understand how it is made, only to confirm that it does what it should.
And if you prefer to do it yourself
These steps are the same whether you outsource or build the automation yourself with a visual tool. The difference is not in the path, but in who carries each stage. If you do it yourself, the step of choosing the task and putting numbers on it remains the most important, and remains where it is easiest to go wrong — the temptation to automate the tedious rather than the profitable makes no distinction between professionals and amateurs. Writing the process you will do too, if only for yourself, because building without having clarified it first leads straight to the house of cards. And testing on real cases is non-negotiable either way. Doing it yourself is perfectly possible for simple tasks; what does not change, whether you do it or someone else does, is the order of the steps. Skipping them is the recipe for the project that doesn't work, whoever it comes from.
Automating a process is no leap into the unknown: it is a sequence of clear steps, the first of which isn't even technical, and over which you keep control from start to finish. It all begins in the same place: putting numbers on a task to know whether it is worth automating. That is exactly what our free diagnostic does, in two minutes and with no commitment: four questions, a result on screen, and an honest answer — yes, no, or not yet. If the answer is yes, you will already know what comes next. And if it is no, you will have saved far more than two minutes.