Voice of Customer

What customers say doesn't arrive through one door. It comes in as support email, as chat inside the product, as something a salesperson hears across a contract table and scribbles in a notebook, as a one-star app store review, as a post in a community forum. Every one of those channels exists to answer and close, so once the reply goes out the remark stays buried in that channel's own records. The record survives; it just never collects anywhere.

Product meetings then run on sentences with nothing behind them. Someone says customers have been asking for this a lot lately, and digging in reveals one account said it once last week. The other side of the table is no better off. Sales says the deal is lost without this feature, engineering answers that they built exactly that last time and nobody turned it on. Both people really heard what they heard, and neither knows the count. When the only evidence is volume and proximity, whoever sounds most urgent in the room wins.

The same request arriving over and over is part of this picture too. Something was requested six months ago, got built, and the customer who asked was never told, so they assume it doesn't exist and ask again while support answers again. Requests that were declined also vanish without a word, which teaches customers that speaking up changes nothing, and from then on they leave quietly. On the company's dashboard the inquiry count drops and everyone reads it as improvement.

Voice of customer turns scattered remarks into something countable in one place. What changes is not the volume of information but its kind. Once one person's anecdote becomes a figure with a count attached, it can be ranked. That is also why it is the cheapest way into product discovery, the work of checking whether something is worth building before building it. Instead of going out to ask something new, it uses what has already arrived.

The terms under voice of customer form a single group: the three components the activity is made of. They are not parallel items but three stretches of one loop, where a remark comes in, gets handled, and goes back out.

1. Feedback channel — the doors opinions come through. A support ticket queue where inquiries stack up one at a time, a feedback button planted inside the product, the free-text box on a net promoter score (NPS) survey that asks how likely you are to recommend on a zero-to-ten scale, notes sales and account managers take in meetings, app store reviews and forum posts are all channels. Each one carries a different speaker. Support hears from people blocked and angry right now, surveys are answered by people who find the product tolerable, and sales notes mix in remarks from people who aren't customers yet. Judge from one channel alone and only that channel's population shapes the product.
2. Feature request — the items that arrive in the shape of "please build this." They are awkward to handle because a request is not a problem but a solution the customer designed alone. Behind a request for a spreadsheet export there is usually someone retyping a month-end report by hand, and if that circumstance isn't written down the item never gets grouped with the similar request another customer filed. Peeling back one layer at intake, and recording what the person was trying to do when they got stuck, decides how every later step goes.
3. Feedback loop — the circuit where what came in gets acted on and the result is checked again. It closes only when you tell the customer who asked and that person says the problem is actually gone. Skip the reply and the first two stretches can run perfectly while the same request keeps arriving, and all the customer learns is that talking to this company changes nothing.

The procedure that actually turns the three has six steps. Many teams run it once a quarter; products with heavy inquiry volume run it monthly.

1. Collect — move every channel's records into one table. One row holds the original sentence, the date it arrived, which channel it came through, which customer sent it, and what plan they are on. Paste the customer's own sentence rather than a summary. The moment the person copying starts trimming, judgment mixes in, and later nobody can retrace why it was read that way.
2. Tag — mark each item with the product area, whether it is a request or a complaint, and which customer said it. Agree on the tag list before starting. Invent tags while tagging and different people use different names, which makes two quarters impossible to compare. More tags are not better either. Twenty of them and the tagger gets tired of choosing and picks whatever is nearest; three and half the items land in "other." Five to eight, drawn along product areas, survives a quarter.
3. Peel one layer — rewrite the request as a problem. "Please build a spreadsheet export" becomes "the month-end report takes two hours of retyping." Once that line exists, the export, an automatic report, and an integration with an outside tool become visibly one bundle.
4. Count — count items, but attach who said them. Twenty identical requests all from individuals on the free plan and twenty where four came from paying twenty-seat teams are entirely different numbers. When the request comes from an account that has already given notice, read it alongside the churn reason record.
5. Decide and build — feed the finished table into the prioritization meeting as an input. The table doesn't make the decision. Something the strategy says not to do now stays deferred at thirty requests.
6. Report back — tell the people who asked what happened. Tell them about what was declined as well as what was built. So few companies do the second that saying no often builds more trust than saying yes. The reply doesn't need to be long. Three lines carry it: the search problem you raised was fixed this month, the bulk folder move you asked for alongside it isn't happening this quarter, and here is why. A declined item needs its reason attached, or the next remark never comes.

The two steps whose absence shows are the second and the sixth. Collect without tagging and four hundred sentences sit in one document nobody opens; drop the report-back and the channels dry up slowly. A customer who has learned that speaking gets no answer stops writing, not complaining. If you want tidier opinions from a handful of large accounts, a standing forum like a customer advisory board is one way to get them, though customers enthusiastic enough to show up there differ from everyone else, so it never replaces the six steps.

"This isn't one account. Eleven came in this quarter, and four of them are teams over twenty seats."

Evidence that it's a recurring problem with revenue behind it, not an individual complaint.

"The request is a spreadsheet export, but what's behind it is the month-end report. Building the export doesn't make that work go away."

A proposal to look past the solution the customer supplied and at the problem underneath.

"Did we ever get back to the customers who asked for this last quarter?"

A check on whether results went back to the requesters — and if they didn't, the same inquiries are coming again.

Pagedeck had four doors and all four stacked up in different places. Support email sat in the tool Sofia used, notes from the in-product feedback button sat in an engineering database, sales meeting notes sat in each person's own document, and forum posts sat nowhere. Mia decided to move all four into one table once a quarter and fixed six tags up front: document editing, search and navigation, permissions and sharing, notifications, speed, and billing and plans. Because the split followed product areas, items landed in the same place no matter who tagged them.

The top item in the first quarter was one nobody predicted. Everyone assumed permission settings would lead, but the sentence that showed up most was about not being able to find a document again. It had been phrased so many different ways that it had never been grouped as one problem. Only after "search doesn't work," "the folders confuse me," and "I don't know where yesterday's document went" all landed under one tag did it add up to thirty-nine items.

Sofia added the records of the seven accounts that had canceled the previous quarter to the same table, and five of them carried that tag. Only then did Theo move search into the quarter's work, and Mia emailed every one of the thirty-nine requesters about what had changed. The next quarter that tag came to nine items. Grace's remark on seeing the table was short: it wasn't that nobody had heard these people, it was that nobody had counted them.

The most common mistake is reading the activity as a ballot box. Every request carries a count, so building the biggest counts first feels fair and rational. But the people who leave remarks are a very thin layer of the user base. They are mostly either heavy users or people who are furious right now, and the person who used the product indifferently and quietly stopped writes nothing at all. Follow the counts alone and the product keeps bending toward the tastes of the enthusiasts already inside, while the places where half-onboarded people got stuck never appear in the table. So treat the table as a candidate list rather than a ranking, and fill in the quiet departures separately from cancellation records and drop-off numbers.

The other common belief is that collecting is enough to keep it running. Attach a tool, open the channels, opinions accumulate on their own, and the job looks finished — the numbers do climb nicely for the first few weeks. The trouble is that "nobody reads the pile" arrives sooner than expected. Without tags, a document holding four hundred sentences is too daunting to open, and if no meeting ever cites it, support agents stop copying things over too. The place this activity stalls is almost never collection; it is sorting and replying. That's why running one existing channel's records all the way through classification beats adding channels. Four doors nobody opens change a product less than one door that gets read every quarter.