पाठशाला Pathshala · ग्राहक Grāhak, The customer · Lesson 15 · Build
A voice-of-customer system that does not depend on memory
What customers tell a company arrives in five places and is remembered in none. Tag it where it lands, route it to an owner and review it monthly by people and by rupees.
Pathshala, The Founder Library · 11 October 2026 · 6 min read
Every week customers tell a company what is wrong with its product, in tickets, sales calls, WhatsApp messages and reviews. Without a system the company remembers the last angry message and the largest customer’s request, and calls the result a roadmap.
This lesson builds the system: the streams to collect, a tag list small enough to use, routing rules that put each signal in front of an owner, a way to count that weighs rupees as well as volume, and the monthly review that turns the count into a decision.
Memory is a system, and a biased one
Every company already has a voice-of-customer system. It is the founder’s memory, and it has three faults. It overweights recency, so last week’s outage feels bigger than a problem that has cost customers an hour a day for a year. It overweights volume, so the customer who writes four emails outranks the forty who quietly work around the same gap. And it overweights proximity, so whatever the sales lead heard on Friday reaches the product meeting and what support heard on Tuesday does not.
The fix is not to stop listening to stories. Jeff Bezos has said that when the anecdotes and the data disagree, the anecdotes are usually right, and that something is then wrong with how the data is measured. The same report describes his habit of forwarding a customer’s complaint to the responsible executive with a single question mark. The habit works because it is a routing rule: one story, one owner, one expectation of an answer. The system below makes that rule run without the founder.
Five streams into one place
List every place a customer’s words land. For most Indian startups there are five. Support: tickets, email and the WhatsApp Business inbox. Sales: call notes, lost-deal reasons and the questions prospects ask in demos. Research: interview logs from the [weekly cadence](/library/customer-development-does-not-stop-at-launch) and churn interviews. Surveys: the comment box under an NPS or satisfaction score, which the [NPS lesson](/library/nps-done-honestly) explains how to read. Public: Play Store and App Store reviews, Google reviews and social replies.
Bring them into one table, not one tool. The support desk can stay the support desk and the CRM can stay the CRM; what matters is that a weekly export or an automation lands every tagged item in a single sheet or database with the same columns: date, source, account, account revenue, tag, verbatim and link. Nielsen Norman Group calls the principle triangulation: using several sources of data so that, for example, a feature that analytics shows failing can be checked against what support records say users report about it. One stream is an anecdote. Three streams saying the same thing is evidence.
Treat what lands in the table as personal data, because it is. Strip phone numbers and Aadhaar or PAN details from verbatims before they reach the shared sheet, keep access to the people who need it and delete on the schedule your privacy notice promises; the [DPDP lesson](/library/dpdp-act-what-it-requires-of-your-product) sets out what that notice must say.
A tag list small enough to use
The tag list is the system. Too few tags and everything is “bug” or “feature request”. Too many and nobody tags consistently, so the counts mean nothing. The house rule of thumb is fifteen to twenty-five tags in two layers: a type (bug, how-to question, missing capability, billing, data request, praise) and a theme that names the part of the product or the job.
Build it the way the UK Government Digital Service’s Government as a Platform teams did, as their user researchers described in 2018. A product manager, a designer and a tech lead each tagged the same fifty tickets in a spreadsheet, compared their tagging, refined the categories and published one taxonomy. A researcher first logged tickets by hand every two weeks; the teams then created the tags inside the support tool, so that whoever replied applied the tag and a monthly report came out automatically. Anyone could propose a tag, and tags that produced nothing the team could act on were cut.
Copy all of it, and especially the last step. Tag at the moment of reply: the agent who answered the ticket knows what it was about, and a monthly clean-up by someone who did not never catches up. Review the list quarterly: merge tags that are always used together, split any tag that has grown past a fifth of all volume, and retire tags that have not changed a decision in two quarters.
For a billing product sold to distributors a first list might read: under type, bug, how-to, missing capability, billing and payment, data or export request, praise; under theme, login and access, item master, invoicing, GST and e-invoice, payments and reminders, reports, integrations, mobile app, language. That is fifteen tags, and almost every ticket takes exactly one of each. Write a one-line definition under every tag with one real example, and keep the list where agents see it while they reply. When two agents disagree about a ticket, the definition is wrong, not the agent; fix it the same week and tell everyone.
Routing: who sees what, and how fast
A tag that sits in a sheet until the monthly review is too slow for some signals. Write four routing rules and put an owner’s name against each. Data loss, payment errors or security: to the engineering lead and a founder within the hour. Churn risk, meaning a paying account says it is considering leaving: to the account owner within a day, with the verbatim. A missing capability from an open deal above a set value: to the product lead within a week, with the deal value. Everything else: into the table for the monthly review.
Routing is also how the customer learns they were heard. When a tag leads to a change, the system should tell everyone who raised it. A one-line message to the forty accounts that asked for bulk upload, sent the day it ships, is the cheapest retention work a company can do, and it is impossible without the account column in the table.
Count the people, then count the rupees
The monthly count has two columns that matter: how many distinct accounts raised a theme, and the annual revenue behind those accounts and open deals. Ranked by mentions, the loudest problem wins. Ranked by rupees, the problem of the largest customers wins. Neither alone is right, and the figure below shows how far apart they can be in a single month.
In the illustrative month, late login OTPs generate forty-one tickets and lead any ranking by volume. Exporting e-invoices for the customer’s chartered accountant generates six tickets and five sales notes, but the accounts and deals behind it are worth ₹38 lakh a year against ₹9 lakh for the OTP complaint. Ranked by both, e-invoice export leads. Weight a sales note as three tickets, on the reasoning that one stalled deal stands for a whole account, and by mentions the Hindi interface climbs to second.
The OTP problem still needs fixing, and probably by a different team: it is a reliability issue with an SMS provider, not a product decision. That is the other use of the count. It separates the work that must happen anyway from the bets that need choosing, and keeps the first from crowding out the second.
A complaint counted once by volume and once by revenue is a decision. A complaint remembered is an opinion.
The monthly voice-of-customer review
Sixty minutes in the first week of each month, with the product lead, the support lead, a sales lead and a founder. Read the top ten themes by accounts and by revenue, side by side. Read three verbatims for each of the top three, aloud. Choose one theme to act on, with an owner, a change and a date; record why the others were not chosen. Check last month’s choice: did its tag volume fall, and did the accounts that raised it get told? Retire or merge one tag if the list has grown.
Every quarter, compare the themes chosen with what shipped and with what the churn ledger says customers left over. When the three lists agree, the system is working. When they disagree, the tag list or the routing is wrong, and that is the first thing to fix.
The figures in the example are illustrative. The method is not: tag where the words land, route to a name and count twice.
Sources
- Holly Challenger, Daniela Victorino and Amber Westerholm-Smyth, How user support ticket analysis shapes what we do on Government as a Platform, GDS User research in government blog, 23 October 2018 — Three people tag the same 50 tickets; tags built into the support tool; monthly automated report; unused tags cut.
- Kathryn Whitenton, Triangulation: Get Better Research Results by Using Multiple UX Methods, Nielsen Norman Group, 21 February 2021
- CNBC, Why Jeff Bezos still reads the emails Amazon customers send him, 7 May 2018 — Anecdotes versus data; the question-mark forward, described at the Bush Center Forum on Leadership, April 2018.