Playbook · fix workflow or automate instead
Fix the workflow or automate it instead? Name what is broken first
A broken process is a missing rule, missing data, a missing owner, or too much volume. Only the last one is an automation problem. How to tell which you have.
Lasse Pettersen
Fix the workflow first when the process is broken by a missing rule, bad data or nobody owning a step. Automate it instead only when the steps are already right and the problem is that a person repeats them too often. Software does not supply a rule, clean a record or take responsibility. It runs whatever it is given, every time, and a wrong process run by a machine is still wrong, only faster and with nobody watching. Most processes owners call broken are the first kind.
The useful question is therefore not “patch or automate” but “broken how”. There are four answers, and they point in different directions.
The four ways a process breaks
A missing rule. Two people do the same job two different ways, and both think theirs is correct. A quote goes out at one margin on Tuesday and another on Thursday. A refund gets approved by whoever picks up the email. The symptom is inconsistency, and the fix is a decision, written down: this is how we price a rush order, this is who approves a credit. Automation cannot make that decision. Asked to automate a process with no rule, a builder either guesses one or builds both versions, and you pay for the guess.
Bad data. The customer list exists in the accounting system and again in the CRM, and they disagree. The price list lives in a spreadsheet on one laptop and in a PDF that went to the sales team last spring. The symptom is rework: somebody spends part of the day correcting what arrived wrong. The fix is choosing one source of truth for each record and retiring the copies. An automation built on top of two disagreeing sources copies the disagreement faster, and the error rate goes up, not down.
No owner. A step happens when somebody remembers. Follow-up on an unpaid invoice, a callback to a customer who asked for a price, a certificate renewal. The symptom is things falling through, and the tell is that nobody can say whose job it was. The fix is a name against the step. This one is tempting to automate, because a reminder is easy software, but a reminder sent to nobody in particular is ignored by everybody, and an alert with no owner is noise.
Volume. The steps are right, the data is clean, somebody owns it, and it still eats the week because the same thing happens dozens of times a day. Orders keyed into two systems. Supplier invoices typed into accounting. Every new enquiry copied from the website form into the job tracker. This is the only one of the four that software solves, and it solves it well.
| Break | What you see | The fix | Automate it? |
|---|---|---|---|
| A missing rule | Inconsistency | A written decision | No |
| Bad data | Rework | One source of truth | No |
| No owner | Things fall through | A name per step | No |
| Volume | Hours a week on the same steps | A build | Yes |
Most processes that feel broken are a mix. The practical order is to clear the first three, then look at what is left. What is left is frequently smaller than the original complaint, and occasionally it is small enough that nobody needs to pay for anything.
What a patch actually looks like
A patch is not a project. It is usually an afternoon and a decision.
- For a missing rule: one page, in plain sentences, saying how the case is handled and who decides the exceptions. Pinned where the work happens.
- For bad data: pick the system that wins for each record, delete or lock the copy, and tell staff where the real one is.
- For no owner: a named person per step, and a shared list the owner checks at a fixed time.
None of that needs software, which is exactly why it gets skipped. It feels too simple to be the answer. It is often the answer, and when it is not, it is still the first half of one.
The patch is the first draft of the build
This is the part that saves money even when you do end up automating.
Every automation is a set of written rules, a list of systems and a list of exceptions. A builder quoting against a process that has not been patched has to discover those rules during the build, on your invoice, and usually discovers them by getting them wrong in testing. A process that has been patched and run by hand for a few weeks already has its rules on paper, its data in one place, and a short list of the cases that did not fit.
So run the patched version by hand first and keep a tally of everything it did not cover. Then read the tally.
- The tally stopped growing. The process is stable. It can be quoted precisely, and a precise quote is a cheaper one because the builder is not pricing uncertainty.
- The tally keeps growing, but the new cases are rare. Automate the common path and route the rare cases to a person. That is a normal design, not a failure.
- The rules are still being rewritten. Do not automate yet. Every rule change after a build is a paid change, and a process still settling will generate them for months.
- The complaint disappeared. The patch was the fix. Spend the money somewhere with volume.
When automating instead is the right call
Some processes do not need fixing at all. The rule is clear, the data is in one place, somebody owns it, and a person is still spending hours a week moving the same fields from one screen to another. Patching that achieves nothing, because nothing is wrong with it except the cost of the person doing it.
Take a building supply distributor in Vaughan whose orders arrive by email and are keyed into the order system and then again into accounting. If both systems agree on what a customer and a product are, that is a pure volume problem and a clean candidate for a workflow automation build in Ontario. The same distributor with two price lists that disagree has a data problem first, and automating it would post wrong prices twice as fast.
The build is not free to own afterwards, and that belongs in the decision too:
- It has to be maintained. When a supplier changes an invoice layout or a software vendor changes an export, the automation breaks and somebody has to notice. A build that fails without telling anyone is worse than the manual step it replaced.
- It has to have an owner. The same rule as the process. Somebody inside the business needs to know it exists, where its instructions are written, and who to call.
- It changes what personal information goes where. A process that moves customer or staff records into new tools falls under the PIPEDA compliance rules that reach AI in Canada, and those narrow which tools a build can use.
On this site a build runs $2,500 to $12,000, and ongoing monitoring is optional at $150 to $400 a month. Set that against the hours the volume actually costs, not against the frustration the process causes, because frustration is often the missing rule talking.
Three sorting questions
If you have a process you are about to spend money on, answer these before calling anybody, including me.
- Would two of your staff handle the same case the same way? If not, you have a rule to write, not a system to buy.
- Is there one place where the right version of each record lives? If not, fix the data. Automation on two sources doubles the cleanup.
- With the rule written and the data clean, is somebody still spending hours a week on it? If yes, that is volume, and volume is what automation is for. Ranking several volume candidates against each other is a separate job, covered in which processes to automate first in a small business.
A process can pass all three and still not be worth building, if the hours are small. A process that fails the first two is not ready no matter how many hours it costs.
Why most owners get this backwards
In the second quarter of 2026, Statistics Canada counted 19.2% of businesses in the country putting AI to work on their goods or services. Of the ones that were not, 40.0% told the survey it had nothing to do with their line of work. The survey does not say why. What I see when I sit down with an owner is that the first process picked for automation is the one that annoys people most, and that one is usually broken by a rule or by bad data, not by volume. The build goes in, the annoyance survives, and automation gets the blame.
The reverse happens too. A business decides AI is not for it, and meanwhile a clean, well-owned process is costing somebody a day a week of copying. That one was never broken. It just never got counted.
If enquiries are the process in question, the same sorting applies: an enquiry that sits unanswered because nobody owns the inbox needs an owner, and one that sits because there are too many to answer by hand is a case for lead response automation in Ontario.
Where an outside look helps
The sorting above is the whole method, and you can run it yourself. What is hard from inside is seeing which of the four breaks you have, because the people doing the work have adapted to all of them and describe the workaround as the process.
That is what an AI business assessment for an Ontario firm is for. It costs $999, it names which processes need a fix and which need a build, and a build with me later has the fee deducted. If you already know the process is clean and it is volume that hurts, skip it and ask for a quote on the automation build.