पाठशाला Pathshala · ग्राहक Grāhak, The customer · Lesson 28 · Scale
Community as a listening post, not a marketing channel
A customer community run for reach becomes a noticeboard. Run for listening, it tells you what is broken, confusing or missing weeks before the same complaint appears on social media.
Pathshala, The Founder Library · 11 October 2026 · 7 min read
The first public complaint about a broken release is rarely the first complaint. It was usually posted a fortnight earlier in the company’s own community, in a thread nobody whose job it was to fix things was reading.
This lesson sets out how to run a customer community as an instrument for hearing the truth about the product: why most communities drift into marketing, who actually speaks in them and who does not, how to design the spaces so that problems surface, the weekly harvest that turns posts into decisions, and the escalation rule that catches a cluster before it reaches social media.
Why most communities end up in marketing
A community is usually started by the person who wants reach, so it is measured on reach: members, posts, event sign-ups. The 2025 CMX Community Industry Report finds marketing still houses the largest share of community teams, at 31 per cent, with customer success and support at 19 per cent, up from 8 per cent in 2022. Product feedback was the top business objective for only 6 per cent of respondents.
Those numbers explain what most communities feel like from the inside: launch announcements, webinars, a welcome thread and a few unanswered questions at the bottom. Nothing is wrong with marketing. The cost is that the one place where customers talk to each other about the product, in their own words and unprompted, is measured on how many people showed up rather than on what they said.
A listening post has a different owner and a different number. It sits with product or customer success, and it is measured on what it surfaces: issues found in the community before they appeared in support tickets or on social media, and the share of those that reached an owner within a week.
Who speaks, and who stays silent
Before designing anything, accept the distortion every community carries. Jakob Nielsen called it participation inequality: in most online communities 90 per cent of users never contribute, 9 per cent contribute occasionally and 1 per cent produce most of the content. He warns that the result is not representative of average users and that you almost always hear from the same 1 per cent.
Three corrections follow. Weight what you hear by who said it: a complaint from an account paying ₹20 lakh a year and one from a free user are both data, but not the same data. Lower the cost of speaking: Nielsen recommends making contribution easy and a by-product of use, which in a community means a one-tap “me too” on a thread, a reaction instead of a reply, and voice notes where your customers prefer them. Sample the silent majority separately: once a month, invite twenty members who have never posted to a short call or a two-question form, and compare what they say with what the regulars say.
The regulars are still valuable. They are your most engaged users, and engaged users notice first. Jason Lemkin’s observation on SaaStr that customers who complain still care applies here: a regular who complains loudly is telling you something before the quiet ones leave without saying it. The skill is to hear them without mistaking them for everyone.
Design the spaces so the truth surfaces
Structure decides what people post. A community with one general channel fills with whatever is easiest to post, which is usually praise or noise. Create a few spaces with plain names and a clear purpose. How do I: questions about using the product, which reveal confusion. Show your workaround: threads where customers share the spreadsheets, scripts and manual steps they use around your product; every workaround is a feature request with the specification already written. Something is broken: bug reports, answered by someone who can reproduce them. What I wish it did: requests, with a rule that each must describe the job and the last time it came up, not just the feature.
Staff it with people who can act. Every post in the broken and how-do-I spaces gets a human reply within one working day, from someone in support or product, not marketing. Say who works there in the space itself, with names. Customers post problems where they expect a fix; they stop posting where they expect a press release.
In India the community often already exists, in WhatsApp groups your customers run themselves: dealers in a district, clinic owners in a city, accountants who use the same software. You cannot own those groups and should not try. Ask to join a few as a named member, answer questions when asked and never sell. For your own groups, keep them small enough to read, by city or segment, with a moderator from the customer side. The lessons on [WhatsApp as a distribution channel](/library/whatsapp-as-distribution-channel) and as a product surface cover the mechanics; the listening discipline is the same as on a forum.
The weekly harvest
Listening that is not written down is not listening. Once a week one person reads every substantive post from the last seven days and tags it with one of six labels: bug, confusion, workaround, request, churn signal (a member saying they are evaluating something else, or have stopped using a feature) and praise with a reason. Each tag records the account, its annual revenue, the segment and a one-line quote.
Total the tags by revenue as well as by count. Twelve posts of confusion from small accounts and two churn signals from large ones are different priorities, and only the rupees show it. Send the top three items to named owners with the quotes attached, and add them to the [voice of the customer](/library/voice-of-customer-system) ledger alongside support tickets and interview notes so the same issue is counted once.
Close the loop in public. When something that started in the community ships or is fixed, reply in the original thread with what changed and thank the member by name. Nothing increases honest posting faster than members seeing that a post led to a change. Nothing kills it faster than a request thread with three hundred upvotes and no reply from the company in a year.
Every workaround a customer shares is a specification you did not have to write. A community built to collect them is worth more than one built to collect members.
Before it reaches social media
Set an escalation rule in advance, with numbers. For example: five or more members reporting the same problem within twenty-four hours, or any post about money taken twice, data shown to the wrong person or a service that has stopped, is an incident. The on-call engineer and the head of support are told within an hour; a named person replies in the thread within two hours with what is known and when the next update will come.
The point of the rule is speed and tone. A customer who gets an honest reply in the community has less reason to post the same complaint publicly, and a customer who does post publicly can be pointed to a thread that shows the company was already working on it. Do not delete critical posts unless they break the community’s published rules; members notice, and a deleted complaint usually reappears somewhere you do not control. To tell a problem worth fixing from a complaint worth answering, the lesson on [problems and complaints](/library/how-to-tell-a-problem-from-a-complaint) has the test.
A worked example: an accounting software community
A company selling accounting software to small firms runs a forum and a dozen city WhatsApp groups of chartered accountants who use it, about four thousand members in all. For two years the community reports to marketing and is measured on webinar attendance. Product reads it occasionally.
It moves the community to customer success and starts the weekly harvest. In the first month the tags show that the largest cluster by revenue is not a request but a workaround: firms exporting reports to a spreadsheet to reformat them for a common filing, a step the product could do. The fix ships in six weeks. In the third month the escalation rule fires on a Saturday morning when seven members report a sync failure after an update; the reply in the thread comes within ninety minutes and the fix by evening. The posts on social media that weekend link to the thread rather than to a complaint.
The weekly and quarterly rhythm
Every week: harvest and tag all substantive posts; send the top three by revenue to owners; reply in every thread whose issue changed status; check that every post in the broken and how-do-I spaces got a human answer within a working day. Every month: sample twenty silent members and compare their answers with the regulars’; review every escalation against the rule. Every quarter: report three numbers to the leadership team: issues first seen in the community, the share that reached an owner within a week, and the share of last quarter’s top items that shipped or were closed with a public answer.
If those three numbers rise while member counts stay flat, the community is doing its job.
The example is illustrative. Community survey figures are from the 2025 CMX report as published.
Sources
- CMX and Bevy, 2025 Community Industry Report — Marketing houses 31% of community teams; customer success and support 19%, up from 8% in 2022; product feedback the top objective for 6%.
- Jakob Nielsen, Participation Inequality: The 90-9-1 Rule, Nielsen Norman Group (2006) — 90% never contribute, 9% occasionally, 1% produce most content; feedback is not representative; make contribution easy.
- Jason Lemkin, on complaining customers, SaaStr (updated 2022) — Customers that complain still care; complaints are often deep engagement coupled with frustration.