Recover from a bad implementation and keep the customer

What a bad implementation looks like

A bad implementation usually does not begin with one dramatic failure. It shows up in small daily problems that pile up fast. Staff invent workarounds. Reports do not match. Simple tasks take longer than they used to. People lose confidence when the new system slows down normal work.

Some problems are clearly defects. Orders fail, data disappears, permissions block the wrong people, or integrations stop passing updates through. Call those defects.

Other complaints come from expectations that were never set clearly. A client might expect automation where the agreed scope only covered data entry. They might assume training included the full team when only managers attended. Those gaps still matter, but they need a different fix. If you treat broken features and missed expectations as the same problem, every call turns into an argument about blame.

Trust usually breaks before the contract does. Once the client feels they were promised one thing and got another, even a small issue starts to look like proof that the whole project is unstable. A two-hour reporting delay can feel much bigger than it is.

Say that out loud early. The client cannot rely on the system yet, and they cannot rely on your team until they see clear action. It is uncomfortable, but it moves the conversation away from excuses and toward repair.

Silence does the most damage. If your team goes quiet while checking logs, debating ownership, or waiting for a perfect answer, the client fills in the blanks. Most people assume nobody is in control.

Start recovery by describing what the client deals with each day. That gives both sides the same picture of the mess. Then you can separate defects, scope gaps, and trust damage instead of dumping everything into one pile.

What to do in the first 48 hours

After a messy launch, speed matters more than polish. If you wait for the next angry email, you give the client time to decide the project is drifting.

Call as soon as you confirm the rollout went wrong. Do not hide behind tickets or a long status note. A short call works better because tone matters. People calm down faster when they hear a real person take ownership.

Use plain language. Say what is broken, who is affected, and what your team is doing now. If reporting is wrong, say that. If users cannot finish a task, say that. Most clients handle a hard truth better than a soft excuse.

This is also the moment to stop making new promises. Do not agree to extra features, side fixes, or "while you are in there" requests. Recovery needs a clean boundary. Put new requests into a separate list and tell the client you will review them after the system is stable.

Set a reset meeting within one or two business days. Keep it short. You are not there to defend the old plan. You are there to agree on three things:

• what failed
• what gets fixed first
• who signs off on the reset plan

A simple example makes this clear. A company rolls out a new approval workflow, but staff go back to spreadsheets because one approval step is missing. In the first 48 hours, the team should call the client, admit the gap, pause new requests, and schedule the reset meeting. That alone can stop a week of confusion.

Your first win is visible control. The client should know when they will hear from you next, what changed today, and what stays frozen until the reset is done.

How to reset scope with the client

Scope talks fall apart when both sides use loose phrases like "almost done" or "just a few fixes." Replace that with a simple record of what was sold, what the client thought they were getting, and what the system does today.

You need one shared version of the truth. If sales promised custom reports, the client expected them in the first release, and the product only has exports, write that down exactly as it is. Do not soften it. Do not argue about intent.

A short working note is enough if it covers five points:

• what your team promised in proposals, calls, or email
• what the client expected by launch day
• what works now
• what fails now
• what is still missing

Use direct examples. "User can log in but password reset fails." "Dashboard loads, but the numbers are wrong for filtered dates." Specific lines lower the temperature because they replace blame with facts.

There will usually be gaps between promises and expectations. That does not always mean anyone lied. Sometimes the sales call was vague. Sometimes the client filled in the blanks on their own. Sometimes the team shipped a partial version and never labeled it that way. Your job is to sort the mess, not defend it.

Then split the work into two buckets. The first is recovery. Put anything there that blocks normal use, breaks a promised workflow, or creates daily support pain. The second is later work. That includes nice-to-have changes, extra reports, edge cases, and ideas that came up after kickoff.

Be explicit about what recovery does not include. If you leave that fuzzy, the client will assume every open issue belongs in the rescue plan.

Write down who approves the reset. One person on your side should own delivery. One person on the client side should approve scope, priorities, and sign-off. If six people can change the plan, the plan will keep moving.

If the project is badly off track, an outside advisor or Fractional CTO can help run this meeting and keep it factual. That helps most when trust is low and every sentence turns into a debate.

End the call with a short written summary: what recovery includes, what moves later, who approves changes, and the date of the next review. If the client can repeat that plan back to you in a minute, it is clear enough.

How to document the gaps

Recovery gets harder when every issue lives in a different email, chat, or meeting note. Put every gap into one shared document or spreadsheet and use the same format each time. People stop arguing about where the truth lives.

Each row should answer the same questions: what is wrong, who feels it, what happens because of it, and what needs to happen next. Simple language works best. "Sales reps cannot send quotes from mobile" is better than a technical note only your team understands.

A short structure is enough:

• issue name
• what the user expected
• what happens now
• business impact
• owner and target date

