Salesforce · Customer Service Platform

Salesforce Service Cloud, architected for the volume you actually run.

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.

  • 45% Faster first response
  • 60% Less manual admin
  • 8–12wk Core build
Service Cloud Lifecycle
CHANNELS & CONTEXT Email · Web · Portal Email-to-Case · Experience Cloud Voice · Chat · Messaging Open CTI · Digital Engagement ERP · NetSuite / SAP Billing · Stripe / Zuora Product usage · Health SERVICE CLOUD LAYER · TWOPIR-ARCHITECTED Case Model & Routing Record types · Queues Enhanced Omni-Channel Entitlements & SLA Milestone timers Breach warnings Knowledge & AI Articles · Data categories Agentforce · Einstein ONE CASE RECORD · ONE SOURCE OF SLA TRUTH 2πr SERVICE OUTCOMES First Response Routed on arrival, not on a queue sweep Breaches Prevented Warned before the milestone expires Deflected Volume Answered by Knowledge before a case opens
12+
Years of Salesforce delivery
500+
Clients served worldwide
40+
Certified delivery specialists
15+
Platform partnerships

Trusted by 500+ organizations — including SaaS, healthcare and enterprise support teams running customer service on Salesforce with Twopir Consulting.

Social Justice Collaborative
Bernstein Liebhard LLP
LegalZoom
Sterling Law Offices
Sterling Law Offices
Social Justice Collaborative
Bernstein Liebhard LLP
LegalZoom
Sterling Law Offices
Sterling Law Offices

Built for Service Operations

  • Salesforce Partner
  • Service Cloud
  • Enhanced Omni-Channel
  • Entitlements & SLA
  • Salesforce Knowledge
  • Agentforce
  • Experience Cloud
  • Open CTI & Voice
Where Support Breaks

The signs your Service Cloud is not working for you

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.

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.

SLAs are tracked in a spreadsheet, not in Service Cloud

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.

Agents cannot see the whole customer

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.

The Knowledge Base exists but nobody trusts it

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.

Leadership cannot get support metrics they believe

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.

Service Cloud is live and agents work around it

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.

What It Is

Service Cloud is a platform. The architecture is what performs.

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.

Three Different Engagements

Implement it, configure it, or build on top of it

"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.

Engagement 01

Implement

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.

  • Case data model, record types and status lifecycle
  • Enhanced Omni-Channel routing and capacity model
  • Entitlement processes and milestone configuration
  • Knowledge taxonomy and authoring workflow
  • Migration from an existing help desk, with parallel run
Where it stops

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.

Engagement 02

Configure & Rescue

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.

  • Full architecture audit: case model, routing, automation
  • Entitlement and milestone repair, breach alerting
  • Automation and Flow consolidation, logic redesign
  • Standard to Enhanced Omni-Channel migration
  • Adoption analysis and agent workflow fixes
Where it stops

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.

Engagement 03

Build On

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.

  • Lightning Web Components for the agent console
  • Apex services, triggers and asynchronous processing
  • ERP, billing and product-usage integrations via API
  • Agentforce actions and custom AI grounding
  • Experience Cloud self-service portal development
Where it stops

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.

What We Deliver

The parts of Service Cloud that decide whether it performs

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.

Case Management Architecture

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.

  • Record types, case origins and status lifecycle design
  • Priority and severity matrix, mapped to real triage
  • Email-to-Case and Web-to-Case capture and routing
  • Assignment, escalation and auto-response rules
  • Case teams and shared case model for enterprise accounts

Enhanced Omni-Channel Routing

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.

  • Standard to Enhanced Omni-Channel migration and validation
  • Skills-based and attribute-based routing configuration
  • Work item capacity and agent workload balancing
  • Routing across email, chat, messaging and voice
  • Overflow, fallback and supervisor console setup

Entitlements, SLAs & Milestones

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.

  • Entitlement process design and account-level mapping
  • Milestone timers with automated warning thresholds
  • Breach escalation flows and auto-reassignment
  • Support tier differentiation across contract levels
  • SLA performance dashboards for support leadership

Knowledge & Self-Service

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.

  • Article data categories and record type design
  • Article lifecycle, review cadence and approval workflow
  • In-case article suggestion and attach-to-case flow
  • Experience Cloud customer self-service portal build
  • Knowledge analytics and content gap reporting

Agentforce & Einstein for Service

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.

  • Einstein Case Classification against real historical data
  • Agentforce Service Agent for digital channel deflection
  • Article recommendation and agent reply assistance
  • Custom Agentforce actions and grounding on your data
  • Honest readiness assessment before anything is licensed

Service Analytics & Dashboards

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.

  • Volume, resolution and backlog reporting
  • SLA compliance and milestone breach tracking
  • Agent productivity and handle time dashboards
  • CSAT and NPS tied back to the case record
  • CRM Analytics for advanced service intelligence
Integration Architecture

What has to reach the case screen before an agent says hello

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.

NetSuite & SAP

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 time

Stripe, Zuora & Chargebee

Subscription 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 load

Genesys, Five9 & Amazon Connect

Open 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-directional

Product Usage & Health

Feature 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 sync

MuleSoft, Workato & Celigo

The 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 retry

Slack & Microsoft Teams

Escalations 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 replies

Experience Cloud Portal

Authenticated 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 record

Zendesk & Freshdesk Migration

Historic 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 cutover
How We Deliver

Four phases, and a system that holds under real load

A 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.

Phase 01

Operational Audit & Architecture

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.

Phase 02

Core Build: Case Model, Routing & SLA

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.

Phase 03

Automation, AI & Integration

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.

Phase 04

UAT, Go-Live & Optimisation

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.

Client Outcomes

What Service Cloud looks like when it actually works

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.
VP of Customer Success US-based SaaS company · 280 employees · Series C Healthcare Technology
Client Engagement

US Healthcare SaaS · 280 Employees

Service Cloud rebuild with ERP integration and omni-channel routing.

38% Lower average handle time
First-contact resolution
14wk Full implementation
Browse Client Case Studies
★★★★★
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.
Director of Support Operations UK-based legal technology platform · 400 employees Legal Technology
Client Engagement

UK Legal Technology · 400 Employees

Full Service Cloud rescue — case model, entitlements, Knowledge and dashboards.

52% Fewer SLA breaches
Knowledge Base usage
12wk Rescue and rebuild
See Legal Sector Work
Who This Is For

Built for the people Service Cloud performance lands on

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.

VP of Customer Success or Support

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.

CIO or IT Director owning the platform

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.

Head of Service Operations in a regulated sector

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.

RevOps lead or Salesforce admin at a scaling company

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.

Why Twopir

Not a licence reseller. An architectural partner.

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.

Salesforce depth, not generalist coverage

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.

We say where configuration stops

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.

Rescue is a first-class engagement

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.

Service, sales and marketing on one record

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.

We stay past go-live

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.

Common Questions

Answers before the first call

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.

Next Step

Start with a diagnosis, not a proposal

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