Cases fall through the cracks between channels
Email lands in one queue, chat in another system, calls in the telephony tool. The same customer has opened the same issue three times and no agent can see the other two.
We implement Service Cloud, rebuild orgs that were configured for a launch demo, and write the custom layer when configuration runs out. Case model, routing, entitlements, Knowledge and Agentforce — designed around how your support team already works.
Trusted by 500+ organizations — including SaaS, healthcare and enterprise support teams running customer service on Salesforce with Twopir Consulting.








Built for Service Operations
These are not edge cases. They are the patterns that show up when a Service Cloud org was configured to pass a launch demo rather than to carry a working support queue. Every one of them is an architecture problem, not a licence problem.
Email lands in one queue, chat in another system, calls in the telephony tool. The same customer has opened the same issue three times and no agent can see the other two.
Entitlements were never configured and milestone timers never run. Managers export a weekly report and count breaches by hand — measuring violations after the fact instead of preventing them.
The account is in the CRM, the subscription in billing, usage in the product database. Agents spend the first minutes of every case assembling context across tabs before they can start solving anything.
Articles were written two years ago with no review cycle and no way to flag what is stale. New agents ask a colleague instead — so your most experienced people spend half their day as a help desk.
Every report needs a manual pull, first-contact resolution disagrees between systems, and CSAT lives in a separate tool with no link to case data. Staffing decisions get made on instinct.
Email folders, shared spreadsheets and an informal escalation process have grown up beside the platform, because the platform does not match how work actually flows. You are paying for a system your team avoids.
Salesforce Service Cloud is the customer service application built on the Salesforce platform. It centralises case management, omni-channel communication across email, phone, chat, messaging and self-service portal, a knowledge base, entitlement and SLA tracking, and AI-assisted automation — on the same data model as the rest of your Salesforce org.
That shared data model is the reason companies choose it over a standalone help desk: the agent sees contract terms, renewal dates, product usage and open invoices next to the case, because it is all one record. It is also the reason a poor implementation hurts more here than elsewhere — a case model that does not match how the business categorises work spreads that mistake into every report, every routing rule and every SLA the org later depends on.
What Salesforce ships is capability. What determines whether support performs is the architecture underneath it — the case data model, the routing logic, the entitlement processes and the integration surface. That architecture is what Twopir Consulting is engaged to design, build and keep working. It is the same discipline we bring to the rest of the platform — see Salesforce services for how Service Cloud sits alongside Sales Cloud in one org.
"Service Cloud work" covers three genuinely different jobs, with different costs, timelines and risks. Knowing which one you are buying is most of the decision — so here is where each starts, and where each one stops.
For teams standing up Service Cloud for the first time
A first build from a clean org, or a migration off a help desk. We design the case model before configuring anything, then build routing, entitlements, Knowledge and reporting against your real case types and real SLA tiers.
Delivered with configuration and Flow. If the design needs Apex, Lightning Web Components or a custom integration, that is scoped separately as build-on work — never absorbed silently into an implementation estimate.
For teams already live, but working around the system
The most common engagement we run. The org is technically live, agents avoid it, SLA data is not trusted and no one can pull a report they believe. We audit what exists and rebuild the parts that are failing, usually without a blank-org restart.
A rescue works inside your existing org and its data. Where the original data model cannot support what the business now needs, we say so and scope the rebuild honestly rather than automating around a broken foundation.
For teams whose requirements have outgrown configuration
Custom development on the platform, for the cases declarative tools cannot reach: bespoke agent interfaces, service logic that has to run at volume, and integrations that need real error handling rather than a nightly file. Deeper AI work runs through our Agentforce practice.
We only write code where configuration genuinely cannot do the job. Custom code is the most expensive thing on a Salesforce org to own — every line is something you maintain through every release, so the boundary is argued case by case, in writing.
Every capability below is designed against how your support operation actually runs — how cases arrive, how they are triaged, what an agent needs before they pick one up, and how leadership measures the result.
Most orgs have a case object. Few have a case model built around how the business really categorises, prioritises and routes work — which is what every report and routing rule later inherits.
The right case has to reach the right agent the first time. We build the routing model — capacity, skills, presence and queue priority — so the team runs at real utilisation instead of flooded or idle.
An SLA that is not tracked in the system is not an SLA — it is a promise. We configure entitlement processes and milestone timers so the team is warned before a breach, not reported to afterwards.
A Knowledge Base nobody maintains is worse than none — it costs agents the time they spend checking it. We design the taxonomy, the authoring and approval workflow, and the feedback loop that keeps it true.
AI works here when it is configured against your own case history rather than switched on from a menu. We assess whether your data can carry it, then implement only what will produce measurable lift.
Support leadership should be able to answer any question about the queue in under a minute. We build the reporting layer so decisions come from case data rather than an end-of-month spreadsheet exercise.
Agents should never leave Service Cloud to understand a customer. Each integration below states what it is for and which direction the data actually moves — the part that decides whether it survives contact with real volume.
Order history, entitlement source data and account standing surfaced on the case, so agents stop opening the ERP in a second tab.
ERP → Service Cloud · read, near real timeSubscription status, plan tier and open invoices next to the case — the context that decides whether a billing complaint is an escalation or a five-minute fix.
Billing → Service Cloud · read, on case loadOpen CTI telephony so inbound calls create or match a case automatically, screen-pop the right record, and log disposition without an agent typing it.
Telephony ⇄ Service Cloud · bi-directionalFeature adoption, error rates and health score written onto the account, so a support conversation and a renewal conversation reference the same evidence.
Product → Service Cloud · scheduled syncThe middleware layer when volume, retry logic and error handling matter more than a point-to-point connector. Chosen on data volume, not on preference.
Middleware ⇄ orchestrated, with retryEscalations raised to engineering or account teams from the case, with replies written back — so the resolution trail stays on the record instead of in a thread.
Service Cloud ⇄ chat · alerts and repliesAuthenticated self-service where customers raise and track cases and search Knowledge — the deflection channel, and the one most often skipped at launch.
Portal ⇄ Service Cloud · same case recordHistoric tickets, attachments and macro logic migrated with the audit trail intact, validated in a parallel run before the old tool is switched off.
Legacy → Service Cloud · one-way cutoverA focused build covering case management, capture, automation, entitlements and reporting typically runs 8–12 weeks. Add omni-channel, CTI, Knowledge, a self-service portal, back-office integration and AI and it is realistically 16–24 weeks.
Before a field is configured we map how work really flows: how cases arrive, how they are triaged, what triggers an escalation, and what separates a clean resolution from one that dragged. The architecture document that comes out of it governs every decision after it.
The foundation first — case data model, routing logic, entitlement processes and milestone timers. Get this layer wrong and no amount of automation or AI rescues it, so every routing rule is tested under simulated volume before anything is built on top.
With the case model stable we add the layers that depend on it: Flow automation, Knowledge, CTI, the back-office integrations that give agents context, and Einstein or Agentforce configured against your own history. Built iteratively — never a black-box deployment.
Testing runs with the actual support team, not only IT: agents test real scenarios, managers check dashboards against numbers they already know. We stay engaged through the first 30–60 days of real volume, because a go-live is a milestone, not a finish line.
Two engagements, and the numbers they moved. Each figure is scoped to the environment it was measured in — these are results from specific builds, not a promise about yours.
Twopir rebuilt our Service Cloud architecture and connected it to our billing platform and product database. Context is there before the agent picks up the case. Our average handle time dropped by 38% in the first quarter after go-live — and our agents stopped dreading the case queue.
Service Cloud rebuild with ERP integration and omni-channel routing.
We had Salesforce. We had a support team. What we didn't have was a system those two things shared. Twopir audited what we had and rebuilt the case model, SLA configuration and Knowledge Base from the ground up. Our support managers finally have a dashboard they actually trust.
Full Service Cloud rescue — case model, entitlements, Knowledge and dashboards.
Four roles buy this work, and they buy it for different reasons. If one of these reads like your week, the first conversation will be short and specific.
You are accountable for SLA performance and CSAT, support is a retention lever rather than a cost centre, and the system you have does not reflect that. You need the numbers to be trustworthy before you can defend them. See our Salesforce for SaaS work.
You inherited a Service Cloud org that was stood up years ago and never properly configured. Agents work around it, SLA data is not trusted, and you need a partner who will assess, fix and document rather than quote a rebuild.
You run support across several channels where documentation and compliance standards add real operational weight. A generic help desk cannot carry it — you need Service Cloud configured for how regulated workflows actually run — as in our healthcare and legal engagements.
You already run Salesforce across sales, marketing and service, and service is the weakest of the three. You know the platform — you do not have the bandwidth to rebuild the service architecture and document it as well.
Support teams rarely struggle because they bought the wrong platform. They struggle because the case model, the routing and the entitlements underneath were never designed to work together under real volume.
Twopir Consulting has delivered Salesforce for 12+ years, and Service Cloud specifically for most of them. We know the configuration decisions that look fine in year one and break at scale in year two.
The implement / configure / build-on boundary is written into the scope before work starts. You are told which of the three you are buying, and custom code is argued for in writing rather than appearing on an invoice.
Most of our Service Cloud work starts with an org that is already live and underperforming. We are set up to audit, diagnose and rebuild in place — not to quote a clean-slate project because it is easier to price.
Twopir holds both Salesforce Partner and HubSpot Partner credentials. When support has to connect back to the wider customer lifecycle, we design both sides of that integration rather than one.
Real volume finds what UAT does not. We stay engaged through the first 30–60 days after launch to catch the edge cases, tune the routing and make sure adoption holds once the project team has moved on.
Yes — they are the same product under two names. During the 2025–26 Agentforce rebrand, Salesforce began marketing Service Cloud as Agentforce Service, alongside similar renames across its other clouds. Your licences, API names, object names and existing metadata are unaffected, and Salesforce documentation and the product UI still say "Service Cloud" in most places. In practice you will see both names for some time, so it is worth using both when searching for documentation or partners.
A focused implementation covering case management, email-to-case, basic automation, entitlements and reporting typically takes 8–12 weeks. A more comprehensive engagement that adds omni-channel routing, CTI integration, a Knowledge Base build, a customer self-service portal, back-office integrations and AI configuration typically runs 16–24 weeks. The real drivers are the number of channels, integration complexity, data migration volume, and whether you are starting clean or redesigning an existing org. We set a milestone plan before any build begins.
Configuration covers the case data model, record types, queues, assignment and escalation rules, entitlement processes and milestones, Knowledge structure, reports and dashboards, and most automation through Flow — which is the large majority of what a support operation needs. Custom development starts when the agent experience needs an interface Salesforce does not ship (a Lightning Web Component), when logic must run at a volume or complexity Flow cannot handle reliably (Apex), or when an integration needs real error handling and retry rather than a scheduled file. We argue that boundary case by case and put it in writing, because custom code is the most expensive part of a Salesforce org to own over time.
Usually yes, and this is the most common engagement we run. The pattern is consistent: the org is technically live, agents have built informal workarounds beside it, SLA data is not trusted, and leadership cannot pull a report they believe. We run a structured audit of the case model, routing logic, automation, entitlements, integrations and adoption, then rebuild the parts that are failing inside the existing org. The exception is a case data model that cannot support what the business now needs — where that is true we say so and scope the rebuild honestly, rather than automating around a foundation that will not hold.
If you route work through Omni-Channel, yes. Salesforce retired Standard Omni-Channel with the Summer '26 release and orgs that were not migrated lose Omni-Channel work assignment — agents cannot log in to Omni-Channel and are not assigned work. Salesforce upgraded many orgs automatically, but an automatic upgrade is not the same as a validated one: routing configuration, capacity models and supervisor tooling all behave differently enough that they need testing in a sandbox against your own queues. Salesforce documents the retirement and the upgrade path in its Standard Omni-Channel Retirement notice. If you are unsure which version you are on, that is a five-minute check we can do in an audit.
Yes. We integrate Service Cloud with ERP systems such as NetSuite, SAP and Microsoft Dynamics, billing platforms including Stripe, Zuora and Chargebee, telephony and CTI tools including Genesys, Five9, Amazon Connect, Twilio and RingCentral, and product usage or analytics systems — so agents have full customer context without switching applications. We use MuleSoft, Workato, Celigo or native APIs depending on integration complexity, data volume and the middleware you already own. Integration architecture is designed during discovery, not retrofitted after the build.
Zendesk and similar help desks are purpose-built for ticketing and work well for straightforward support workflows — they are often faster to stand up and simpler to run. Service Cloud is native to the Salesforce platform, which means it shares a data model with Sales Cloud and everything else in your org. Where support performance is tied to retention, expansion or account health, that shared record is the deciding factor: the agent sees contract terms, product usage and renewal dates alongside the case. Service Cloud also handles complex entitlement structures, enterprise account hierarchies and multi-tier SLA management that a help desk generally does not. If none of those apply to you, a help desk may genuinely be the better buy.
We audit the Service Cloud org you already have — case model, routing, entitlements, automation and adoption — and hand back written findings with prioritised recommendations. If the answer is that you need less work than you thought, that is what the audit will say.
Response within 24 hours · We start with diagnosis, not a sales call · Contact the team