Social Listening

What a company can see is only part of what gets said. Support tickets, app store ratings, and survey answers all arrived through channels the company built, and the people who use those channels are the ones with a reason to address the company directly.

The rest happens elsewhere. A community where people in the same job gather, a group chat inside a customer's office, a short post on a social feed. In those places people talk to each other with no intention of talking to the company. That makes what they say more candid than anything arriving through a support form, and it also means the company has no idea what it is.

Leaving it unknown means decisions get overturned outside the room. A buyer who has been evaluating for six weeks asks, in the final meeting, whether it is true there was a security breach. Checking turns out there was a breach at a company with a similar name, and a community post that garbled the two has been sitting near the top of search results for two months. Nobody inside the company had ever seen it.

Social listening is what you get when reading the outside conversation becomes a scheduled job rather than something someone notices by accident. Some teams run tools that watch for mentions of specific terms; some have a person walk a fixed set of communities on a fixed day.

It starts with deciding what to listen for and ends with a weekly summary. Six steps.

1. Build the term list. Product name and company name alone miss about half of it. Add the shortened way people say it, the typos that recur, competitor names, and phrasings of the problem that never mention you at all — something like "can never find where the meeting notes went" belongs in that last group.
2. Choose where to listen. Two or three job-specific communities, one or two social platforms, and app store reviews is enough to start. Some of the most useful places are visible only to logged-in members, which means no tool can crawl them and a person has to go look.
3. Collect. Terms loaded into a tool produce an alert when a new mention appears, and whatever the tool cannot reach gets walked by a person on a set weekday.
4. Sort into three buckets: things that are factually wrong, complaints, and praise or usage tips. This sorting is what determines the next action.
5. Decide the response rules in advance. Separate the places the company account will enter from the places it will not, name who answers, and write down whether the answer is due in a day or in three.
6. Write the weekly summary. What belongs in it is not how many mentions there were but what is going to change. The same misunderstanding appearing three times means fixing a help doc; the same feature request appearing five times goes to the product team.

The three buckets from step 4 go to different places. Factually wrong claims get corrected in place, or answered by publishing something accurate enough to outrank the wrong version. Complaints go to product. Praise and usage tips get treated as user-generated content (UGC) — one good review reposted by the company account reads better in organic social than anything the company writes about itself.

The person running it is usually a marketer: maintaining the term list, doing the weekly walk, writing the summary. But four different people read that summary and each needs a different part of it.

1. Product gets the complaint bucket. A complaint that keeps recurring is not an opinion, it is a location.
2. Sales and customer success get advance notice of what a buyer is likely to ask. Walking into a meeting already knowing which misconception is circulating is the difference between an answer and a scramble.
3. Whoever runs the company's own community gets the questions that came from outside it. This is where the next topics for community building come from.
4. The founder gets escalations only, not the whole report. The signal worth escalating is the same negative claim spreading across several places within a day.

Cadence splits into normal and intensive. Normal is once a week. Four situations call for more: the two weeks after shipping a new feature or new pricing, the days after an outage, the moment a competitor ships something similar, and right after the company appears in the press. During those, twice a day rather than once a week.

"Three posts went up in the community saying saving is broken. We haven't had a single support ticket."

Watching only your own channels understates the size of a problem.

"That post is factually wrong so let's correct it, but stay out of the complaint replies underneath."

Distinguishing where to intervene from where to leave it alone.

"Skip the mention count. Just tell me what we're changing this week."

The summary exists to produce a decision, not a report.

At Pagedeck, Ravi walks three communities and two social feeds every Tuesday. The term list holds the product name, two common misspellings of it, three competitor names, and problem phrasings like "meeting notes" and "document permissions."

The routing is fixed. Complaints go to Mia, and misconceptions a buyer might repeat go to Sofia. Last quarter a post misreading the document limit on the free plan appeared four weeks running, and Mia fixed one sentence on the pricing page, after which the mentions stopped.

The most common mistake is believing the point of the work is reporting mention volume and the positive-to-negative split. Tools display those two numbers most prominently, so the assumption follows naturally. But "40 more mentions than last week" does not determine anything. Whether the increase came from praise for a new feature or from an outage leads to completely different next actions. A summary that contains only numbers stops being opened after about four months, which leaves the work still happening and the results gone.

The second mistake is assuming every negative post requires a reply. Leaving it alone feels like letting it grow, so the hand moves first. But intervening produces different outcomes in different places. Correcting something factually wrong is usually right. A company account arriving under a post about taste or disappointment to explain itself keeps that post alive longer, and readers hear an excuse. Those belong in the product backlog, where fixing them is the response. Which places you enter is a decision better made at step 5 than in the moment you read the post.