How to Build a Voice of Customer Program: Steps & Examples (2027)

Leadership asked for "a VoC program," and nobody agrees on what that means. One person pictures an NPS survey, another wants a dashboard, and a third expects a monthly slide of customer quotes. This guide gives you a concrete method that runs in a spreadsheet before you buy anything. It covers nine steps, a 90-day rollout plan, a copy-ready template and a worked example. It also shows where a platform like BuildBetter takes over once ticket and call volume outgrows manual coding.

What Is a Voice of Customer Program? (Definition)

A voice of customer (VoC) program is a repeatable system for collecting what customers say across every channel, organizing it with a shared taxonomy, sizing it against business impact, and routing it to the people who make product, service and go-to-market decisions, with a record of what changed as a result.

A real program passes a three-part test that a survey alone fails:

• More than one source, including unsolicited feedback. Support tickets, call notes and loss reasons sit next to survey responses.
• A named owner and a fixed cadence. One person is accountable, and work happens weekly, monthly and quarterly on a schedule.
• A documented link from feedback to decisions. Every top theme gets a logged decision, and customers hear what you did about it.

The term comes from quality management and product development. Abbie Griffin and John R. Hauser popularized it in their 1993 Marketing Science paper "The Voice of the Customer," which described how to identify, structure and prioritize customer needs. Its roots go back further, to Quality Function Deployment (QFD), developed in Japan by Yoji Akao in the late 1960s, and to Noriaki Kano's 1984 model of customer requirements. Those early versions focused on requirements gathering. The modern version covers the full customer lifecycle: evaluation, onboarding, adoption, renewal and churn.

This guide is written for B2B SaaS product, CS and founding teams. Everything in it works in a spreadsheet with no budget.

Why Most VoC Programs Fail (What Actually Breaks)

Most VoC programs fail because of process gaps. Good intentions are rarely the problem. The same breakdowns show up again and again:

• The program is just a survey. A quarterly NPS score tells you sentiment moved. It doesn't tell you why, and it misses the customers who never answer surveys.
• Feedback lives in eight places. Sales hears objections on calls, CS logs churn reasons in the CRM, support tags tickets its own way and PMs keep notes in docs. Nobody can count anything across sources.
• Every team uses its own tags. "Reporting" means dashboards to one team and CSV exports to another, so themes can't be compared or summed.
• The loudest customer wins. One strategic account's request outweighs 40 small customers hitting the same bug, because nothing is sized by ARR, segment or frequency.
• Insights have no decision attached. A monthly themes deck gets presented, people nod, and the roadmap stays the same. Without action tracking, the program loses credibility within two quarters.
• The loop never closes. Customers who gave feedback never hear back, so response rates and goodwill decay.
• Nobody owns it. VoC becomes everyone's job, which means it's no one's. Coding falls behind after the first busy month.

The gap these failures create is old and well documented. Bain & Company's 2005 "Closing the Delivery Gap" research found that about 80% of companies believed they delivered a superior experience, while only about 8% of their customers agreed. Each step of the method below exists to prevent one of the failures above.

How to Build a Voice of Customer Program: The 9-Step Method

This method needs a spreadsheet, a shared calendar and about 4-6 hours a week from one owner. You don't need to buy software.

Step 1: Define the purpose and the decisions it serves

Write down 3-5 decisions the program must inform in the next two quarters. Examples: "what goes on the Q3 roadmap," "why we lose deals to competitors," "top drivers of churn in the mid-market segment." Rule: if a feedback source doesn't inform one of these decisions, don't collect it yet. Teams that start from decisions collect less, code faster and get the roadmap to change sooner than teams that start by connecting every source.

Step 2: Inventory your sources, solicited and unsolicited

Solicited feedback is feedback you ask for. It includes relationship surveys (NPS), transactional surveys (CSAT, CES), interviews, onboarding check-ins and beta feedback. Unsolicited feedback arrives without a prompt. It includes support tickets, sales and CS call notes, chat logs, review sites (G2, Capterra, TrustRadius), community and Slack channels, cancellation reasons and win/loss notes.

Score each source from 1 to 3 on volume, signal quality and ease of export. Start with 3-4 sources, and make at least two of them unsolicited. Interviews and unsolicited sources do different jobs. Griffin and Hauser found that 20-30 in-depth interviews per segment surface roughly 90% or more of customer needs, so use interviews to discover themes. Use tickets, calls and loss reasons to size them.

Step 3: Assign an owner and a cadence

Name one accountable owner, usually a PM, product ops lead or CS ops lead, plus one contributor per source. Then set a fixed rhythm:

• Weekly: intake and feedback coding (60-90 minutes)
• Monthly: synthesis and readout
• Quarterly: program review with leadership

