Why AI Marketing Projects Fail in the First 90 Days

A note on the numbers

You will see confident statistics claiming that most AI projects fail. We have not found a reliable figure for AI marketing projects specifically, so we do not give one. The closest widely cited reference is a prediction, not a measurement: a Gartner press release of July 2024 was headlined with the prediction that 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, and Gartner named poor data quality, inadequate risk controls, escalating costs and unclear business value as the causes. Those four causes are a useful lens. Each of them shows up, in marketing form, in the patterns below.

Days 1 to 30: starting without the ground under you

Tool first, outcome second

The project begins with a purchase: a content platform, an agent builder, an AI add-on for the CRM. The question of what number it should move comes later, if at all. By day 30 the team can describe what the tool does but not what it has changed.

No baseline

Nobody recorded how long the work took, what it cost or what it produced before the project began. Any later claim of improvement is a guess, and the first sceptical question from a finance director ends the conversation.

Context that lives in people's heads

The tool is given a few lines about the business and produces generic drafts. The team concludes that "AI is not good enough for us" when the real gap is that nobody wrote down the offer, the customer and the proof.

Days 31 to 60: volume without control

Output nobody has time to check

AI produces drafts far faster than people can review them. Either a backlog forms and the project feels slow, or the checks quietly stop and unreviewed work goes out. The second is worse, and it is where the first brand or accuracy incident usually comes from.

Optimising towards a broken number

Automated bidding or content scoring is switched on while tracking is still double counting or missing conversions. Reports improve while the business does not.

Scope creep

Early enthusiasm adds a second and third workflow before the first is proven. Now no single result can be attributed to anything.

Days 61 to 90: the value question arrives

Reports nobody reads

Weekly dashboards exist but no meeting uses them to make a decision. The project cannot show value because nobody is asking what the data means.

Costs rise faster than proof

Usage-based pricing, extra seats and integration work add up. Without a baseline and an outcome, there is nothing to set them against, and the project is cut at the next budget review.

The owner leaves or loses interest

The person who championed the project moves on. Nobody else knows how the workflows are configured or what they are meant to achieve.

Failure patterns, warning signs and prevention

Pattern	Early warning sign	Prevention
Tool first	Nobody can state the target number in one sentence	Write the outcome and baseline before buying anything
No baseline	Improvement claims use words, not before and after figures	Log time, cost and output for two weeks before starting
Thin context	Drafts could belong to any competitor	Write a context document a new hire could use
Unchecked output	Review backlog grows, or reviews stop being recorded	Cap volume at what can be checked; name the checker
Broken number	Platform conversions drift away from orders or CRM records	Reconcile tracking before switching on automated optimisation
Scope creep	A new workflow starts before the first has a result	One workflow until it has a measured outcome
Unread reports	The weekly meeting has no decision in its notes	Every review ends with one recorded decision
Cost creep	Monthly tool spend rises without a matching result	Track cost per output and set a ceiling
Single owner	Only one person can explain the setup	Document each workflow's input, output, outcome and exceptions

Run a pre-mortem before you start

A pre-mortem imagines the project has already failed and works backwards. It takes about an hour and it is the cheapest risk control available.

1. • Gather everyone involved, including whoever controls the budget and whoever will check the work.
2. • State the premise: "It is 90 days from now and the project has been stopped. What happened?"
3. • Write privately for five minutes. Each person lists every plausible reason. Writing alone avoids the loudest voice setting the list.
4. • Read the reasons out and group them. Most will fall into the patterns above.
5. • Pick the three most likely, and for each agree one prevention and one warning sign.
6. • Put the warning-sign checks in the calendar at days 30, 60 and 90, with a named person responsible for each.

Illustrative example: a team imagines failure and the top reason is "we could never prove it saved time". The prevention is a two-week time log before launch; the warning sign is the day-30 check finding no comparable log after launch.

What the projects that last have in common

They start narrow, with one workflow tied to one outcome. They have a baseline. They cap output at what people can check. They reconcile tracking before automating spend. And they hold a short weekly review that ends in a decision. None of this is sophisticated; it is simply the part that is easy to skip.

The readiness checklist tests most of these conditions before you commit money, and the health check tests them once a system is running.

FAQ

Is 90 days long enough to judge an AI marketing project?

It is long enough to judge whether the project is working as a process: baseline recorded, output checked, one workflow measured. Some outcomes, such as organic search growth, need longer to show in the numbers.

Should we restart or stop a project that is failing?

Look at which pattern caused it. If the cause was missing foundations such as baseline, context or tracking, fixing those and restarting narrowly often works. If nobody can name an outcome worth moving, stopping is the honest choice.

Who should own an AI marketing project?

Someone accountable for the marketing outcome, not only someone enthusiastic about the technology. They need the authority to say no to new workflows until the first one has a result.