Blog Posts

If you’re choosing between Service Cloud Voice and a CTI solution, don’t start with features. Instead, start with where routing lives, where call data lives, and who owns the configuration. Those decisions determine reporting, governance, and long-term maintenance. They’re not interchangeable terms Service Cloud Voice is a Salesforce voice product experience inside Service Console. CTI is a category of integration patterns, and that range is wide. For example, “CTI” might mean: Therefore, the real question is: which pattern matches your Service Cloud operating model? The five questions that decide this cleanly 1) Where does routing happen? If your service org runs on Omni-Channel, routing is not a side detail. However, many CTIs still route in the vendor platform first, then sync outcomes into Salesforce. As a result, you maintain two routing models. Ask: When queues/skills/business hours change, do admins update Salesforce, or a separate console? 2) What is the “call record” in Salesforce? Service Cloud Voice aligns to Salesforce’s voice data model (including VoiceCall). In contrast, many CTIs log a call as a Task, a custom object, or a delayed sync record. Ask: Do you need call events to be first-class Salesforce data for workflow and reporting, or is “activity

In a lot of Salesforce orgs, the CRM is solid but calling still lives on desk phones, mobiles, or a separate app. Calls do happen, notes sometimes make it back into Salesforce, and managers try to stitch together a picture of activity from partial data. CTI is often reduced to “click-to-dial and call logging.” In reality, when telephony is wired natively into Salesforce, it changes how the CRM behaves day to day: which records are created, how work is queued, and how easy it is to keep follow-up consistent. The rest of this article stays on that level and looks at a few specific areas where a well-implemented CTI setup tends to improve both CRM reliability and sales execution. 1. Every call becomes structured CRM data Without CTI, calls show up as: As a result, you cannot reliably answer simple questions such as: With CTI that writes directly into Salesforce, each call can be represented as a Voice Call (or similar) record from the moment it starts. Then you can: Because the data lands as first-class CRM records, reports stop depending on guesswork. You can build dashboards on standard objects instead of exporting logs from an external telephony portal. 2.

When voice routing feels random in a Salesforce org, it’s usually not a “CTI feature” problem. It’s because three basics are not wired cleanly into Salesforce: If these live partly in a CTI portal, partly in carrier consoles, and only partly in Salesforce, the result is fragile operations and constant exceptions. As a result, admins end up debugging two different routing engines for every escalation. A stable model puts all three under Salesforce control and treats CTI as an execution layer, not a second system. 1. The non-native pattern: routing “next to” Salesforce In a typical non-native Salesforce CTI setup: Salesforce then receives: Practically, that leads to issues architects know well: The core problem is simple: Salesforce is not the system of record for routing, time, or permission. It is just one more consumer of CTI data. 2. A Salesforce-first model: CTI as an extension A native Salesforce CTI model reverses this: In this model: This is less about “native vs non-native” branding and more about who actually controls the contact center logic. 3. Skill-based routing: keep skills with agents, not in a CTI silo Skill-based routing is easier to manage when skills live on users and queues inside Salesforce.

Most Salesforce teams I meet already “use WhatsApp.” Sales reps call from their mobile. Support teams answer customer voice notes. Managers see screenshots in Slack, not data in Salesforce. The moment you ask, “Can we treat WhatsApp voice calls like any other call in Salesforce?” the gaps show up very quickly. What people usually mean by “WhatsApp Voice in Salesforce” In practice, I see three common patterns: All three patterns have the same problem: Salesforce is not the control plane for WhatsApp Voice. It only hears about calls after the fact, if at all. A Salesforce first view of WhatsApp Voice Before you talk about any app or provider, it helps to define what “good” looks like. In a Salesforce-first design: WhatsApp and the carrier become the media layer. Salesforce becomes the brain. Once you look at it this way, “WhatsApp Voice in Salesforce” stops being a feature request and becomes a straightforward architecture question: How do we represent WhatsApp calls as first-class Voice Call records and treat them like any other native CTI call? The core data model: one call object, multiple channels The starting point is the call model. A clean pattern is: At minimum, every WhatsApp Voice

If you’ve been around more than one CTI rollout, you already know the pattern: the phones “work,” but reporting is unreliable, routing rules live in a vendor UI, and no one is quite sure where recordings and call data actually live. When you strip away branding, most of those problems are not feature issues. They’re architectural. Specifically: is Salesforce the system of record for telephony, or just a place where a CTI connector drops some activity logs? That is the real difference between native and non-native CTI. 1. How to spot a non-native Salesforce CTI Often before definitions, it helps to look at the symptoms. These are the red flags I see when CTI lives “next to” Salesforce instead of in it: If two or three of those are true in your org, you are operating on a non-native CTI architecture, even if the product markets itself as “for Salesforce.” 2. Two very different CTI architectures At a high level, there are only two real CTI models in Salesforce 2.1 Non-native (integrated) Salesforce CTI Salesforce is a consumer of CTI data, not the place where telephony logic lives. 2.2 Native CTI inside Salesforce: one console, consistent UX Here, Salesforce is