Step 4: Build a customer feedback taxonomy

Use two levels. The first is a category: Bug, Feature request, Usability, Onboarding, Pricing/Packaging, Performance, Integration or Support experience. The second is a specific theme, such as "CSV import errors" under Onboarding. Every row also needs these fields: source, date, account, segment, ARR, lifecycle stage, sentiment, verbatim quote and link to the original.

Keep the taxonomy to 25-40 themes at launch. Review it monthly, and merge similar themes before you split any.

Step 5: Analyze and size

Count each theme two ways: by mentions and by unique accounts. Weight the counts by ARR and segment. Score severity separately from frequency, on a 3-point scale where 3 is a blocker and 1 is an annoyance. The Kano model helps here. A gap in a must-be requirement, such as missing SSO for enterprise buyers, is a severity 3. A missing delighter is not. Compare every theme's numbers against the previous period.

Paste this formula into your theme rollup:

Impact score = unique accounts × severity (1-3) × segment weight
Example weights: SMB = 1, Mid-market = 1.5, Enterprise = 2. In a sheet: =C2*D2*E2

A blocker hitting 5 enterprise accounts (5 × 3 × 2 = 30) outranks an annoyance hitting 25 SMB accounts (25 × 1 × 1 = 25).

Step 6: Distribute insights to decision-makers

Write a one-page monthly readout. It should list the top 5 themes, what changed since last month, 2-3 verbatims per theme and a recommended action for each. Then send each team its own cut:

• Product gets feature requests and usability themes.
• CS gets churn drivers.
• Sales gets objections.
• Marketing gets the language customers use.

Put the readout into meetings you already hold, such as roadmap review and QBR prep. Don't create a new meeting. Amazon's well-known "empty chair" practice works on the same idea: someone represents the customer inside the meeting where decisions are made.

Step 7: Track actions

Keep a decision log with these columns: theme, decision, owner, date, status and linked ticket. Every theme in the top 5 gets a decision, and "won't do, here's why" counts. Bain's Net Promoter operating model calls this systemic work the outer loop.

Step 8: Close the loop