The impact line matters more than many teams think. Do not write "workflow error" if the real effect is "three support agents spend 20 extra minutes per order." When the client can see lost time, missed sales, or customer complaints, priorities get easier.

Proof keeps the list honest. Add a screenshot, short steps to reproduce the problem, or a direct quote from a user. One sentence can be enough: "I have to export this by hand every Friday." That kind of proof stops long debates and helps your team fix the right thing.

Group the gaps so the client can review them quickly. A practical split is urgent now, this week, and later. You can also assign each item to one owner on your side and one owner on the client side if their input blocks the fix. If nobody owns it, it will sit there.

Keep the list short enough to review live on a call. If you bring 70 items, nobody will decide anything. Merge duplicates, cut side comments, and move tiny polish requests into a later backlog. A recovery document is not a wish list. It is a working list of problems the client can scan, discuss, and approve in one meeting.

Build a plan the client can follow

A recovery plan fails when it looks like an internal task dump. The client needs one document that shows what is broken, who will fix it, when they can expect progress, and how they will confirm the result.

Start by turning every gap into a work item with a plain name. "Invoices fail when tax is edited" is better than "billing workflow defect." Each item should have one owner, one target date, and one test the client can watch or repeat.

Put the work in the order the client feels it. Fix the problems that block revenue, orders, support, or daily use first. Small polish changes can wait. Add one short reason beside each item so the client can see why one fix comes before another.

A shared plan usually needs five parts:

• the issue in plain language
• the person who owns the fix
• the target date
• the proof that the fix works
• the current client status

Keep dates honest. If a fix needs four days, say four days. Clients handle a tough timeline better than a promise that slips twice.

Do not stop at code fixes. Add the work around the fix too. If the team changed a screen, report, or approval step, schedule a short training session before you ask the client to sign off. Then set a retest date so they know when to try it again.

One visible document is enough. A shared sheet, ticket board, or short project page all work if the client can open it and understand it in under two minutes.

Add one follow-up checkpoint after sign-off. That call catches the small issues people miss on the first pass, like a report that exports in the wrong format or a user role with the wrong permission. Those details often decide whether the client feels relief or stays nervous.

Run training that solves real problems

After a bad implementation, training should clear up confusion, not fill calendar space. Users do not need a tour of every screen. They need to finish the work they do every day without stopping to ask for help.

Start with the tasks that cause the most friction. Ask users where they hesitate, where they make mistakes, and where they still fall back to old tools or side notes. In many teams, the trouble comes from a small set of repeat actions such as creating a request, updating a record, finding the right report, or handing work to the next person.

Teach the workflow people actually use

Build each session around one real task from start to finish. Use the same order, terms, and handoffs people see in daily work. If a team only needs four parts of the system, stay with those four parts. A short session that solves one problem beats a long demo that covers everything and sticks with nobody.

A simple session often works best:

• show the task once in full
• let a user repeat it live
• stop at the confusing step
• correct the process on the spot

Write down every open question during the session. Do not rely on memory afterward. If several people ask the same question, the process is still unclear or the product still needs a fix. Those notes also help the client see that the team is tracking problems carefully.

Keep guides current. When the team fixes a field, changes a label, removes a step, or adjusts permissions, update the guide right away. Old instructions create new support problems fast.

Then give users time to try the new flow on real work. After that, schedule a follow-up check-in. That second session often tells you more than the first because users now have real examples, real errors, and a better sense of what still slows them down.

A simple recovery example

A 20-person sales team rolled out a new CRM too fast. The system went live, but reps could not find two custom fields they used to qualify deals. Leads from the website landed in a shared inbox instead of going to the right owner, and account managers had no clear handoff from sales to onboarding. After one rough week, the client said the CRM was slowing everyone down and asked whether they should go back to spreadsheets.

The project lead stopped defending the launch and reset scope with the client. The team froze new requests for five business days and focused only on work that removed daily pain. They split the backlog into three groups: urgent workflow fixes, handoff problems, and later changes. That gave the client a clean line between "fix now" and "wait until the system is stable."

They also built a gap log. Before that, feedback sounded like frustration, not work. People said reports felt wrong or the setup felt messy. Once the team wrote each problem as a plain task, the conversation changed:

• add missing lead source and deal risk fields to every sales view
• route web leads by territory instead of sending all leads to one inbox
• add a required handoff note before onboarding starts
• fix the dashboard that used the wrong close date

By the end of week one, every complaint had an owner, a due date, and a status. The client stopped repeating the same objections because they could see progress.

Training came next. The first launch session had tried to cover the whole CRM in one hour, which helped almost no one. The recovery team switched to two short sessions built around real work. Sales reps practiced entering a lead, updating stage, and handing it off. Onboarding managers practiced picking up the record and checking the notes they needed.

