Turn recurring creator comments into a campaign FAQ by grouping questions that need the same answer, then checking each answer against current product information. Keep the comment evidence beside the approved answer and name the person responsible for it. Treat repetition as a reason to investigate. It does not show how common a concern is among all customers.
The workflow below produces two linked records: a question-coding sheet and an answer handoff. It is a recommended editorial process, not a platform requirement.
Define the comments you reviewed
Start with a bounded set of campaign posts. Record the creator, post URL, publication date, review window, language, collection method and whether you included replies. State any cap on how much you reviewed. A worksheet headed "campaign comments" is too vague to reproduce.
For example, a hypothetical scope could cover all accessible comments and replies on selected launch videos during their first week. If you only review the first page of results, say that instead. Keep inaccessible posts and missing replies in a coverage note.
Platform settings affect what reaches your sheet. On YouTube, the comment-thread listing documentation describes time and relevance ordering, pagination and search-term filtering. Moderation-state filtering requires proper authorization, and disabled comments or insufficient permissions can prevent retrieval. A keyword-filtered batch therefore needs a different label from an unfiltered review of the same videos.
YouTube also warns that a thread response may contain only some replies. Someone preparing an API export must account for that limit before calling it a complete thread review. These are YouTube-specific mechanics; check the access and export rules for whichever platform you use.
Read the post itself before coding its questions. "Does that come with it?" only makes sense when you know what the creator showed.
Code the answer needed
A useful code describes the decision the reader needs to make. "Shipping" may be too broad. "Delivery destinations," "dispatch timing" and "arrival before an event" can require different answers and owners.
The Government Digital Service's research-analysis method separates observations from interpretation, groups related observations and then turns findings into actions. Apply that separation here: preserve a neutral paraphrase of the question before assigning a code.
Use one row per question. When a comment asks about both compatibility and delivery, give it two linked rows with the same comment reference. Count questions and comments separately.
Question-coding sheet
| Field | What to record |
|---|---|
| Evidence reference | Post URL, comment reference, posted time and collection time |
| Context | Product version shown, creator demonstration and relevant parent reply |
| Question | Neutral paraphrase without guessing the person's intent |
| Answer code | Specific issue such as compatibility or included accessories |
| Conditions | Market, model, size or offer mentioned; otherwise mark unknown |
| Review note | Ambiguity, duplicate reference, translation concern or missing context |
| Answer record | FAQ identifier and status: research, review or ready |
Keep likes as a separate observed field if they help triage work. They do not turn one question into many independent questions. Avoid labelling a neutral request as negative sentiment because it mentions a limitation.
Define what belongs in each code and what belongs elsewhere. Have another reviewer classify a small shared batch, compare disagreements and revise unclear definitions before continuing. For several languages, use a multilingual listening codebook to keep the meaning of a code consistent across translations.
Work through a hypothetical product example
Suppose creators demonstrate a fictional travel mug. The comments below and the product facts are invented to illustrate the method. They describe no real campaign.
| Hypothetical question | Code | Evidence needed for an answer |
|---|---|---|
| Can the whole mug go in the dishwasher? | Care: body and lid | Current care instructions for both parts |
| Can I put the lid on the top rack? | Care: lid | Lid-specific care instructions |
| Is the lid the creator uses included? | Package contents | Exact SKU's packing list |
| Will this fit my car's cup holder? | Physical fit | Mug dimensions and the reader's cup-holder dimensions |
The first two questions share a care topic. An FAQ answer can address both if it distinguishes the body from the lid. The package question stays separate even though it also mentions a lid. Coding by repeated words alone would merge questions with different answers.
Now assume the fictional care guide permits dishwasher cleaning for the lid and requires hand washing for the body. A usable hypothetical FAQ answer is:
Can I put the mug in the dishwasher? Hand wash the mug body. The lid is dishwasher-safe. Follow the care guide for the model you bought.
That answer depends on the assumed care guide. A creator's demonstration of washing the whole mug would not establish the product instruction.
For cup-holder fit, dimensions alone do not support a promise that the mug fits every car. Give the verified mug dimensions and explain what the buyer should compare. If the relevant dimensions are missing, keep that answer in research.
Prioritize without claiming customer prevalence
For each code, report how many distinct comments and posts contain it within the reviewed set. Keep repeated copies or follow-ups traceable so one thread does not appear to be several unrelated discoveries.
Statistics Canada explains that non-probability samples can carry participation and selection bias. Conclusions about a wider population require assumptions about who the sample represents. People who comment under selected creators do not provide a random sample of buyers.
Use a narrow finding such as "care questions recurred across the reviewed launch posts." Avoid converting a comment share into "the percentage of customers confused about care." A liked question may deserve attention, but its likes do not establish customer prevalence.
Choose FAQ candidates using these editorial criteria:
- The question appears in separate threads or posts.
- An answer would help someone choose, use or maintain the product.
- A misunderstanding could lead to an unsuitable purchase or incorrect use.
- The team can supply a verified answer with the necessary conditions.
A rare but consequential question can outrank a frequent low-impact one. An unresolved safety concern belongs with the qualified product or safety owner before anyone drafts public guidance.
Hand off an answer with its evidence
Sprout Social's listening workflow recommends sharing customer questions with the teams that can act on them. For an FAQ, make that handoff specific enough for the recipient to approve or reject the wording.
Attach these fields to every proposed answer:
| Handoff field | Approval question |
|---|---|
| Reader question | Does this preserve what people asked? |
| Evidence links | Can the reviewer inspect the supporting comments and context? |
| Proposed answer | Does the first sentence answer the question directly? |
| Product source | Which current specification, care guide, packing list or offer terms supports each claim? |
| Scope | Which product version, market and campaign dates does it cover? |
| Owner and review date | Who checked it, and when must it be checked again? |
| Status and destination | Is it ready for the campaign FAQ, or waiting for evidence? |
If the product page and internal specification conflict, ask the product owner to resolve the discrepancy. Do not choose whichever source makes the answer more attractive. Keep unsupported wording out of the ready queue.
Publish approved answers where readers encounter the question, and add them to the creator brief without dictating the creator's delivery. Keep current TikTok corrections in the separate product-confusion response workflow; this worksheet prepares the reusable FAQ.
Before the next campaign batch goes live, select one recurring question, code its evidence and send its proposed answer to the named product owner. Expand the FAQ only when that first answer has a traceable source and clear scope.