Close the loop internally first: tell the CSM or AE who surfaced the feedback what happened. Then close it externally (Bain's inner loop) by telling affected customers when something ships or when the answer is no. Tag affected accounts in the spreadsheet so you can find them when the work ships. Here is a three-line template:

Hi [Name], a few months ago you told us [problem in their words].
We just shipped [change], which [what it does for them]. Here's how to try it: [link].
Thanks for pushing us on this. It changed what we built.

Step 9: Measure the program itself

Track a short list of VoC program metrics:

• Share of feedback coded within 7 days
• Number of sources connected
• Decisions influenced per quarter
• Loop-closure rate
• Time from theme detection to decision
• Movement on the outcome metric tied to each decision, such as churn, win rate or ticket volume

Intuit's "Follow Me Home" practice, where employees watch customers use the product in their own setting, is a reminder of what these metrics are for. They show whether the program changes behavior inside the company, not just whether it produces reports.

90-Day VoC Rollout Plan

Copy-Ready VoC Program Template

You can build this in about 10 minutes with three tabs:

• Feedback log: ID | Date | Source | Account | Segment | ARR | Lifecycle stage | Category | Theme | Severity (1-3) | Sentiment | Verbatim | Link to original | Coded by | Loop-closure tag
• Theme rollup: Theme | Category | Mentions | Unique accounts | Total ARR | Avg severity | Segment weight | Impact score | Prior-period score | Trend
• Decision log: Theme | Decision | Rationale | Owner | Date | Status | Linked ticket | Accounts to notify | Loop closed (Y/N) | Outcome metric

Worked Example: A 90-Day VoC Rollout at a 150-Person B2B SaaS Company

This is a hypothetical composite built to show the mechanics. The numbers are illustrative, not customer data.

Setup. The company has 150 employees, about 400 customer accounts and three segments: SMB, mid-market and enterprise. After two quarters of rising mid-market churn, leadership asks for a VoC program.

Owners. A senior PM owns the program at about 20% of their time. A CS ops analyst handles ticket and churn exports, a sales ops contributor supplies win/loss notes, and a support lead keeps tagging consistent.

Sources at launch.

• About 1,100 support tickets per quarter
• About 60 recorded CS and sales calls per month (coded from notes only at first)
• 31 closed-lost deals with loss reasons
• A quarterly NPS survey with about 120 responses
• Churn reasons for 18 churned accounts

Days 1-30. The PM publishes taxonomy v1 with 32 themes and runs a 60-day backfill. The backfill took about 14 hours. Sixty days of tickets came to roughly 730 items, and at about a minute each that is around 12 hours. The loss reasons, churn reasons and NPS comments added about 2 more.

Decision 1: SSO/SCIM moves up the roadmap. Of the 31 lost deals, 14 cited missing SSO or user provisioning, and most of them were enterprise deals. This is a Kano must-be gap. The decision log entry reads: Theme: SSO/SCIM | Decision: move from next half to current quarter | Owner: PM, Platform | Status: In progress | Ticket: PLAT-212.

Decision 2: Fix onboarding instead of building a new feature. Import errors appeared in about one in four tickets from accounts in their first 30 days. The same theme showed up in 7 of the 18 churn reasons. The team shipped a guided CSV import with a template and deprioritized a requested dashboard feature.

Decision 3: Decline a request and explain why. A vocal enterprise account pushed hard for custom workflows. Sized by account and ARR, only 3 unique accounts were behind it. The team sent a "not now, here's why" note and offered a workaround. Because the decline came with evidence, the account accepted it.

Day 90 readout. The PM shared the baseline metrics: 82% of feedback coded within 7 days, 5 sources connected and 6 decisions logged. Three outcomes are now being watched: mid-market 90-day churn, first-30-day ticket volume and enterprise win rate. The readout also flagged a problem. Call notes were too inconsistent to code reliably, so the richest source was still the weakest.

Takeaway: The program earned trust because every readout ended in a logged decision, not a chart.

Common Voice of Customer Program Mistakes

Most of these mistakes come from skipping a step in the method or doing it out of order.

1. Treating NPS as the program. A score is an outcome metric. It doesn't give you reasons.
2. Collecting everything before deciding anything. Volume without decisions creates a backlog, not insight.
3. Over-engineering the taxonomy at launch. With 120 tags, nobody codes consistently. Start small and merge often.
4. Counting mentions instead of accounts. One chatty customer can look like a trend.
5. Ignoring internal voice. Sales and CS conversations often hold the clearest "why," but they rarely get written down.
6. Letting the owner role rotate or dissolve. Coding consistency breaks quickly when the owner changes.
7. Buying a tool before the process exists. Software automates a program. It doesn't design one. No tool, including ours, fixes missing owners, undefined decisions or a leadership team that won't act on findings.
8. Never saying no. Loop closure includes declined requests. Customers read silence as "ignored."
9. Reporting themes without verbatims. Leaders act on customer words, not category labels.

VoC Program vs. NPS Survey: What's the Difference?

An NPS survey is one input to a VoC program. A quarterly survey on its own is a VoC program of one source. Net Promoter Score, introduced by Fred Reichheld in Harvard Business Review in 2003, asks customers to rate their likelihood to recommend on a 0-10 scale. Promoters score 9-10, passives 7-8 and detractors 0-6. NPS is the percentage of promoters minus the percentage of detractors, so it ranges from -100 to +100. (Net Promoter and NPS are registered trademarks of Bain & Company, Fred Reichheld and NICE Satmetrix.)

NPS is still useful for two jobs. It tracks relationship health over time, and it gives you a segmented list of detractors to follow up with in interviews. Pair it with Customer Effort Score where support matters. CEB research published in HBR in 2010 found that 96% of customers with high-effort service interactions became more disloyal, compared with 9% of those with low-effort interactions.

What Does It Cost to Run a VoC Program Manually?

The direct cost of a manual VoC program can be close to zero, but the owner's time grows with every source you add. Use this time model and adjust it for your own volume:

• Short ticket or survey comment: about 1-3 minutes to read, code and log.
• A 30-45 minute call: roughly as long as the call itself, or longer, to review and code from a transcript.

Example calculation. Take 300 tickets and 40 calls a month. Tickets cost 300 × 2-3 minutes, or about 10-15 hours. Calls cost 40 × 30-45 minutes, or about 20-30 hours. That adds up to 30-45 hours a month before any synthesis or readout work. That is a large share of one PM's month.

The spreadsheet total also leaves out some hidden costs:

• Coding drifts when two people tag the same theme differently.
• Exports have to be pulled and cleaned up every week.
• Backfills go stale and have to be redone.
• Every hour spent coding is an hour of PM time not spent talking to customers or shipping.

When You Need VoC Tooling (and When You Don't)

You need VoC tooling once manual coding can't keep pace with your sources. These thresholds are a reasonable guide:

• You don't need tooling if your program is one survey plus a few interviews a quarter. Manual coding is fine at that size, and doing it by hand teaches you the taxonomy.
• Manual coding starts breaking past roughly 200-300 pieces of feedback a month, or as soon as more than one person is coding and consistency drops.
• Manual coding clearly breaks once call recordings and support tickets are both in scope. Call review time grows in step with call volume, and transcripts are too long to tag by hand every week.
• Other warning signs: you find themes weeks after they start, you can't tie feedback to ARR without manual CRM lookups, and you rebuild loop-closure lists from scratch every release.

How to evaluate voice of customer tools

• Native sources: Does it support calls, tickets, surveys, CRM and Slack natively?
• Capture vs. analysis: Does it capture source data, or only analyze data you've already exported?
• Taxonomy control: Can you edit the taxonomy, or are the themes a black box?
• Account linkage: Does it link feedback to accounts and ARR?
• Traceability: Can every theme be traced back to the original verbatim?
• Outputs: Does it produce tickets, docs and emails, or only dashboards?
• Security: Does it have SOC 2 and similar certifications?
• Pricing model: Is it priced per seat or by usage? Check vendors' current pricing pages rather than third-party figures.

Tools that help

1. BuildBetter: best for unifying internal and external feedback. BuildBetter Tickets + Conversations imports support tickets, chats, surveys and community feedback through 100+ integrations, including Zendesk, Intercom, Freshdesk, Front, Help Scout, Salesforce, HubSpot, Typeform, Slack and G2. It keeps everything in continuous sync. It also captures calls directly, with a bot recorder, no-bot local recording or mobile recording, so your sales and CS calls sit next to tickets and surveys. Each signal is tagged against your own taxonomy with severity and account context. The output is a Jira or Linear ticket, a PRD or a loop-closure email, which covers Steps 7-8. Pricing is usage-based with unlimited seats, and BuildBetter is SOC 2 Type II and HIPAA-ready. Caveat: it isn't purpose-built for distributing enterprise surveys at very large scale. If your program is mostly high-volume surveys, look at a dedicated survey platform.

2. Zonka Feedback. A survey and feedback-collection platform for multichannel CSAT, NPS and CES surveys. It's a good fit for strengthening the solicited side of the program.

3. Survicate. A survey tool for in-product, website and email surveys. It's useful for targeted transactional surveys at lifecycle moments.

4. Birdie. A customer feedback analytics platform that consolidates and analyzes feedback such as reviews and support conversations.

Whatever you pick, keep the method. The taxonomy, owner, decision log and loop closure belong to you, not the tool.

Voice of Customer Program FAQ

What are the steps to build a voice of customer program?

There are nine steps:

1. Define the decisions the program serves.
2. Inventory solicited and unsolicited sources.
3. Assign an owner and a cadence.
4. Build a shared taxonomy.
5. Analyze and size themes by accounts and revenue.
6. Distribute insights to decision-makers.
7. Track actions in a decision log.
8. Close the loop with customers.
9. Measure the program itself.

Who should own a VoC program?

One named person should own it. This is usually a product manager, product ops lead or CS ops lead who is accountable for coding, readouts and the decision log. Each feedback source also needs one contributor. Shared ownership without a single owner is the most common reason programs stall.

How long does it take to launch a VoC program?

It takes about 90 days to reach a stable program. Plan 30 days for sources and taxonomy, 30 days to the first readout and decisions, and 30 days to embed the program in roadmap and leadership meetings.

What are examples of voice of customer data?

Common examples include support tickets, sales and CS call notes or recordings, NPS, CSAT and CES survey responses, user interviews, review-site comments, community posts, churn and cancellation reasons, and win/loss notes.

How do you measure the success of a VoC program?

Measure decisions influenced per quarter, time from theme detection to decision, loop-closure rate and coding timeliness. Also track movement in the outcome metric each decision targeted, such as churn, win rate or ticket volume. Survey scores alone aren't enough.

Can you run a VoC program without software?

Yes. A spreadsheet with a feedback log, a theme rollup and a decision log is enough for one survey plus a few hundred items a month. You'll need tooling once call recordings and support tickets are both in scope, or once volume passes a few hundred items a month.

Sources and Further Reading

• Wikipedia: Voice of the customer
• Wikipedia: Net promoter score
• Wikipedia: Kano model
• Wikipedia: Quality function deployment
• Griffin, A. & Hauser, J. R. (1993). "The Voice of the Customer." Marketing Science, 12(1).
• Reichheld, F. (2003). "The One Number You Need to Grow." Harvard Business Review.
• Dixon, M., Freeman, K. & Toman, N. (2010). "Stop Trying to Delight Your Customers." Harvard Business Review.

Make churn optional.

Your spreadsheet program proves the method works. BuildBetter keeps it running at scale. Every call, ticket, survey and Slack thread is synced, coded against your taxonomy and sized by account. Each top theme can then become a ticket, a PRD or a loop-closure email without a manual export.

Make churn optional. Book a demo →