For the next month, the team held a 30-minute follow-up each week with the client lead. They reviewed the gap log, closed finished items, and added only issues tied to real tasks. That regular rhythm calmed the account. People knew where to raise problems, when they would get an answer, and what would change next.

Mistakes that make recovery harder

When a project goes off track, teams often make it worse by trying to protect themselves. The client does not need a debate. They need clear fixes, dates, and proof that the same problem will not show up again next week.

One fast way to lose trust is to argue about who caused the mess. Internal blame might feel satisfying for five minutes, but it can cost you two weeks. If the client hears the vendor blaming their staff, or their staff blaming the vendor, confidence drops fast. Keep the discussion on facts: what is broken, who will fix it, and by when.

Another common mistake is hiding delays behind technical detail. Long explanations about integrations, permissions, or data mapping often sound like excuses when users still cannot do their jobs. A simple update works better: "The export still fails for finance users. We found the cause. We will test the fix by Thursday and confirm with your team the same day."

Scope also slips in quiet ways. A team changes workflows, reports, or handoff steps during recovery and calls it "part of the fix." That creates a second problem on top of the first. If anything changes beyond the agreed repair work, write it down and get approval before work starts.

Teams also damage trust when they close tickets before real users test the fix. Internal testing is not enough. The person who runs payroll, approves orders, or answers support requests needs to say, "Yes, this works in my normal day." Until then, the issue is not closed.

Training gets ignored too often. That is a mistake, especially after a rough launch. People who had a bad first experience will guess, avoid the tool, or create workarounds in spreadsheets. A short training session focused on the exact broken tasks usually does more than a long generic walkthrough.

Watch for these warning signs during recovery:

• status updates get longer, but the client gets less clarity
• new work starts before anyone approves the change
• tickets close based on developer checks alone
• users still ask the same how-to questions after "training"

Recovery starts to feel real when the client can see what changed, who tested it, and when users will get help.

Quick checks before you call it done

A recovery effort is only done when the client can feel the difference without your team standing beside them. If people still depend on workarounds, extra calls, or hidden know-how, the fix is not finished.

Use a short go-no-go check before you close the recovery plan. It keeps the team honest and prevents the same argument two weeks later.

• Ask the client contact to say the main fixes in plain words, from memory. If they cannot explain what changed, the message did not land.
• Watch a real user do the task that caused the pain. If they still need a prompt, a cheat sheet, or rescue from your team, keep the item open.
• Review every open issue and assign one owner and one date to each. No shared ownership, no vague "soon," no floating tasks.
• Put the next follow-up on the calendar before the call ends. A recovery plan loses force when the next checkpoint stays informal.
• Spend ten minutes with your own team and write down what failed in the first implementation. Capture the cause, not just the symptom.

The second point matters more than most teams admit. A dashboard may look fixed, but if the finance manager still cannot export the monthly report alone, you have not solved the problem that matters. Software can pass tests and still fail users.

Keep the proof simple. Save the list of open items, the dates, the owner names, and one short note on what the client can now do without help. That record protects both sides and makes the next follow-up easier.

When recovery is done, closure should feel boring. The client knows what changed, users can do the blocked work, and everyone knows who handles the rest. That is a better finish than a cheerful call full of loose ends.

What to do next

After the reset call, put everything on one page and send it the same day. Clients calm down when they can see what changed, what is fixed now, and what still needs work. If they have to piece that together from chat messages, meeting notes, and memory, trust drops again.

That summary should stay plain and specific. Include the new scope, the fixes already shipped, the training completed, the open issues, and the dates for each next step. Add names next to owners. A simple page often does more than a long report because nobody has to guess what happens next.

A short follow-up cycle matters just as much. Do not wait a month and hope the rollout settles on its own. Set a light rhythm for the next two to four weeks so the client sees steady progress and has a place to raise issues before they turn into new complaints.

A simple follow-up cycle often includes:

• one check-in at the end of each week
• one short status note after each fix or training session
• one place to log open issues and decisions
• one final review to confirm what is now working in daily use

Use those follow-ups to ask a harder question: does the client only need delivery help, or do they need leadership help too? A bad implementation often exposes bigger problems. The product may be unclear. The team may have no owner. Decisions may be slow, or nobody may be responsible for adoption after launch.

If that is what you see, say it plainly. Do not hide a leadership problem inside a delivery plan. Some clients need more than bug fixes and extra training. They need someone who can reset priorities, tighten product decisions, and guide the team through recovery.

In that situation, outside help can make the reset faster and less emotional. Oleg Sotnikov at oleg.is works as a Fractional CTO and startup advisor, and this is the sort of problem where that kind of support can help: scope is unclear, delivery is shaky, and the team needs one person to bring product and technical decisions back under control.

The goal is simple: leave the client with one clear document, a short review cycle, and a named person who owns the recovery.