Jump to section
Your phone buzzes. It's a Slack from your champion at the customer you've been implementing for six weeks.
"Hey – wanted to let you know, Friday is my last day. I've let the team know you'll be in touch about the project."
The project. The one that has twelve open tasks, a data migration scheduled for next week, and a go-live date the board is waiting on. The one that now has no owner on the customer's side.
If you've been in implementation or customer success for more than a year, you've probably lived a version of this. It is one of the few onboarding scenarios where the damage is immediate, the path forward is unclear, and the clock is ticking before the momentum evaporates. And it happens more often than most teams admit – roughly 30% of stalled implementations come down to exactly this, according to our internal onboarding data across hundreds of B2B implementations.
This post covers both halves: what to do right now if it's already happened to you, and how to make sure it never kills a project again.
What actually disappears when a champion leaves
It is easy to assume the problem is enthusiasm. The champion was excited about the software, drove the purchase, and now the internal cheerleader is gone. That stings, but it's not what sinks the project.
Two things disappear with a departing champion, and neither of them is motivation.
Context. The history of what was decided and why. Which integration path was chosen after three calls with IT. Why the go-live date was pushed from March to April. What the economic buyer said about phasing the rollout. Most of this lived in the champion's inbox and their head. When they walk, it walks with them.
Mandate. The internal authority that made colleagues prioritise the implementation work at all. The champion had it – maybe because they were the department head, maybe because the person who signed the contract told everyone to cooperate. When they leave, that mandate doesn't automatically transfer. The IT lead who was told "drop everything for this integration" now has a new boss who has never heard of your product.
The successor inherits neither. They open their laptop on day one to find a project they didn't choose, with a history they can't see, and a set of colleagues who no longer feel any pressure to cooperate. That is the problem the recovery play has to solve.
And it's why the fix is never more follow-up. Another "just checking in" email to an inbox that no longer belongs to anyone won't move anything.
Recovery: what to do when it's already happened
You just got the message. Here is the sequence that gives the project the best chance of surviving.
Confirm who has taken over – don't assume
The champion's email might say "Priya will take over from here." In practice, Priya might not know this yet. Or Priya knows and isn't happy about it. Or Priya is also leaving in three weeks.
Your first move is to get a real name attached to the project, from someone with the authority to assign it. That means going above the champion's level if you can – to the executive sponsor, the person who signed the contract, or the department head. A short, direct message:
"Really sorry to see [name] go – they were great to work with. Can you confirm who will own the implementation on your side going forward? We have a go-live date to protect and I want to make sure the right person has everything they need from day one."
This does two things. It gets you a real answer instead of an assumption. And it subtly reminds the executive that there is a project with a deadline that needs an owner – which is the first nudge toward re-establishing mandate.
Put the full project status in front of them – no call required
Your instinct will be to schedule a 30-minute handover call with the new person. Resist it.
The new owner just inherited a project they didn't ask for. Their calendar is already full with the job they actually applied for. Booking a call to "walk them through where things stand" asks them to invest an hour before they've decided whether to care. Some will take the call. Most will postpone it. And every day the call sits unheld, the project drifts.
Instead, send them a single link that shows everything in one place: the plan, the open tasks with owners and due dates, the decisions that have already been made, the files and forms that are in flight, and the go-live target. Make it something they can open on their phone between meetings and understand in ten minutes.
This is where a shared onboarding workspace earns its keep. In Valuecase, each customer gets their own branded Space – the single place that customer opens to get onboarded, holding the plan, tasks, forms, resources and project history behind one link, with no login required. When a champion leaves, the Space doesn't. A new stakeholder opens the link and finds everything: what's been decided, what's still open, who owns what, and what's due next. No recap call. No digging through forwarded emails. No "can you send me the latest version of the plan?"
That self-serve catch-up is the difference between a successor who shows up to the first call ready to discuss next steps and one who shows up needing a history lesson. The project can survive the first scenario. The second one kills it.
Re-establish the timeline – don't assume it survived
Your old champion agreed to a go-live date of April 15. The new owner wasn't in that conversation. They don't know why that date was chosen, what it was based on, or whether it's still realistic given that they're now two weeks behind on decisions the old champion was supposed to make.
Assume the timeline is broken until you've confirmed otherwise. Send the new owner a short note that names the original target, acknowledges the disruption, and asks for a reset:
"Our target go-live was April 15, based on the data migration completing by March 28. Given the transition, I'd like to spend 15 minutes this week confirming whether that still works or whether we should adjust it. No pressure either way – I'd rather have a date we can both commit to than one that's already slipped."
This gives them permission to be honest without feeling like they're disappointing you. It also re-anchors the project in reality, because a timeline that nobody has re-confirmed is just a number on a slide.
Re-sell the project to the successor
This is the step most teams skip, and it's the one that decides whether the project survives.
The new owner never bought your software. They didn't sit through the demos, didn't make the case to their boss, didn't spend months building internal consensus. From their perspective, this project is extra work that landed in their lap from someone who left. They have no emotional investment in its success, and they almost certainly have other priorities that feel more urgent.
Before they'll own it, they need the short version of what their predecessor already knew:
- Why the company bought it. The business pain that triggered the purchase, and the outcome the leadership team expects.
- What it costs if it stalls now. The contract is signed, the budget is spent, and the internal disruption has already happened. Walking away means eating the cost with nothing to show for it. Finishing means the disruption was worth it.
- What success looks like, concretely. Not "smooth onboarding." The specific result – "the support team handles tickets in the new system instead of email by May 1" – that makes the investment pay off.
- What's in it for them. This project is now part of their workload and their reputation. What does it do for their team? Does it cut manual work by half? Give their boss visibility they've been asking for? Make their department look good at the next quarterly review?
This isn't a 30-slide deck. It's a one-page summary or a 10-minute conversation. But it has to happen before the new owner will treat the project as theirs rather than as someone else's mess they've been asked to clean up.
The executive sponsor who signed the contract can help here. A short message from them – "this project matters to the business and I'm counting on you to get it live" – transfers mandate faster than anything you can say from the vendor side. Ask for it.
Prevention: multi-thread onboarding like a sales deal
Every account executive knows a deal with one contact is a deal at risk. They map the buying committee, build relationships with multiple stakeholders, and never let a single person be the only thread between your company and the deal.
Onboarding teams inherited none of that discipline despite identical exposure. Most implementations are built around one enthusiastic champion, and when that person disappears, so does the project.
The fix is straightforward: apply the same multi-threading discipline to implementation that sales applies to the deal. Four moves make it real.
1. Insist on two named owners on the project charter
Most onboarding plans have one "customer owner" field and one name in it. That's the vulnerability.
From day one, the project charter – the document that names who owns what on both sides – should require two names on the customer side. The primary owner (your champion) and a secondary owner who is looped into key decisions from the start, receives the same status updates, and can step in without a handover if the primary becomes unavailable.
This isn't a backup contact. It's a co-owner who has enough context to keep the project moving, not just someone who knows the champion's phone number. The customer onboarding roles and responsibilities that matter here are the champion and the executive sponsor – name both explicitly at kickoff, with real ownership assigned to each.
2. Ask the lottery question at kickoff
Here is the exact wording that works, borrowed from our internal onboarding playbook:
"One last thing before we wrap up – if you won the lottery next month and disappeared to a beach somewhere, who would step in and keep this project moving?"
It gets a laugh every time. Then the room goes quiet for a moment while the champion actually thinks about it. And then they name someone.
That name is your second owner. The question forces the champion to identify their successor out loud, in front of their team, before anything has gone wrong. It also surfaces gaps that would otherwise stay hidden: if the champion hesitates for ten seconds and can't name anyone, you've just learned that this project is entirely dependent on one person, and you caught it on day one instead of week six.
A well-run customer onboarding kickoff call is the natural place to ask it. The kickoff is already where you align on goals, map stakeholders, and lock the plan – adding one question to the agenda costs nothing and buys you a named backup for the life of the project.
3. Spread early validation across the actual users
Champions design the setup. End users live with the result. When those two groups never overlap, the implementation is a single point of failure disguised as a project plan.
The champion configures workflows based on assumptions about how the support team works. The support team sees the configuration for the first time at go-live and discovers it doesn't match their actual process. Now you're re-configuring during what was supposed to be week one of live operations, and the champion – the only person who understood why the original choices were made – is gone.
The fix is to pull validation forward and spread it across the team leads whose people will actually use the product. In the first two weeks, before configuration is locked:
- Have the support team lead walk through the ticket routing setup, not just the champion.
- Get the IT lead to confirm the integration architecture, not just nod at it in a slide.
- Ask the department head who'll manage the team using the product whether the reporting structure matches what's being built.
Each of those conversations creates a second person who understands a piece of the implementation. When the champion leaves, the knowledge doesn't leave in one lump – it's distributed across three or four people who each know their part.
4. Keep project context out of private email threads
This is the structural fix that makes everything else hold.
When the project's history lives in email threads between you and one person on the customer's side, a new stakeholder has no way to catch up. The decisions, the files, the open questions, the reasons the timeline looks the way it does – it's all locked inside an inbox they can't access and a person who isn't there anymore.
Move the project context into a shared space that both sides can see, from day one:
- The onboarding plan with owners and dates, kept current
- The decisions that were made and why (not just what was decided, but the reasoning – "we chose Option B because the customer's IT team uses Azure, not AWS")
- The open tasks and who's responsible for each
- The files, forms, and resources the customer needs to complete their side
This is where Valuecase's model creates an advantage that general tools don't. In Valuecase, each customer gets their own branded Space – a single link holding everything above, visible to both sides, with no login required. When a new stakeholder needs to get current, they don't book a call. They open the Space and self-serve.
Contrast this with what happens when implementation runs through internal project tools like Asana, Monday or Notion. Those tools do a fine job of tracking your team's work. But they're internal-only by design – the customer never sees them. Everything the champion knew about the project's status, history and open decisions was never in a system either side could read. It was in their inbox, and it left with them.
A shared onboarding workspace flips that. The project context lives in a place the customer already opens, not in a person who might not be there next month.
The signal: watch concentration risk like any other health metric
There is a pattern that shows up before a champion departure becomes a crisis, and most teams miss it because they're not looking for it.
When every task completion, every reply, every form submission and every check-in response on a project comes from a single contact, that's not an engaged champion. That's concentration risk. It is visible weeks before anything goes wrong if you're watching for it.
The simplest version: pull up your active implementations and count how many customer-side contacts have interacted with each project in the last 14 days. Projects with one – especially large or complex ones – are the ones to watch. Engagement tracking inside Valuecase makes this automatic: you can see who opened the Space, what they viewed, and whether activity has narrowed to a single person.
Treat it like any other health metric. A project with a single engaged contact isn't healthy – it's fragile. Flag it, have the conversation, and get a second name before the fragility becomes a crisis. The real cost of bad onboarding is highest when the damage is invisible until it's too late – this one is visible if you look.
FAQ
How common is champion departure during implementation?
Around 30% of stalled B2B implementations trace back to a champion leaving or being reassigned, based on internal data across hundreds of onboardings. It's common enough that teams should have a rehearsed recovery play, not improvise one when it happens.
What's the first thing to do when a champion leaves mid-implementation?
Confirm who has actually taken over – from someone with authority, not from the departing champion's forwarding message. Then put the full project status in front of that person in a form they can consume without scheduling a call. A shared onboarding workspace that holds the plan, decisions, tasks and files makes this possible; an email chain with the old champion doesn't.
How do you re-engage a new stakeholder who didn't choose the software?
Re-sell the project. They need to know why the company bought it, what outcome leadership expects, what it costs if it stalls, and what's in it for them personally. A one-page summary or a 10-minute conversation – not a deck, not a demo. The executive sponsor who signed the contract should reinforce the message internally.
Should I keep the original go-live date after a champion change?
Assume it's broken until confirmed. Ask the new owner for a 15-minute reset conversation where you can adjust the date honestly. A realistic date both sides commit to is better than an optimistic one that silently slips.
How do you prevent single-threaded implementations?
Four moves: require two named customer-side owners on the project charter, never one; ask the lottery question at kickoff to surface the backup out loud; spread early validation across the team leads who'll actually use the product; and keep all project context in a shared space, not in private email threads with one person.
Can general project tools prevent this?
Not reliably. Tools like Asana, Monday and Notion track your internal work well, but they're internal-only – the customer never sees them, so the project history the champion carried was never in a system either side could access. A shared customer-facing workspace keeps the context where it survives the person.
What does a shared onboarding workspace actually do here?
It holds the plan, decisions, tasks, files and project history in one place both sides can see, behind a single link with no login. When a champion leaves, the successor opens the same link and self-serves the full context. No recap call, no forwarded emails, no lost history. Engagement tracking also flags when a project has become dependent on a single contact before it becomes a crisis.
See how a new stakeholder gets up to speed in 10 minutes – book a demo of Valuecase or start a free trial.
