Blog Posts

If call data doesn’t show up cleanly in Salesforce reports, teams end up managing performance in spreadsheets or external portals. That’s usually not a reporting problem, it’s an architecture problem. This post walks through how to think about CTI dashboards inside Salesforce, using native objects and standard reporting, without turning analytics into a separate system. Where CTI reporting usually falls apart Across many orgs, the same patterns repeat: As a result, dashboards exist but aren’t trusted. The core principle Dashboards only work when Salesforce owns the call data. That means: Once that’s true, dashboards become straightforward. A practical dashboard model 1) Start with the call record Your call object should clearly capture: If these fields are consistent, reporting stays stable. 2) Build reports before dashboards Create simple reports first: If a report feels hard to build, the data model likely needs adjustment. 3) Layer dashboards for managers Dashboards should answer operational questions quickly: Avoid overloading a single dashboard. One role, one view. 4) Keep analytics inside Salesforce When dashboards run on native objects: That’s what keeps reporting trustworthy over time. Why native CTI matters here CTI dashboards break most often when call data is split between Salesforce and an external

Most “AI for calls” projects don’t fail because the models are bad. They stall because the call information land outside the Salesforce workflow, so nobody trusts them, and nothing downstream changes. What seems to hold up in real orgs is simpler: treat AI outputs as inputs to the next Salesforce step, not as a separate layer of text agents skim once. Where AI call handling usually disappoints A few patterns show up repeatedly: As a result, AI feels like extra output rather than operational improvement. A useful way to think about it “Smarter call handling” is basically three questions: If the answer is “no” to any of these, AI usually becomes optional reading. The CTI + AI pattern that tends to work 1) Capture the call in Salesforce with minimal friction Nobody gets excited about call logging, but it’s the foundation. At minimum, teams need: Otherwise, you’re summarizing something that can’t be reliably reported later. 2) Store call information where the workflow lives The outputs that actually get used are usually: The important part isn’t the list. It’s that these artifacts stay attached to the call record and related Contact/Case/Opportunity, so they can be governed like the rest of Salesforce

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