A telco I worked with came to us with what looked like a simple ask: "We want our agents to handle Facebook complaints inside Service Cloud." Two discovery sessions later, the picture had ballooned into three separate Facebook Pages, a Zalo Official Account, a barely-used Twitter handle that the PR team watched nervously, and a TikTok account where the spiciest complaints actually lived. None of that fits behind one button, and the first thing I had to tell them was that the obvious answer — turn on Salesforce's built-in social feature — was already a dead end.
Salesforce sunset the legacy Social Customer Service feature in Spring '24. It still works in orgs that had it, but no new development is happening on it, and Salesforce themselves recommend migrating off. So the real conversation isn't "how do I configure the social tab," it's "which combination of native Messaging, a third-party listening tool, and custom middleware do I assemble, and how do I keep agents sane while doing it." That architecture decision drives everything downstream, so it's worth being honest about the moving parts before you commit to a design.
The trap most teams walk into is treating social as just another email channel with a different logo. It isn't. Social is public, it's fast, it has an audience, and a single angry post from the wrong person can do more brand damage in thirty minutes than a month of slow email responses. Your design has to respect that, or you'll build something that's technically correct and operationally useless.
The three-layer architecture you actually end up with
For this telco we landed on three layers, and I'd guess most mid-to-large social implementations end up somewhere similar.
The first layer is Service Cloud Messaging for direct messages. When a customer DMs the Facebook Page or messages the Zalo OA one-to-one, that flows in as a Messaging Session, routes through Omni-Channel to a "Social Messaging" queue, and the agent replies in real time from the Service Console. This is the clean, native, fully supported path, and it covers the highest-intent conversations because someone who DMs you usually has a specific problem.
The second layer is a third-party listening tool — Sprinklr in this case, though Hootsuite or Brandwatch fill the same slot — for everything that happens in public. Wall comments, post replies, Twitter mentions, hashtag campaigns, TikTok comments. Sprinklr connects to each platform's API, applies keyword and sentiment filters, and pushes the matching items into Salesforce over REST, where they land either as a case with a "Social Post" type or as a custom Social_Mention__c record carrying source, author, message, URL, and sentiment. This layer matters because Salesforce natively never listened to wall comments and never supported Zalo or TikTok at all.
The third layer is custom middleware for the platforms even Sprinklr can't fully reach. Zalo OA comments on posts (as opposed to DMs) needed a small service the client's developers built: it subscribes to the Zalo webhook, filters by sentiment and product keyword, pushes mentions into Salesforce, and proxies the agent's reply back out through the Zalo API. TikTok was worse — its Business API is effectively read-only for comments, so Sprinklr scrapes them in and agents reply manually in the TikTok app, logging a note in Salesforce that says "Replied via TikTok." Nobody loves that last part, but it's the honest state of those platforms today, and pretending otherwise just sets the client up for disappointment.
Triage is the decision that makes or breaks the implementation
Here is the mistake I see kill more social projects than any technical issue: turning every mention into a case. On a brand of any size, "your service is terrible" gets typed a few hundred times a day, and almost none of those comments are actionable. If each one spawns a case, your agents spend their shift wading through garbage and the genuinely urgent cases — the customer who gave you an address and a service ID and is clearly offline — get buried and blow their SLA. The business consequence is real: NPS drops not because you ignored customers, but because you drowned the signal in noise you created yourself.
So triage has to be deliberate and strict. The rule I push for is that a mention only becomes a case when it carries something an agent can act on: an address, a customer ID, a clear intent. A customer complaining about an outage and naming their address becomes a high-priority case routed to the network team. Someone ranting about a price increase and cursing the brand becomes a medium case to billing, with a flag to PR. A question about plans is a lead, not a case, and goes to sales. The generic "this telco sucks" gets logged as a Social_Mention__c for trend analysis and nothing more. Spam gets auto-archived. Mechanically this is a Flow on the mention object that checks sentiment and keywords on insert and decides whether to create a case, a lead, or nothing — but the logic is a business decision, not a technical one, and it deserves a real workshop with the client rather than a guess.
One more thing that surprises clients: social SLAs are nothing like email. A public Twitter mention with PR risk might need a 15-minute response; a Facebook DM, where the customer expects chat-like immediacy, more like 5 minutes; TikTok, where nobody expects real-time, can sit for a couple of hours. Define these per channel up front, and put them on a supervisor dashboard, because a missed social SLA is visible to everyone watching the thread.
Routing on dimensions email never had
Once mentions are flowing and triaged, routing them well requires variables that email and chat simply don't have. Public versus private matters enormously. Influence matters — a verified account or a creator with a six-figure following is a different risk class from an anonymous account with eleven followers. Sentiment matters, and so does reach velocity: a post picking up two hundred shares in half an hour is a different animal from the same post sitting quietly.
I usually express this as a weighted priority score blending influence, sentiment, public-vs-private, and volume, then map score bands to queues. A verified user posting negative sentiment in public goes straight to a "Crisis" queue with a PR alert. A creator above ten thousand followers with negative sentiment goes to senior social agents. A small account with a complaint goes to the general social queue. And don't forget the positive end — praise from anyone should route somewhere low-priority so an agent can actually say thank you, because engagement is half the point of being on these channels at all.
A hard-won caveat: sentiment scoring on local-language text is often the weak link. The off-the-shelf, English-trained models routinely mis-read regional phrasing — I've watched genuinely positive, slangy praise get scored as negative and routed to crisis. If your customers post in a language the default model handles poorly, budget for a locally-trained model or fine-tuning, put a human confirmation step in front of any "critical" escalation, and measure accuracy monthly rather than trusting the vendor's marketing number.
Public replies are official statements, so they need approval and a voice
A reply posted publicly under the brand name is, functionally, a press release. It can go viral, it can create legal exposure if an agent promises a refund the company can't honor, and it can leak PII. So public replies — at least the negative or high-influence ones — need an approval workflow before they go out, while private DMs can be sent directly.
The shape I implement: a positive, boilerplate "thanks for the kind words" reply uses a pre-approved template and needs no sign-off. A negative reply that requires real explanation goes through a Salesforce Approval Process — entry criteria on sentiment score or follower count, a supervisor step, and a second PR-director step once the author's following crosses a high threshold. The reply itself is sent from an LWC on the case page that only enables the "Send" button once the record is approved, then calls the connector or platform API to post it.
The danger here is that the safeguard becomes the bottleneck. I've seen a creator with half a million followers post a damning complaint at 10pm, the agent draft a reply and submit it for approval, and the supervisor not see it until 9am — by which point the thread had gone everywhere. The fix is to treat approval like any other SLA: a hard timer that escalates to a director if no one responds in thirty minutes, a 24/7 on-call rotation for crisis posts, and an automatic "crisis mode" that, past a follower-and-velocity threshold, skips individual approval in favor of a pre-approved holding reply like "We're on it and will DM you in ten minutes." A safe, generic answer sent fast beats a perfect answer sent too late.
Finally, consistency. When two hundred agents reply on social, their personal styles leak through — one formal, one breezy, one corporate — and customers reading the thread perceive a brand with no coherent voice. Quick Text templates anchored to documented brand-voice guidelines fix most of this, with Knowledge articles (reviewed by PR and legal before publishing) supplying the standard answers agents can link to publicly. The discipline to drill into agents is that Quick Text is a starting point, not a finished reply — paste the template, then personalize it, because nothing reads worse than a copy-pasted apology to someone who gave you a specific time and place. And the non-negotiable rule, enforced with a PII-detection regex on the draft if you can: never confirm a phone number, customer ID, or full address in a public reply. That's both a privacy-law violation waiting to happen and a gift to anyone running a social-engineering attack.
The principle underneath all of this is simple. Social customer service fails not when the integration breaks but when the operation can't keep up with the channel's speed and visibility — so design for the noise, design for the audience, and make the safe path the fast one.
Implementing or optimizing Service Cloud? Our Salesforce team runs discovery, designs the case process, and configures Service Cloud, Omni-Channel, and Knowledge on production engagements. Get in touch ->
See our full platform services for the stack we cover.
Top comments (0)