Two teams walk into the same quarterly business review with two different answers to "why are customers churning." Support says it's the onboarding flow, because that's what tickets show. Sales says it's pricing, because that's what lost-deal calls show. Product says it's missing features, because that's what the NPS verbatims show. Nobody is lying. Each team is reading a different slice of the same customer base through a different channel, coded a different way, and calling it the whole picture.
That is what a fragmented voice of customer (VoC) programme actually costs: not a line item, but a recurring tax on every decision that touches the customer, paid in slower meetings, re-litigated debates, and findings that quietly cancel each other out.
What does "fragmented" actually mean in a VoC programme?
Fragmentation isn't the absence of a VoC programme. Most organisations past a certain size have plenty of customer data: support tickets, NPS surveys, sales call notes, churn interviews, app reviews, community forum posts. The fragmentation is structural, not a data shortage.
Three things typically break down at once:
Different coding, same underlying signal. Support tags a ticket "onboarding friction." Product labels a similar theme from interviews "activation problem." Sales calls it "time to value." These may be the same customer pain described three ways, but without a shared category structure, no one can tell whether it's one big problem or three small ones.
Different sample, same claim to truth. NPS verbatims skew toward customers engaged enough to answer a survey. Support tickets skew toward customers frustrated enough to complain. Churn interviews only capture people who already left. Each channel is a real signal and also a biased one, and fragmented programmes present each in isolation as if it were the whole customer base.
Different owner, same customer. When CX owns NPS, product owns in-app feedback, and sales owns win-loss, each team optimises its own channel and reports up through its own function. The customer experienced one continuous relationship; the organisation analysed four disconnected snapshots of it.
Only 22% of business leaders say their teams share data well, according to Zendesk's Customer Experience Trends research, and 82% say they would want to combine service data with customer feedback data if they could. The gap between those two numbers is roughly the size of the fragmentation problem in most organisations: broad recognition that unified feedback would be more useful, alongside structural reasons it rarely happens.
Where does the cost actually show up?
Fragmentation rarely appears on a budget line. It shows up as friction, delay, and quietly wrong decisions, which makes it easy to underweight until you look for it deliberately.
1. The re-litigation tax
When two teams bring contradictory findings to the same meeting, the meeting doesn't end in a decision. It ends in a follow-up: whose data is right, whose sample is bigger, whose method is more rigorous. That follow-up consumes another round of analyst time and another meeting slot, and it happens on a recurring basis because the underlying fragmentation was never fixed, only argued around this one time.
2. The loudest-voice-wins failure mode
Absent a single coherent evidence base, decisions gravitate toward whichever team tells the more compelling story, not necessarily the one with the stronger evidence. A sales leader with three vivid quotes from lost-deal calls can out-argue a research team with a systematic 200-response NPS coding pass, because the systematic version is harder to summarise in a sentence. Fragmentation doesn't just slow decisions; it changes which decisions win.
3. The blind spot compounding
A channel-by-channel view means every team optimises what its own channel shows and stays blind to what the others show. Product fixes the features NPS mentions most. Support streamlines the flows tickets mention most. If the actual driver of churn is a fourth thing that shows up faintly across all three channels but strongly in none, no single team's dashboard ever surfaces it. The signal was there. It was just distributed thin enough across silos that no one channel crossed the threshold to get noticed.
4. The repeated-research tax
Without a shared category structure, teams re-run research that has effectively already been done. A product team commissions a study to understand "why do enterprise customers churn," not realising CX already has 18 months of coded churn interview data sitting in a different tool under different category names. The research budget is spent confirming what already existed rather than extending it.
A rough way to size the cost for your organisation
You do not need a precise figure to make the case for consolidation internally. A defensible estimate across four components usually gets the point across.
| Cost component | How to estimate it | Typical range |
|---|---|---|
| Re-litigation time | Meetings per quarter where two teams present conflicting customer findings x average attendee hours x loaded hourly rate | Often the largest single line for mid-size orgs with 3+ feedback-owning teams |
| Repeated research | Studies commissioned in the last 12 months that substantially overlap with existing coded data from another team | Even one avoided study often justifies a consolidation project |
| Decision delay | Average days between "we have conflicting signals" and "we made a call," multiplied by the cost of delay for that decision type (e.g. a pricing change, a roadmap commitment) | Highly variable, but often the biggest indirect cost |
| Missed signal | Harder to quantify directly; proxy with churn or complaint volume on issues that existing fragmented data touched but no team acted on in time | Use as a qualitative argument, not a hard number |
Even a conservative pass through the first two rows, re-litigation time and one avoided repeated study, is usually enough to justify the analyst time it takes to consolidate a coding structure across channels. The build itself does not need to be complicated: see our step-by-step guide to combining customer insights across 8 feedback channels for the practical mechanics of running one stable category structure across interviews, NPS, tickets, and sales calls.
Why does fixing this usually stall?
If the cost is this visible once you look, why do fragmented programmes persist? Three reasons come up repeatedly.
Ownership is genuinely distributed, and that's not entirely wrong. Support should own the support relationship. Sales should own the sales relationship. The fix is not centralising ownership of every channel under one team; it's agreeing on a shared category structure each team codes into, while keeping channel ownership where it already sits.
Tool sprawl makes technical unification hard. NPS lives in one platform, tickets in another, call notes in a CRM, interviews in a folder somewhere. Unifying the analysis layer does not require unifying every source system, but it does require a way to bring the text out of each system into one consistent coding process, which is the part most organisations have not built.
Nobody owns the cost of not fixing it. Every individual team's dashboard looks fine from inside its own silo. The cost only becomes visible at the point where two teams' findings meet, and by then it reads as "we have different data," not "we have a systemic problem," so it never gets escalated as one.
What does a consolidated VoC programme actually require?
Not a single new source of data. A shared coding layer across the sources you already have.
One category structure, multiple channels. The same top-level categories (say, onboarding, pricing, reliability, support experience) get applied consistently whether the source is an interview transcript, an NPS verbatim, or a support ticket export, so a "pricing" finding from sales calls and a "pricing" finding from churn interviews are directly comparable rather than differently labelled guesses at the same thing.
Metadata that travels with the data. Segment, channel, date, and customer tier need to stay attached to every piece of feedback so you can ask "does this show up more in enterprise or SMB" without re-coding anything. Skimle's metadata analysis is built specifically for this kind of cross-tabulation.
Traceability back to source. When two teams disagree, the fastest resolution is opening the underlying quotes together, not re-arguing from memory. Two-way transparency, the ability to go from a finding back to its source and from a document to what was and wasn't coded, turns that resolution into a five-minute exercise instead of a week-long audit.
A cadence, not a one-off project. Consolidation projects that run once and then get abandoned as new data arrives simply re-fragment within two quarters. The category structure needs to be something new data gets coded into on an ongoing basis, not a retrospective analysis exercise.
For the full programme design, from data source selection through turning findings into decisions, see our guide to building a VoC programme that actually influences decisions. If NPS verbatims specifically are one of your fragmented sources, our guide to analysing NPS comments at scale covers the coding framework in more depth.
Frequently asked questions
How do I know if our VoC programme is fragmented?
The clearest sign is contradictory findings surfacing in the same meeting without a fast way to reconcile them. A second sign: if you asked five stakeholders "what's the biggest driver of customer dissatisfaction right now," and got five different answers each backed by a different data source, your programme is fragmented even if each individual source is well-analysed.
Does fixing fragmentation mean buying one tool for the whole organisation?
Not necessarily. It means establishing one coding structure that different channels feed into, which can sit on top of existing source systems (your CRM, survey tool, and ticketing system) rather than replacing them. The unification happens at the analysis layer, not necessarily at the data collection layer.
Who should own a consolidated VoC category structure?
Most organisations that get this right assign a small central insights function (sometimes one or two people) to maintain the shared category structure and metadata standards, while individual teams keep ownership of their channel and contribute coded data into the shared structure. Full centralisation of every channel under one team is rarely necessary and often politically unworkable.
How long does it take to consolidate feedback that's currently siloed across 4-5 channels?
Building the initial shared category structure and coding a first pass across existing historical data typically takes a few weeks for a small team using AI-assisted analysis, versus months of manual coding. Maintaining it going forward, coding new feedback into the existing structure as it arrives, becomes a much smaller recurring task once the initial structure exists.
Try Skimle for your VoC consolidation
If reconciling conflicting findings across channels is eating more analyst time than the research itself, it's worth seeing what one shared coding structure across your feedback sources looks like in practice.
Try Skimle for free and bring in data from two or three channels to test it.
Related reading:
- How to combine customer insights across 8 feedback channels without losing the thread
- Voice of customer research: how to build a VoC programme that actually influences decisions
- How to analyse NPS verbatim comments at scale
About the authors
Henri Schildt is a Professor of Strategy at Aalto University School of Business and co-founder of Skimle. He has published over a dozen peer-reviewed articles using qualitative methods, including work in Academy of Management Journal, Organisation Science, and Strategic Management Journal. His research focuses on organisational strategy, innovation, and qualitative methodology. Google Scholar profile
Olli Salo is a former Partner at McKinsey & Company where he spent 18 years helping clients understand the markets and themselves, develop winning strategies and improve their operating models. He has done over 1000 client interviews and published over 10 articles on McKinsey.com and beyond. LinkedIn profile
