A planning template that makes someone own the social listening decision

Give social listening a named decision-maker before any collection begins. The useful output is not a monitoring stream but a recorded choice, backed by bounded evidence and an explicit stop route. A planning record makes each unresolved permission, quality or ownership question visible before it can be mistaken for approval.

What needs to be decided before I collect anything?

The authorised owner must name the exact choice, the deadline and whether the available routes are to proceed, revise or reject. They must also identify a possible finding that could change the choice, so evidence has a defined decision role.

Complete the planning template before purchasing software or collecting posts; every field needs an auditable response, and a blank is a gate rather than an invitation to assume. Mark platform records and privacy rules as England, UK or global, because many apply at UK or global level.

Keep a question log beside the decision block. Prioritise questions, revisit them as learning changes, and close each when no possible finding can affect the choice. This keeps the brief iterative rather than open-ended monitoring; the team roles record who may close each question.

What should each checkpoint leave on the record?

Use six checkpoints to make the record auditable: each has a required record, a condition that pauses progress and a named output. A blank or unresolved item stays visible; it does not become evidence that the work is safe to continue.

Who belongs in my sample, and how do I define England?

Define the population as people, organisations or service users relevant to the choice, without implying that everyone in it posts online. Set the research question as one answerable question linked directly to the choice, rather than a general invitation to monitor conversation.

Set the England criterion through residence, work site, service location or event, and record unknown geography when it cannot be established. Language or a place mention is not a substitute. The audience research guide addresses this boundary when defining who is in scope.

What must I check about each source?

Treat access permission and privacy review as separate gates. Under UK GDPR, the ICO guidance on privacy information says data from publicly accessible sources still requires privacy information unless an exception or exemption applies; a DPIA is required when informing people is impossible or disproportionate.

Record access, fields, limits, retention, rights contact and first-party terms for every source. For qualified review, add the controller, purpose, proposed lawful basis, access roles, sharing arrangements and DPIA decision. The review record may also note privacy information, data protection principles, data protection by design and by default, records of processing activities, and security of processing.

How can I tell whether a query is accurate enough?

Test query quality on a reviewed sample, and treat precision as a measure of those returns rather than of the wider audience. Leave recall blank unless a defensible ground-truth set exists. The test assesses query quality, not overall population coverage.

Calculate precision as relevant sampled returns divided by all sampled returns reviewed. Report the numerator, denominator, period and exclusions with it; precision is not an audience rate. The sample and labels must support the stated measure, or the quality record stays open.

Show the metric and its limits on the reporting dashboard. For each query, log terms, spelling variants, exclusions, syntax, language and approver, plus its version. For the test sample, record source, dates, sampling route, sample size and how duplicates were treated.

Define relevant, irrelevant and ambiguous returns, along with any topic or sentiment labels, and record reviewer disagreements and adjudication. If a model supplies labels, log its version and error costs. The ICO AI guidance is marked under review after the Data (Use and Access) Act, so a named privacy and AI reviewer must confirm current requirements and controls at approval.

Who has to prove the operation can work?

Before collecting data, separate requirements that are merely documented from capabilities demonstrated or tested. Keep anything unresolved visible, assign an owner to each function, and let one person hold several roles only when workload and conflicts remain acceptable for the work.

What am I allowed to do with a finding?

Separate permission to study a signal from permission to act on it, and list which actions may follow. Name the people authorised to investigate, reply, change a service or prepare a claim, and set review and close-out conditions before launch.

Route high-risk allegations and sensitive personal information through a separate escalation path. Set review triggers in advance for a source-policy change, query revision or classifier update; also specify who responds to a missing-data surge, complaint, security event or change of purpose.

Define the close-out measure as recommendations accepted divided by eligible recommendations considered during the stated review period, with exclusions documented. This records a workflow measure only; it is neither return on investment nor causal impact. Do not treat permission to study a signal as permission to act on it.

Before launch, assign the author and fact-checker, with named privacy, research-ethics, AI, security, advertising and legal specialists approving their areas. On the approval date, recheck every platform record against the disclosure policy and run the quality checklist before the first release; the template itself grants no permission or compliance.

What should I do first?

Start by completing the decision block and checking who can act on its answer. Then keep source permission, query quality, operating readiness and release approvals as separate recorded gates; none should be assumed complete because another gate has already passed.