Practical guide · Quebec SMEs
How to choose the first process to automate in your SME.
The right first project is not the most spectacular process. It is the one that removes repeated friction, has clear enough rules and allows the team to verify quickly whether the solution works.
Before automating: specify the human result.
Automation is a way to move information, apply a rule or trigger an action. It does not decide what good service means for you. Start with a simple sentence: ‘When this event occurs, the right person must receive this information and know what to do.’
This sentence forces the team to name the trigger, responsibility and result. If it remains impossible to write, the process is probably not ready to be automated.
Step 1
Inventory repeated irritants.
During a normal week, note the tasks that require copying, checking, searching, reminding, renaming, transferring or confirming. Do not choose anything yet. Look for repetition and moments when the team says, ‘We have to remember to…’
Signs to be noted
- The same data is entered in several tools.
- An action depends on a personal reminder or inbox.
- A similar mistake comes back several times.
- A customer often asks for an update on their request.
- The owner must approve a foreseeable situation.
- A task increases almost directly with each new client.
Keep also rare but serious irritants. They are not always the best candidates for first automation, but they may require different control.
Step 2
Observe a complete cycle without correcting the story.
Follow a real request from beginning to end. Who receives it? Where does the information enter? Who processes it? Which tools are used? What happens when a field is missing, someone is absent or the customer changes their mind?
Avoid documenting the ‘ideal’ process at this stage. The goal is to see the real work, including the workarounds. They often explain why a generic tool is not enough or why an older automation is ignored.
Minimum form
- Observable trigger.
- Information required.
- Responsible person or role.
- Decision or rule applied.
- Action produced.
- Most common exception.
- Proof that the cycle is over.
Step 3
Compare candidates with the same grid.
A discussion without criteria often favours the most visible project or the person who speaks louder. Instead, use five simple dimensions, each rated from 0 to 3.
How often does the task occur?
How much effort, waiting or recovery does it create?
Are the rules and entries fairly stable?
What improves if the process becomes reliable?
Does the team control the tools, data and access?
The total does not make the decision for you. It compares assumptions and identifies why a process is a priority. A frequent and predictable candidate is often safer to start with than a rare case filled with exceptions.
Step 4
Decide what should remain human.
Good automation does not try to absorb every situation. It handles the normal path, recognizes its limits and routes exceptions to an identified person. Define the cases that must stop the flow: conflicting information, an unusual amount, a sensitive request, missing consent or a rule that cannot be applied.
If no one knows how to intervene, automation creates a new dependency rather than making the company more autonomous.
Step 5
Set the smallest useful version.
The first version must close one complete loop. For example: receive a request, validate essential fields, create a record, assign an owner and send a confirmation. A complex dashboard or multiple integrations can wait if they are not required to prove the process's value.
A clear perimeter contains
- a trigger;
- minimum data;
- a main rule;
- a visible result;
- a failure alert;
- manual recovery;
- a process owner.
Step 6
Test the system with cases that can break it.
Do not only validate the perfect scenario. Use missing data, unexpected value, duplicate, service failure, account without permission, and recovery after error. Also check what the client sees and what the team can explain.
Measure a small number of signals related to the initial problem: manual steps removed, pending files, detected errors, visible response times or number of status requests. Avoid announcing a gain before having a comparable and sufficiently stable measure.
Step 7
Document for the company to maintain control.
Automation without documentation remains tied to the person who built it. The deliverable must explain the trigger, tools, access, rules, possible errors, recovery steps, responsible people and how to disable the system safely.
Also keep the reason for important decisions. In a few months, this information will make it possible to distinguish a real constraint from a choice that can now evolve.
Ready-to-use summary
The Level Up decision grid.
1. The expected result is formulated in one sentence.
2. The actual cycle was observed from end to end.
3. The task is frequent enough to justify the effort.
4. The rules of the normal path are understandable.
5. Exceptions and human recovery are defined.
6. The first version closes a complete loop.
7. Access, responsibilities and data are controlled.
8. The test measures the initial problem, not just system activity.
If several responses remain uncertain, start by clarifying the process. This work is already an improvement, even if no automation is built.
Next step
You can apply this grid to two or three irritants and compare the results with your team. If the chosen process requires several tools, permissions or sensitive exceptions, a diagnosis allows to frame the solution before investing in development.