Social mention triage

A public brand mention, comment, or tag on social media can signal an emerging technical incident, an urgent customer complaint, a routine product inquiry, or irrelevant online noise. Operating without context risks embarrassing public statements, missed high-value customer churn risks, and uncoordinated support efforts. This playbook governs one inbound social mention case: verifying author identity against customer records, gathering cross-functional context, drafting a response or internal escalation, securing human approval, and confirming that the intended action was executed. All external communications and record writes operate under explicit human authority. The agent investigates context across connected databases and support queues, but never posts public social responses, issues refunds, or promises product changes autonomously. If external integrations fail or context remains ambiguous, the case halts for owner direction.

• Inspect the incoming mention record and extract core metadata. Parse the author username, platform channel, timestamp, mention permalink, direct quote, and any media or thread context provided via Tally, Fillout, or inbound webhook. Flag whether the mention is a root post, a reply to official brand content, or a quote share.
• Cross-reference the author handle and name against internal customer databases in Airtable and conversation history in Help Scout. Search for matching customer profiles, linked corporate email domains, subscription tier, and open support tickets. Treat any handle or name match as a tentative correlation until corroborated by verified account records such as a confirmed email or direct message verification. Explicitly document unmatched or uncorroborated profiles as unverified public visitors, and never disclose internal account details, billing status, or customer identity publicly based on a tentative match.
• Query system health advisories and active product incident channels for known service disruptions. Compare the user's reported problem against recent bug reports and maintenance windows. Note whether the report aligns with an acknowledged incident or represents an isolated issue.
• Evaluate mention urgency, risk category, and recommended resolution path. Classify the mention into one of three operational categories: routine inquiry or positive feedback requiring a standard acknowledgment; technical or billing problem requiring support ticketing; or high-risk brand, legal, or security report requiring executive escalation. Draft the appropriate response artifact: a concise public redirect directing the user to a secure support channel, an internal escalation brief for the support desk, or a recommendation to log the mention with no public reply.
• Approval. Present the complete triage packet to the communications lead, including the raw mention permalink, matched account record, system status context, and proposed action. If the recommendation includes a public reply, present the exact drafted wording; if an escalation is proposed, present the target team and ticket priority. The communications lead may approve the action as drafted, edit the proposed response text or destination, request additional internal investigation, or decline action and mark the case as noise. If approved, proceed to execute the routing and response workflow. If changes are requested, adjust the artifacts and resubmit for approval. If declined, log the rationale and advance to terminal closure.
• Information request. If the social mention alleges an active security vulnerability, data exposure, or undocumented billing defect that cannot be validated from internal records, request clarification from the on-call engineering or billing lead before presenting a public response. Hold the public response draft until technical confirmation is received or an official incident advisory is published.
• Exception. If an inbound social mention contains explicit legal threats, regulatory notices, harassment, or severe brand safety risks, pause automated triage workflows immediately. Notify the communications director and legal counsel with the original text, author handle, and timestamp. Await formal guidance from legal before drafting or publishing any public reply.
• Execute approved external actions and confirm verified receipts. If an internal escalation was approved, create the ticket in Help Scout or update the tracking record in Airtable, capturing the returned ticket ID or record confirmation. If a public reply was approved, provide the finalized text to the communications lead or social media publishing queue and verify the published permalink or owner sign-off. Record the final state in the triage log.
• In a fictional walkthrough scenario, a user tags the company on X claiming their workspace was locked after paying an annual invoice. The agent retrieves the post, finds a tentative handle match to an enterprise account in Airtable, and identifies a payment webhook sync delay in billing logs. Because the social handle is not yet confirmed by private account credentials, the agent avoids sharing account specifics publicly. It drafts an internal high-priority Help Scout ticket containing the billing logs for Support, alongside a polite public response asking the user to confirm their account email via private message. The communications lead approves the proposed escalation and public reply. The agent creates the support ticket, logs the returned ticket confirmation, verifies the approved reply was sent, and completes the triage case.
• Close the triage run only after verifying the terminal condition. If an action was approved and confirmed, record the outcome as completed with the external ticket ID or publication permalink. If the owner determined that no action was required, record the outcome as declined and archive the triage brief. If an integration failed during ticket creation or external verification could not be confirmed, retain the draft artifact, notify the owner, and hold the case in an unresolved state for manual recovery.