0.3Identifying processes to automate
The essentials in 30 seconds
- Good candidate = repetitive, frequent, with clear rules, no subtle human judgement: copying, notifications, follow-ups, reports.
- Method: audit one week, quantify frequency × duration, and only automate what can be written as "when X, do Y, except if Z".
- Start with a quick win (high impact, low effort): frame well before building, otherwise you accelerate chaos.
Running mini-case — Lina audits her week
Lina, digitalisation officer in Oran, notes for a week everything she recopies by hand: registrations to the spreadsheet (20 minutes, twice a week), payment reminders sent one by one, and an activity report recompiled every Sunday evening. She prices each action as frequency × duration, discards the still-fuzzy report with changing rules, and chooses her quick win: copying registrations, simple and measurable. She frames it in one sentence before any build.
Standalone case for this section: it returns in the course, diagram, script and 48h challenge of section 0.3.
1. What makes a good candidate
The most profitable skill is not technical: it is spotting the right processes. A good candidate is a repetitive, frequent task with clear rules and no subtle human judgement: copying data from one tool to another, sending a notification with each new order, following up a client after X days, generating a weekly report. Conversely, a rare, fuzzy task requiring human expertise is a bad candidate. Lina highlighted the registration copying in green and the changing-rules report in red.
2. Audit and quantify
The method: audit your daily work. For one week, note the actions you repeat (copy-paste, manual updates, information transfers), estimate their frequency × duration, and spot those following an explicit rule: an identifiable trigger (form submitted, date reached), clear actions, a possible condition ("except if amount is low"). Lina framed her copying in one sentence: "when a form is submitted, create a row and notify, except if the file is incomplete".
3. Prioritise: the impact / effort matrix
Prioritise by time saved and ease of implementation: first the quick wins (high impact, low effort), which prove value and train you gently. Keep big projects for later, and never start with the most complex. Automating a poorly chosen — or poorly defined — process costs more than it returns: framing well before building is the key. If the process cannot be written as "when X, do Y, except if Z", first clarify and standardise it.
🔎 Concrete example — 🔎 Concrete example — Framing a task
"When a registration form is submitted (trigger),
create a row in the base + notify the team (actions),
except if the file is incomplete (rule)."
→ 2 times 20 min per week = estimated time saved.Reading: Lina holds her framing in one sentence: trigger, actions, rule, time saved.
Lesson: if you cannot write it as "when X, do Y, except if Z", it is too fuzzy.
Section vocabulary
- Process
- A sequence of repeated steps to get a result (processing a registration, following up a client).
Simple example: Lina describes her registration process: form, base, notification, archiving.
What it is not: a one-off action done only once.
Reflex: break each process into steps before automating it.
- Repetitive task
- Action redone regularly in identical form (copy-paste, notification, update) — the ideal candidate.
Simple example: Lina recopies registrations twice a week: the perfect copy-paste to remove.
What it is not: an expert decision that changes with each case.
Reflex: note for one week everything you repeat identically.
- Trigger
- Event that launches an automation (form submitted, new row, date reached).
Simple example: For Lina, the trigger is clear: a new registration form submitted.
What it is not: the action itself (the notification sent).
Reflex: name the trigger first in any framing.
- Business rule
- Explicit condition deciding behaviour ("if file incomplete then do not notify").
Simple example: Lina adds her rule: except if the file is incomplete, do not notify.
What it is not: a vague "it depends on context" never written down.
Reflex: write each rule as "if… then…" before building.
- Process mapping
- Representation of steps (inputs, actions, decisions, outputs) to analyse before automating.
Simple example: Lina draws her registration map in four boxes in her notebook.
What it is not: building directly in the tool with no prior analysis.
Reflex: draw the process on paper before opening Make or Zapier.
In practice — Hands-on — Spotting your best automation candidates
- For one week, note each repeated task (copy-paste, follow-ups, updates, transfers) in a notebook, like Lina.
- For each, estimate frequency × duration: how many minutes, how many times per month?
- Test the rule: can you write it as "when X happens, do Y, except if Z"? If not, it is too fuzzy.
- Rank by impact / effort and choose ONE quick win: major time saved AND simple to automate.
Ready-to-say script — pitching your quick win (30 s)
"I audited my week: copying registrations takes me twice twenty minutes, with a simple rule. I suggest automating it first: when a form arrives, we create the row and notify, except for incomplete files. It's our quick win, I frame it in one sentence and build it this week."
Say this with the frequency × duration figures; show the written framing sentence.
Copy-paste template — my framing card
TASK: _______________
FREQUENCY × DURATION (time/month): _______________
TRIGGER (when X): _______________
ACTIONS (do Y): _______________
RULE (except if Z): _______________
IMPACT / EFFORT: [ ] quick win [ ] big project [ ] discardSmall business / small budget
With no time to waste: a single framing card on the most repetitive task (invoices, follow-ups) — the rest waits for the first success.
SME Oran
Lina has each colleague in Oran fill in a framing card: the team compares time saved and votes for the shared quick win.
Freelancer
Alone: price the time saved in money (hourly rate × hours) to choose the most profitable quick win, not the most fun.
Fuzzy process
Unwritten rule or full of exceptions: first standardise on paper with colleagues, then automate the stable part — never the reverse.
✓ Best practices
- Audit your daily work and quantify frequency × duration.
- Start with a quick win (high impact, low effort).
- Clarify and standardise the process before automating it.
✗ Common pitfalls
- Automating a fuzzy or high-human-judgement task.
- Starting with the most complex project.
- Automating a chaotic process (it accelerates chaos).
Key takeaways
- Good candidate = repetitive, frequent task with clear rules, no subtle human judgement.
- Bad candidate = rare, fuzzy task or one requiring human expertise.
- Method: audit your daily work, quantify frequency × duration, spot explicit rules.
- Start with a quick win (major time saved + simple); frame well before building.
48h challenge — apply tomorrow
Audit 3 repeated actions from your week, quantify their frequency × duration, and frame just one in a "when X, do Y, except if Z" sentence: your quick win.
- I can tell a good candidate (repetitive, clear rule) from a bad one (fuzzy, human judgement).
- I priced 3 tasks as frequency × duration.
- I framed my quick win in one sentence with trigger and rule.
Frequently asked questions
Where do I start if I identified many tasks to automate?
Prioritise with a simple impact / effort matrix. Impact is time (or errors) saved; effort is implementation difficulty. Start with high-impact, low-effort tasks ("quick wins"): they prove value fast, train you gently and build buy-in. Keep big projects (high impact but high effort) for when you are more comfortable. Avoid starting with a complex, uncertain automation: a first quick success beats an ambitious project that stalls.
How do I know if a process is too complex to automate in no-code?
Beware of processes requiring lots of human judgement ("it depends on context"), with exceptions at each step, or whose rules are unwritten/unstable. If you cannot describe the process as "when X happens, do Y, except if Z", it is probably too fuzzy to automate as-is. Best practice: first clarify and standardise the process (make it explicit), then automate the stable part. Automating a chaotic process only accelerates chaos.
What is the best automation candidate?