Ease AIThe pattern repeats itself
Most AI pilots fail quietly. No press release, no post-mortem, no angry email to the consultant. The invoice gets paid, the tool gets built, and six months later it sits unused while the team goes back to doing things the way they always did.
I see the same four patterns. The technology is rarely one of them.
No baseline measurement
You cannot prove an improvement if you never measured the original state. Most pilots begin with a feeling: "This takes too long," or "We lose too many enquiries." The feeling is often correct. The number is missing.
If you do not know how long the task takes now, you will not know whether the automation saved time or simply moved the bottleneck somewhere else. If you do not know how many enquiries you lose now, you will not know whether the chatbot captured more or simply annoyed a different segment of your audience.
Measure first. Count the hours, the emails, the calls, the errors. Write the number down. If the pilot succeeds, you will need it to justify the next one. If it fails, you will need it to understand why.
No internal owner
Someone inside your organisation has to want this to work. Not tolerate it, not comply with it—want it.
If the pilot is handed to someone as extra work on top of their existing role, it will drift. If it is assigned to someone who was not consulted before the decision was made, it will be quietly undermined. If no one is named at all, it will be everyone's responsibility, which means it is no one's.
The owner does not need to be technical. They need to know the process being automated, have the authority to change how the team works, and have enough time protected to see the pilot through. Half a day a week is a reasonable floor. Two hours a month is theatre.
Automating the wrong step
The step that feels the most repetitive is not always the step that causes the most damage when it goes wrong. The step that takes the most time is not always the step that blocks everything else.
I have seen pilots automate data entry while the real problem was that three people were re-entering the same data because two systems did not talk to each other. I have seen pilots automate email responses while the real problem was that no one had defined what a good response looked like, so every reply was different and customers had to ask twice.
Automate the wrong step and you make a broken process faster. The process is still broken. Now it is just broken at scale.
If you are not certain which step to automate first, do not automate anything yet. Map the process end to end, find the constraint, and fix that. Sometimes the constraint is a person doing repetitive work. Sometimes it is a missing handoff, a unclear decision rule, or a tool that never worked properly in the first place. Workflow automation is useful when the workflow itself is sound.
Teams who were never asked
If the people doing the work were not consulted before the pilot was commissioned, the pilot will be designed for a process that does not quite exist.
The person answering the phones knows which questions actually get asked and which edge cases come up twice a week. The person processing the invoices knows which suppliers send PDFs that look like scans of faxes and which ones send structured data. The person writing the emails knows which clients need three followups and which ones reply in ten minutes or not at all.
If you design the automation without asking them, you will design it for the process as you imagine it works. That version is always tidier than reality. The automation will handle the common case beautifully and fail on the thirty percent of work that does not fit the template. The team will route around it, and six months later you will be paying for a tool no one uses.
Ask first. Show them the draft. Let them break it in testing. If they say it will not work, believe them.
The technology works fine
The tools are capable. A well-built chatbot can handle enquiries, route conversations, and escalate edge cases. A well-built workflow can move data between systems, trigger actions based on rules, and log everything for audit. A well-built assistant can draft emails, summarise documents, and pull answers from your own materials.
The models are reliable enough for production use. The platforms are stable. The integrations exist. The cost is measurable. These are not experimental technologies anymore.
But the technology cannot measure your baseline, assign an owner, choose the right step, or ask your team what actually happens when the process breaks. That part is not technical. It is organisational, and it is where most pilots fail.
When not to buy this
If you do not have a number for the current state, do not commission a pilot yet. Measure first.
If you do not have someone internal with the time and authority to own the project, do not start yet. Assign the owner first, and make sure they were part of the decision to proceed.
If you are not certain which step to automate, do not automate anything yet. Map the process, find the constraint, and confirm that automation is the right fix for that constraint.
If you have not asked the people doing the work whether the proposed automation will actually help them, do not spend the money yet. Ask them. If they say no, listen.
A $3,500 chatbot that no one wants is a waste of money. A $20,000 workflow that automates the wrong step is a waste of money. Saying no costs nothing.
Funding does not fix a bad pilot
Ontario businesses with 1 to 499 full-time employees can apply for up to $15,000 through the Digital Modernization and Adoption Plan programme, matched fifty percent, specifically to hire an external consultant to produce a digital adoption plan. The programme explicitly funds this kind of planning work. Ontario added $5 million to the programme on 20 May 2026, and applications are first-come first-served.
The grant is real and the money is available. But it does not fix the four patterns above. If you do not measure a baseline, assign an owner, choose the right step, or consult your team, the funded pilot will fail for the same reasons the unfunded one would have.
Use the funding to do the planning properly. Measure the baseline. Map the process. Identify the owner. Get the team involved. Then build the thing that will actually get used.
Start here
If you are considering an AI pilot and want to avoid these patterns, start with a conversation. I would rather turn away a project that will not succeed than take money for something that will sit unused.
You can request a scorecard to see where automation might fit, or look at pricing for the kind of project that makes sense once the planning is done. If you are in Burlington, Oakville, Hamilton, or anywhere else in Halton or the Golden Horseshoe, I work in person. If you are elsewhere in Ontario or across Canada, I work remotely.
The technology works. The question is whether the project is set up to succeed.