A retailer I worked with came to the project convinced they needed "chat on the website." The marketing team had seen a competitor's widget, the executive sponsor wanted a number on a slide, and everyone assumed this was a one-afternoon configuration job. It is not. The moment you sit down to scope it, the single word "chat" splits into two genuinely different products with different agent ergonomics, different license lines, and very different ways of going wrong in production.
The distinction that matters is synchronous versus asynchronous. Live Chat, the channel that grew out of the old Live Agent and now lives under Embedded Service, is a real-time one-to-one session. A customer opens a widget on the site, clicks to start, gets connected to an agent who is online right now, and the two of them talk until someone closes the tab. When that tab closes, the session is over. There is no thread to reopen tomorrow. Messaging is the opposite: the customer sends something from a mobile app or from WhatsApp, closes the app, and the agent replies two hours later. The customer reopens the app and the reply is sitting there in a conversation that simply persists. That single property reshapes everything downstream, from how you staff the team to which license you buy, so the first job on any of these engagements is to stop people from saying "chat" and force a decision about which behavior the business actually needs.
My rule of thumb is that Live Chat fits pre-sale impulse moments on the desktop web, where synchronous pressure helps close a decision, and messaging fits post-sale support that naturally stretches across hours or days. The retailer ended up running both: Live Chat on the product and checkout pages of the website, and messaging inside their mobile app alongside WhatsApp and Facebook for the slower order-and-returns conversations. That combination is common and correct, but it is a deliberate design, not a default.
Live Chat is mostly about the pre-chat form and the routing fallback
The Embedded Service deployment itself is the easy part. You create a deployment, whitelist the permitted domains, create a chat button, and point it at a queue with a routing type such as Least Active. Where Live Chat projects actually succeed or fail is in two unglamorous places: the pre-chat form and the off-hours behavior.
On the same retailer, marketing handed me a pre-chat form with eight fields, including date of birth and "how did you hear about us." Customers opened it, saw something longer than a sign-up form, and closed the tab. Chat conversion dropped sharply, and the feature was on track to be written off as a failure that had nothing to do with the actual chat. The fix is a principle worth defending in front of stakeholders with data: collect only the two or three fields an agent truly cannot begin without, usually a name or phone number plus a problem category, and let the agent ask everything else once the conversation is live. If marketing pushes back, run an A/B test on three fields versus five and show them the conversion delta. The pre-chat form is also where you do quiet but important plumbing, mapping the phone number to a Contact lookup so you do not create duplicates, mapping the problem picklist to Case Type, and auto-creating the Case on chat start.
That auto-create setting deserves its own mention because forgetting it produces a subtle reporting hole. If "auto-create Case from chat" is off, every conversation still generates a Chat Transcript record, but with no Case attached unless the agent remembers to click the button. They will not always remember. Months later, leadership's case-volume dashboard understates the real support load because an entire channel never made it into the Case object. Turn auto-create on, and if customers tend to spam the chat button, configure it to find-or-create a Case for the same Contact within a recent window so you do not shatter one conversation into five Cases.
The other classic Live Chat failure is routing with no fallback. A queue of five agents who are all offline at 11pm does not produce a polite "we're closed" message by default; it produces a customer staring at a spinner that never resolves. Salesforce will not close the widget or apologize on your behalf. Configure Business Hours on the channel, and outside those hours switch the widget to an offline experience, typically a Web-to-Case form so an offline chat becomes a Case, or a hand-off to an Einstein Bot for basic FAQs.
Capacity is the setting everyone skips and later regrets
By default an agent can be handed an unlimited number of simultaneous chats. That sounds generous until a flash sale sends five chats at one agent at once, their response time balloons from thirty seconds to five minutes, and customers start dropping. The cure is a Presence Configuration with an explicit capacity, often three concurrent chats for Live Chat. Once an agent is holding their limit, the next chat routes elsewhere or waits in the queue instead of degrading every conversation that agent is already in. This is also the lever that connects directly to your license count, so capacity is a number you should be modeling during discovery, not discovering in production.
Capacity is where the asynchronous nature of messaging starts to pay off. Because nobody expects an instant reply on WhatsApp, you can safely set a higher messaging capacity per agent, around five concurrent sessions, where Live Chat tops out lower. The agent experience differs too: Live Chat gives an agent one workspace tab per conversation in the Service Console, while messaging presents a multi-thread inbox the agent works through. Setting the capacity numbers correctly per channel, rather than copying one figure everywhere, is what keeps utilization healthy.
Messaging lives and dies by identity matching and the 24-hour window
Messaging brings two hard problems that Live Chat never has to face, because messaging conversations arrive from outside identities and persist over time. The first is matching the inbound contact to an existing Contact record. A message from WhatsApp arrives with a number formatted as +84901234567, while the Contact in Salesforce was saved as 0901234567. With no normalization, Salesforce fails to match and creates a fresh Contact every time the customer writes, until one person owns five fragmented records and every report by Contact is wrong. Normalize phone numbers to a single canonical format, typically E.164, before matching, whether through a matching rule with normalization or a small trigger, and test it against several formats of the same number before you call it done. Facebook adds its own wrinkle: the key you match on is the page-scoped user ID, which is specific to that page and is not the customer's main Facebook identity, so the same person on two pages looks like two people.
The second hard problem is the customer-service window, and it catches almost every team that has not done messaging before. WhatsApp enforces a 24-hour window: once the customer has been silent for more than a day, an agent cannot send free text. To reach out proactively after that — a delivery confirmation, a payment reminder — you must use a message template that Meta approved in advance, or the platform simply rejects it as outside the service window. Facebook works the same way with its own message tags, and Zalo uses a longer window plus its own notification-service templates. The practical consequence for the project is that you cannot leave this to runtime. During discovery, enumerate every proactive outbound use case the business wants, submit those templates for approval early, and wire your flows to send the approved template rather than free text when the trigger fires. Teams that skip this step ship a system that silently drops important notifications.
Thread continuity is the design choice that ties messaging together. When a customer who complained about an order last week writes back this week about a defective product, you generally want a new Case for the new issue while the customer still sees one continuous conversation. Salesforce can reuse an active messaging session and append to it, or open a new session and Case when the previous one has ended, so the backend splits the work into separate Cases while the frontend preserves the single thread the customer expects. And if any of those channels rides on a self-built middleware connector — Zalo commonly does, lacking native integration — that connector needs a retry queue and health monitoring, because a middleware outage at 2am that silently drops messages becomes an angry customer and a lost conversation by morning.
The throughline across both channels is the same one I open every chat-or-messaging discovery with: match the channel to how the customer actually behaves, then make the unglamorous settings — pre-chat length, business-hours fallback, capacity, phone normalization, approved templates — deliberate decisions rather than defaults. The widget is the part everyone sees in the demo, but it is those quiet configurations that decide whether the channel earns its license cost or quietly becomes the thing nobody trusts.
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.
