Quick answer: Devotel Orbit's Inbox social-mentions queue ingests public brand and keyword mentions — X/Twitter posts, Reddit threads, Trustpilot or G2 reviews, public Instagram and Facebook comments — into the same omnichannel inbox your team runs for private channels. A listening connector normalizes each mention and posts it to POST /inbox/social-mentions/ingest; from there the mention lands in a dedicated queue with sentiment chips, platform filters, and deep links back to the original post. Routing rules, ticket automation, and per-queue SLA escalation policies then triage and assign it the same way they triage a WhatsApp or email thread. This post is the operator angle for that pipeline, documented in the inbox.
What shipped: an ingestion queue, not another feed to skim
Social care breaks when it lives in a separate tool. An operator with a private inbox and a listening dashboard ends up copy-pasting links between windows, and the "public brand mention" never gets the same assignment, SLA clock, or reply path as a paid conversation. The Inbox social-mentions queue closes that gap by treating a public mention as a first-class inbox conversation, not a notification.
A public mention differs from a DM in one structural way: it opens with no context, so the ingestion connector supplies the details the queue needs. Platform token, author handle, permalink back to the original post, matched keyword, and optionally sentiment and reach all arrive on the ingest payload and are preserved as a social_mention metadata blob on the conversation. Every ingested mention is idempotent on (channel, external_id) — re-deliver the same provider id and the server returns deduped: true instead of a second row, so retries are safe.
The queue itself lives at Inbox → Social mentions — a rail tab next to All conversations, Pending replies, and Archive. Each row shows a sentiment chip, the platform token, the author, an unread count, and two deep links: one into the conversation view, one out to the original public post via the stored permalink. Filter by platform and status; the queue pages through the mention firehose rather than capping at one screen. The full route contract, the platform tokens, and the comment-thread structure for instagram_comment / facebook_comment are in the social-mentions Inbox page.
How the tenant wires it: routing, dispositions, and SLA hooks are yours
Every control past the ingest point is tenant-owned — nothing here routes messages outside your own workspace. Three surfaces compose on top of a landed mention:
Routing rules. A mention is an inbound conversation on the social_mention channel, so the same rules engine that assigns WhatsApp or email conversations decides who answers a mention. Conditions match on keyword, language, sentiment, tag, and contact segment; actions assign to a user, a team, a round-robin pool, or a skill-matched agent, or hand the conversation to an AI agent. A mention whose connector tagged sentiment: negative on Trustpilot can route straight to your retention team; a mention with a high reach can escalate to a senior agent. Dry-run the rule against a sample payload before it goes live, exactly as you would for any other channel. The full condition vocabulary and the worked API sequence are in routing rules.
Ticket automation. Where routing rules decide whose desk, ticket automation decides what happens to the ticket right now: reassign, retag, reprioritize, escalate, or notify a Slack channel or webhook on a lifecycle event. A mention that lands with a negative sentiment and stays unread past your floor can escalate priority, tag stale, and notify on-call without anyone touching the queue. The two engines compose — a ticket-automation rule can be the thing that raises priority before a queue breach ever fires. See ticket automation for the trigger catalog, action vocabulary, and dry-run shape.
Disposition tags. When a mention closes, the outcome label it carries is a tenant-owned vocabulary — the disposition sets under Inbox → Settings → Dispositions cover the inbox conversation type social mentions land in, so a resolved Trustpilot complaint and a snoozed Reddit thread close with the same outcome labels the rest of your digital queue uses. Those labels are the axis the Distribution view and your reports query against. See inbox dispositions for the label-set editor and lifecycle rules.
Queues and SLA-escalation. Mentions land in the same conversation machinery as every other channel, so the queues you already run can include them — and per-digital-queue SLA escalation policies watch the queue as a whole (how many open conversations already breached, how old the oldest still-open one is) and page supervisors the moment the queue stalls. Conversation-level SLA timers hang first-response and resolution clocks on each mention the moment it lands. The queue-level escalation model is in per-digital-queue inbox SLA escalation policies.
What you can do once it is wired
The triage loop is the one your team already runs, with the public-mention specifics filled in:
- Triage unprompted mentions. A public mention arrives with no prior thread, so the connector-supplied metadata — matched keyword, sentiment, reach, permalink — is the context. Read the original post through the permalink, then assign and reply in the thread.
- Route to the right queue. Use the routing and automation surfaces above to decide whether a mention lands on the social-care desk, the retention desk, or a senior-agent pool — and keep that decision in a rule, not in an operator's head.
- Track response SLA. Workspace SLA timers give each mention a first-response and resolution clock; the per-queue escalation policy pages a supervisor when the queue backlog ages past your floor. The result is the same SLA discipline you run on WhatsApp, applied to the public conversation.
For the Meta comment family, a new comment on one of your posts also triggers your published comment-received automation: a private DM goes out to the commenter inside Meta's follow-up window while the public thread stays in the queue.
Limits: where the ingestion boundary still sits
This queue ingests what a connector posts to it. The listening providers behind each network are still your accounts — Orbit normalizes and triages the mention once it arrives, and the deep link back to the public post always leads out to the network itself. Two boundaries matter:
- Networks without a listening provider in your stack. If you do not already pull X/Twitter mentions, Reddit threads, or review-site notifications through a listening poller or webhook subscriber, those networks still need that external tool to feed the ingest endpoint. The queue is the destination; the connector is the source.
- Firehose-scale streams. The queue pages the mention firehose rather than capping it, but a brand running a full-enterprise listening programme across dozens of networks is still best served by a dedicated listening platform feeding the mentions it matters about into Orbit. The queue is built for triage and response, not for raw ingest-volume analytics across the open web.
Both boundaries are stated in the social-mentions Inbox page — the example connectors there show the same endpoint, same idempotency contract, per platform.
Frequently asked questions
Do I have to build the listening connector myself?
No. Any poller or webhook subscriber that normalizes a mention into the documented payload shape can post to the ingestion endpoint. The Inbox social-mentions page shows four worked connector payloads — X/Twitter, Reddit, Trustpilot, and an Instagram comment thread — all posting to the same route with the same idempotency contract.
What happens if the same mention is ingested twice?
Dedup is server-side on (channel, external_id). Re-deliver the provider's stable mention id and the ingest endpoint returns 200 with deduped: true instead of opening a second conversation, so retries are safe.
Which teammates can post into the queue?
Only owner, admin, or super-admin roles can write into the shared queue — a connector acts on your behalf under that role. Any operator can read the queue and the dashboard page; the rail tab itself is hidden from agents today and widens with the API.
Do routing rules treat a mention differently from a DM?
No. A mention is an inbound conversation on the social_mention channel, and the same condition vocabulary (channel, keyword, language, sentiment, tag, segment) applies. Dry-run the rule against a sample mention exactly as you would for any other channel.
Does a mention ever leave my workspace?
No. Routing rules, ticket automation, and SLA escalation are all tenant-owned; nothing in the pipeline sends a message outside your own channels. The comment-received DM automation on Meta posts is a tenant-configured automation, not a default.
Resources
- Social listening and public-mention triage (docs) — the ingestion endpoint, queue, and connector contract
- Routing rules — auto-assign inbound conversations (docs) — the condition and action vocabulary for who answers a mention
- Ticket automation — event-driven ticket rules (docs) — lifecycle-event rules that retag, reprioritize, and notify
- Per-digital-queue inbox SLA escalation policies (docs) — queue-level breach alerts for queues that include social