# The seven failure modes that kill AI builds inside six months: the diagnostic Source: https://getstartedwithai.net/tutorials/why-ai-automations-fail-uk-smbs Site: Get Started With AI Tagline: Build AI automations that actually run your business. Audience: solo professionals, freelancers, consultants and AI implementers in training Contact: hello@getstartedwithai.co.uk This Markdown companion is generated from the prerendered page for AI crawlers. # The seven failure modes that kill AI builds inside six months: the diagnostic Roughly 60 percent of AI automations built in UK small businesses are inactive within six months of going live. The reasons cluster around seven failure modes, and most are predictable from the way the project was scoped. Tally based on 120-plus implementation projects between 2019 and 2026. The seven below name the mode, give the early signal that catches it, and the fix that recovers the build. Run this checklist at the start of any new AI project to avoid building something that is going to be turned off in November. ## How to use this list - Read the seven modes once, in order. They are ranked by how often they appear, not how serious they are. - For an existing build, walk it through every mode and note which signals are present. - For a new build, treat the list as a pre-flight checklist. Five minutes per mode is the cost of avoiding the recovery work later. - Anything ticked needs a fix before the build ships. Most fixes take an hour; one or two take a day. ## Failure mode 1: bought the tool, skipped the workflow change A practice buys a £40-a-month AI tool, configures the default settings and expects time saved to appear. Nothing changes because nobody changed how the work happens. The tool sits unused after the second week. - Early signal: the build was bought before the workflow was written down. If you cannot describe the current process step by step, no AI tool will fix it. - Fix: pull the tool back, run the WIRE Audit step, document the workflow, then re-implement against the documented version. - Cost of the recovery: about a day. Cost of skipping it: the £40 a month plus the lost confidence that AI will work for you next time. ## Failure mode 2: no baseline, so no win was provable A build saves time but the firm cannot prove how much. After three months the partner asks if it was worth £500 to set up and there is no answer. The build gets dropped at the next budget review. - Early signal: nobody timed the manual process before the build went in. If you cannot say "this used to take 4 hours a week", you cannot defend the saving. - Fix: run the Time Tax calculation retrospectively against an estimated baseline. It is rough, but a rough number defends a budget; no number does not. - Future projects: every WIRE engagement starts with a baseline measurement before the build. The same rule applies inside an SMB. ## Failure mode 3: built for the partner, not the operator The partner buys the tool and is impressed by the demo. The bookkeeper or the assistant who actually runs the work hates it because the workflow does not fit how they think. They quietly stop using it. - Early signal: the operator did not sit in the build session. If the only person who knows how the AI is configured is the person who never uses it, the build is already breaking. - Fix: re-run the configuration with the operator. Let them set the defaults, the prompts and the review cadence. The partner approves the result; they do not author it. - Rule: the person who runs the work owns the build. Always. ## Failure mode 4: model output drifted, nobody noticed A build runs cleanly for six weeks. In week seven the underlying model is updated by the vendor, output quality drops 20 percent and nobody is reviewing the output. By week ten the build has been silently producing worse work for a month. - Early signal: no weekly sample review. The first month review has stopped happening. - Fix: a 10-minute Friday review of 5 random outputs against a written quality rubric. Logged in a Sheet. Drift shows up by week two. - See the WIRE Method Four Breaks Monitoring tutorial for the full version of this practice. ## Failure mode 5: data the AI relied on changed shape A build assumes a CSV export with 12 columns in a specific order. The accounting software updates, the export now has 14 columns and the order shuffles, so the build returns nonsense or fails silently. - Early signal: no schema test on the input. The Zap or scenario assumes the data shape never changes. - Fix: add a schema-check filter at the start of the run. If the column count or names do not match what the build was scoped against, halt and alert the operator. - Common offender in UK practices: bank feed CSVs, where the format changes when the bank updates its statements UI. ## Failure mode 6: nobody but the original builder could run it A consultant configures a clever build. Six months later they have moved on. A small change is needed and nobody at the firm knows the password to the workflow tool, the GPT instructions or the Sheet structure. The build dies the day it needs maintenance. - Early signal: no documentation, no shared access, no named owner inside the firm. - Fix: the WIRE Bus Test. If the original builder went under a bus, could the firm still operate the build? If the answer is no, write the runbook before anything else. - A 2-page runbook plus a shared admin login is the difference between a build that lasts a year and one that lasts a fortnight. ## Failure mode 7: built on a free tier that hit its limit A Zapier free tier runs out of tasks at the worst possible moment. A ChatGPT free tier rate-limits a high-traffic day. The build fails just as the firm has come to depend on it. Trust drops; the build is shut down. - Early signal: the build was scoped to a free tier even though the volume forecast was above the free quota. - Fix: budget the tooling cost at the start. Most production SMB builds need a paid tier of every tool involved. £100 to £200 a month total is normal; treating it as zero is the failure. - Rule: free tiers are for prototyping. The production build is on paid tiers from the day it goes live. ## What you ship A pre-flight checklist that catches every failure mode before the build goes live. The WIRE Method exists to catch every one of these before the build ships. Audit names the workflow in writing, Identify ranks by Time Tax with a baseline, Run picks the smallest viable build with a named owner, Embed adds the monitoring and the runbook. A build that goes through all four steps almost never lands in this failure list. ## What to build next Run the wire-method-monday-morning-test on your top automation candidate next. The 15-minute diagnostic catches modes 1 and 2 before any tool is bought. After that, the wire-method-time-tax-calculator gives you the baseline that defends mode 2. ## Related builds More tutorials in Operations. Each one runs in 60 to 90 minutes and ships a finished asset. ### Document an SOP in 30 minutes: the AI build that captures process before automation 30 to 60 minutes. Implementer. [Open tutorial](/tutorials/sop-ai-capture-build) ### Generate the next quarterly report on autopilot: the AI reporting build 60 to 90 minutes. Solo Pro / Implementer. [Open tutorial](/tutorials/ai-quarterly-reporting-build) ### Run a Bus Test on every running automation: the AI build for governance light 60 to 90 minutes. Implementer. [Open tutorial](/tutorials/ai-governance-light-bus-test) ### Stay GDPR-clean while shipping AI: the compliance build for solo and small firms 90 minutes. Implementer. [Open tutorial](/tutorials/ai-gdpr-compliance-build) ## Questions people ask before they start ### What is the most common reason AI projects fail in small businesses? Failure mode 1 is the runaway leader. The tool was bought before the workflow was written down. Skipping the audit step is the single largest predictor of a build that does not last six months. ### How long before a typical AI build either pays back or fails? The decision point is around 90 days. By day 30 the build should be running. By day 60 the operator should be using it without prompting. By day 90 the time saving should be visible on a calendar review. If any of those three checkpoints is missed, the build is in trouble. ### Can a failed AI build be recovered? Often yes, by re-running it through the seven failure modes above. The most recoverable cases are 1 (workflow not documented) and 6 (no runbook). The hardest is failure mode 3 (built for the wrong person) because it is a culture problem, not a tooling problem. ### Do these failure modes apply to enterprise AI projects? The shapes are similar but the scale is different. Enterprise projects have additional failure modes around procurement, security review and integration sequencing. The seven above cover roughly 80 percent of UK SMB cases. ### Where does this failure data come from? A working tally across 120-plus AI implementation projects between 2019 and 2026. The numbers are practice observation, not a published study; treat them as a working frame, not a benchmark.