AI & Automation

Our Vendor's Implementation Stalled. Who Finishes It?

The software is paid for and the rollout stopped. Why it happens, what is usually left undone, and the four ways out with what each one costs.

Mauricio Esparza By ·Published ·2 min read
mithub.club
Short answer

Implementations stall at the boundary of the vendor's product: your data, your integrations, your process and your adoption. The four ways out are pushing the vendor, hiring the vendor's professional services, bringing in an independent implementer, or doing it internally. The decision turns on one question: is the remaining work inside their product or outside it?

The contract is signed. The kickoff happened. Then it went quiet, and now you are paying monthly for something nobody uses.

This is common enough to be a category of problem rather than bad luck.

Implementations stall at the boundary, not inside the product

Almost always, one of four things:

Your data was messier than the scoping assumed. Every statement of work is written against clean data. Nobody has clean data.

An integration nobody owns. Two systems that have to talk, through an API neither vendor documents for your case.

A process that was never written down. The vendor asked how it works, someone described how it should work, and the gap surfaced during configuration.

Adoption. The product is configured and the team does not use it. No vendor can fix this for you, and most do not try.

Notice that three of the four sit outside the vendor's product, where they have neither access nor mandate.

The question that decides your next move

Is the remaining work inside their product or outside it?

Write the list of what is left. Mark each line as inside or outside. The shape of that list tells you which of the four options below is yours.

The four ways out

1. Push the vendor. Right when the remaining work is genuinely theirs. Ask for a written list of scope, delivered, and remaining, with an owner per line. Even if you go another route, that document is the most useful thing you will get from this phase.

2. Buy their professional services. Reasonable for depth inside their product. Useless for anything outside it, and that is where the stall usually lives.

3. Bring in an independent implementer. The right answer when the remaining work is your data, your integrations and your process. Someone accountable for the outcome in your environment rather than for the software working.

4. Do it internally. Viable if you have a person with the time, the access and the decision rights. The reason this is rare is not skill. It is that the person who could do it already has a job.

What not to do

Do not buy a second platform to escape the first. The work that stalled is your data, your integrations and your process, and all three travel with you, plus a migration.

Do not restart the scoping from zero. Whatever exists has value. The first job of anyone who comes in is to inventory what is built and what it actually does, not to redesign.

How to brief whoever finishes it

Give them four things and the first week goes to work rather than to discovery:

  • The original scope and what was delivered
  • Access to the systems, on day one
  • The list of what is left, marked inside or outside the product
  • One person who can make decisions without a committee

What finished should mean this time

Not configured. In production, with a named owner, a runbook someone else has followed, an error route, and a business result you can verify by opening a record rather than by reading an execution log.

Agree that definition before anyone starts, because the vague version of done is how the first attempt stalled.

Frequently asked questions

Is it the vendor's fault?

Usually partly, and it rarely matters. Most stalls happen outside the product boundary, where the vendor has neither the access nor the mandate. Assigning blame does not move the rollout.

Should we ask for a refund?

Ask for a written list of what was in scope, what was delivered and what remains, before discussing money. That list is worth more than the refund, because it tells you exactly what still has to happen and who can do it.

How do we avoid this on the next purchase?

Ask what percentage of customers run the product without customisation, what their implementation covers and where it stops, and what customers usually end up building themselves. The answers predict this failure better than references do.

Can we just switch products?

Almost never the answer. The work that stalled is usually your data, your integrations and your process, and all three travel to the new platform with you, plus the cost of the migration.

Sources

  1. Building effective agents · Anthropic (accessed 2026-09-22)
  2. Handle errors gracefully · n8n Docs (accessed 2026-09-22)
  3. Why evaluate AI workflows · n8n Docs (accessed 2026-09-22)
AI & AutomationImplementationProcurement
Mauricio Esparza
Mauricio EsparzaGTM Systems Lead · Revenue Engineer · Founder of MitHub. Designs and runs revenue systems for multi-location businesses: AI voice campaigns, enrichment, CRM automation and attribution. Founded MitHub to teach the method in the open.

Part of AI & Automation on MitHub.

Keep going

AI & Automation

The Pilot to Production Gap in AI Projects

The pilot worked and the rollout did not. The six failures that sit between a demo and a production system, and what has to exist before the second unit goes live.

Read · 3 min →mithub.club
AI & Automation

How to Choose an Agentic AI Implementation Partner

Twenty questions that separate a partner who will reach production from one who will stall in your company, grouped by what each protects you from.

Read · 2 min →mithub.club
Revenue Engineering

We Do Not Want Another Platform. Can You Work With What We Have?

The most common question buyers ask implementation help, answered honestly: when your existing stack is enough, when it is not, and how to tell the difference before spending anything.

Read · 2 min →mithub.club
AI & Automation

When to Hire a Forward Deployed Engineer

The buyer's view of the forward deployed engineer: the problems that need someone embedded in your systems, how the engagement is scoped, and how to tell a real one from a consultant with slides.

Read · 3 min →mithub.club
Revenue Engineering

How to Choose a CRM Implementation Partner

What to ask an agency, consultant or contractor before signing: the four questions that predict the outcome, the pricing shapes and the clause that protects you if it ends badly.

Read · 2 min →mithub.club
Revenue Engineering

Who Owns an Automation After It Goes Live?

The question nobody answers when the build finishes: who monitors it, who fixes it when an API changes, who approves changes, and what happens when the person who built it leaves.

Read · 2 min →mithub.club