Most conversations about broken handoffs stop at the line between sales and customer success. That's where the obvious pain shows up: a rep gathers context, a CSM starts from zero, and the customer repeats themselves once.
But a panel on customer process mapping pointed out that the repetition doesn't stop there. Community, advocacy and education teams each run their own onboarding, and each one tends to ask the same discovery questions all over again, separate from whatever sales or CS already learned.
This used to be a minor irritation. The panel argued it isn't anymore, because customers and the people supporting them have far less spare time than they did even two years ago.
Why do customers get asked the same questions by every team?
Diana Gabroveanu made the point directly: alongside CS and support acting as the first line of onboarding, community teams invite customers into their own onboarding, asking them to learn how to participate, how to do advocacy, how to talk to peers. Each of these programs asks its own version of the same questions the customer already answered during the sales process or during CS onboarding.
Erin Felton framed the underlying issue as context that gathers carefully in one place and then fails to travel anywhere. She said failure points aren't concentrated in any single handoff, they're spread evenly across every one, which means adding more teams into the post-sale journey adds more places for that context to die rather than travel.
Why does this cost more now than it used to?
Gabroveanu's point was specifically about time. A couple of years ago, people might have had the spare hour to repeat their goals to a new team. Now, with everyone under pressure to do more with less time, that hour doesn't exist in the same way. What was a mild annoyance has become a real tax on the customer's attention, and on the account team asking for it.
This matters because community, advocacy and education programs are often positioned as value-adds, not obligations. If getting into them means going through another round of discovery, customers reasonably deprioritize them, or show up frustrated that they had this conversation already.
A narrower question: what does each program actually need to ask?
A useful exercise the panel implied, without naming it as a formal step, is for each of these programs to separate what it truly needs to learn fresh from what it's asking out of habit. A community team asking how a customer wants to participate is asking something new. A community team asking what the customer's stated goal was at signing is repeating sales and CS. The first kind of question earns its place. The second kind is the tax described above.
Does adding AI tools fix this, or make it worse?
The panel's answer was blunt: probably worse, if it's added without fixing the underlying disconnect first. Gabroveanu argued that most of what gets called an AI problem is really an old departmental disconnect that predates AI by a decade. Layering separate AI tools onto separate teams, where onboarding has its own tool, CS has another, and sales has a third, just adds a new layer of fragmentation on top of the old one.
Angela Sutton backed this with a figure from a Gartner survey: 62% of underperforming AI projects fail specifically because of bad data preparation. Her argument was that shared metrics and clean, common data have to exist before any AI layer gets added, otherwise the AI just automates the same silos faster.
The narrower, more useful role the panel described was recording and transcribing calls into a shared, searchable place, so that a new person picking up an account, whether in CS, community or education, can review the history instead of asking the customer to repeat it. Several video tools already do a version of this without extra cost.
Both Gabroveanu and Sutton were careful to add a caution here: AI-generated health scores and sentiment summaries can be far off from what actually happened on a call, and should be checked, not trusted blindly. Sutton's suggestion was to be specific about what you're extracting, such as a customer's exact words on a stated goal, rather than relying on a general sentiment score that may not mean the same thing to a CS person as it does to someone doing upsell.
- Separate AI tools per team with no shared data underneath
- Trusting a generic AI health score or sentiment summary without checking it
- Shared, searchable transcript library any team can check before a call
- Specific extraction: exact words on stated goals, named red flags
What to try first
Erin Felton suggested starting small: a pilot with one cross-functional group aligned around a single customer or customer set, sharing KPIs and milestones instead of working department by department. The idea is that the people involved keep their specific skills, sales, onboarding, community, but their responsibility is to one shared customer outcome rather than to their own department's checklist.
Angela Sutton's suggestion was to build a short, specific case study around one real customer's disconnect experience, showing where they got asked the same thing twice and what it cost, and use that story to get leadership aligned before trying to fix everything at once.
- Map who touches the customerList every team, including community, advocacy and education, not just sales and CS
- Check what each one asksNote where questions overlap with what's already on record
- Build one shared recordA searchable place with call history any new team member checks first
- Pilot with one accountAlign KPIs across the teams touching that one customer before scaling
This session's full discussion of where handoffs break down and where AI genuinely helps is covered in more depth on the session page. For the core sales-to-CS handoff zone specifically, the execution gap worksheet is built to map that one account. For a broader look at where AI helps a CS team and where it's just noise, see this related piece. The steps above line up with the practices laid out in customer success best practices.
Frequently asked questions
Which teams beyond sales and CS repeat onboarding questions?
The panel specifically named community, advocacy and education teams as running their own onboarding steps that often ask the customer the same discovery questions already answered elsewhere.
How can a community or education team tell which questions are worth asking again?
The distinction is whether the question is genuinely new to that program, such as how a customer wants to participate, or whether it's really repeating what sales or CS already learned, such as the customer's stated goal at signing.
What's a reasonable first step for a team trying to fix this?
The panel suggested a small pilot: one cross-functional group aligned around a single customer or account set, sharing KPIs and a common record of what's already been discussed, before trying to fix every team at once.
Keep reading
Stay in the conversation