Service Cloud · implementation and rebuild
Every channel you add
is a project of its own.
Service Cloud is not one implementation. It is a case model, plus one integration per channel, plus a knowledge base nobody wants to write. Describe the shape below and the estimator prices each part separately, because that is how they actually consume time.
Elapsed
-
Fixed price
-
Scale
-
Engagement
-
What makes up the price
Phases
Every line above is a fixed price, not a range. It becomes the contract price once the written scope is signed, and it cannot move upward afterwards. Everything is built inside your own org and documented as the work happens, so nothing here depends on any one person staying available.
What actually takes the time
The case object is easy. Routing is not.
A case record takes an afternoon. Deciding who a case goes to, what happens when they do not answer, and how that changes at two in the morning takes weeks, because it is a business decision wearing a technical costume.
The case model
Record types, statuses, reasons, queues, and the difference between a case that is closed and a customer whose problem is solved. Agreed in writing before anything is built.
Channels
Email-to-case is an afternoon. Telephony, chat, WhatsApp and a customer portal are each a separate integration with a separate vendor, separate credentials and a separate go-live.
Routing and SLAs
Omni-Channel, skills, capacity, entitlements, milestones and business hours. Straightforward to configure and slow to agree, which is the reverse of what most plans assume.
Knowledge
Article types, approval flow, and the uncomfortable part: someone has to write the articles. This is also the prerequisite for any agent answering customers later, which is worth knowing now.
Fit
Worth reading before you book.
This is for you if
- Between 5 and 200 support agents with a real SLA to meet
- You want routing rules written down rather than living in one person's head
- Agentforce is on the roadmap and you would rather build the knowledge base once
- Someone in-house will own the queues after handover
- You want routing documented as it is built, not reconstructed later
This is not for you if
- You want a contact centre platform rather than Service Cloud
- The requirement is to replicate Zendesk field for field
- Nobody will commit to writing knowledge articles
- The go-live date is fixed before the scope is
The base package
What EUR 11,000 already contains.
Service Cloud is priced per channel because that is how it consumes time. The base covers the part every rollout needs regardless of how customers reach you.
A case model that survives contact with reality
Record types, statuses, reasons and the distinction between a case that is closed and a customer whose problem is solved. Written down before anything is configured, because these definitions decide what every report afterwards is capable of saying.
Queues, assignment and escalation
Who a case goes to, what happens when nobody picks it up, and how that changes outside business hours. Configured in days, agreed in weeks, which is the reverse of what most plans assume.
Email-to-case
The channel every rollout starts with. Threading, auto-response, attachments and the rules that stop an out-of-office reply reopening a solved case at three in the morning.
Reporting managers actually open
Backlog by age, first response and resolution against target, volume by reason, and agent workload. Built from the questions asked in your operations meeting rather than from a template.
Training, documentation, sixty days after
Sessions for administrators and for agents, both recorded. Then sixty days of questions answered while the queues meet real volume, because the routing that looked right in a workshop rarely survives the first busy Monday unchanged.
Sequencing
Which channel to launch first, and which to launch second.
The most common Service Cloud mistake is launching every channel on the same morning. When something breaks, and something always breaks, nobody can tell which channel caused it.
Email first, always
It is asynchronous, so a routing mistake costs minutes rather than a dropped call. It carries the highest volume in most B2B operations, which means the case model gets stress-tested properly. And it is the cheapest channel to unpick if the model turns out wrong.
Then chat, if you have the staffing
Chat exposes capacity honestly. An agent handling three concurrent chats is not handling three cases well, and the routing has to know that. Launch it once you have a month of email data telling you what your real concurrency looks like.
Telephony when the vendor is ready, not when you are
This is the channel with an external dependency you do not control. The integration is straightforward; getting the telephony vendor's API credentials and a test window is not. Start that conversation in discovery, not in the channel phase.
The portal last, and only with knowledge behind it
A self-service portal without a populated knowledge base is a contact form with extra steps, and customers learn that within a week. Deflection is a promise the knowledge base keeps, not the portal. Launch them together or launch neither.
Knowledge
The part everyone postpones and later pays for twice.
Knowledge is boring, unglamorous, and returns more than anything else in a service implementation. It is also the prerequisite for any customer-facing agent you deploy afterwards, which makes postponing it an expensive decision rather than a neutral one.
What I build
Article types, the approval workflow, templates, categorisation and search tuning. Data categories mapped to how customers describe problems, not to how your product is organised internally. Those two are rarely the same thing.
What you do
Write the articles. There is no way around this and no consultant should pretend otherwise. The realistic starting point is your twenty most repeated questions, which your agents can list from memory in one meeting.
Why it matters more in 2026
Every customer-facing agent reads from knowledge. An agent with no knowledge base does not stay silent, it improvises, and improvisation in front of a customer is the failure mode that ends agent programmes. The knowledge base is the guardrail.
Questions
Asked often enough to answer here.
Is moving from Zendesk to Service Cloud worth it?
Only if your service and revenue data need to be in the same place. Zendesk is a better help desk in isolation. Service Cloud wins when a support conversation has to inform a renewal, an escalation has to reach an account owner, or an agent needs to reason across both. If none of that applies, staying put is the cheaper answer and I will say so.
Will everything from an existing help desk map to Service Cloud?
No, and planning for that is the difference between a smooth migration and a bad quarter. Some custom fields have no equivalent, some automations were workarounds for a limitation that does not exist here. Deciding what to drop is a business call, best made before migration rather than during.
Is Field Service included in a Service Cloud implementation?
It is a separate product with its own licences, its own mobile application and its own scheduling engine. Bundling it into a Service Cloud number produces a figure nobody can defend, so it is priced on its own line and scoped separately.
How many support agents justify Service Cloud?
Around five. Below that the routing rules cost more to maintain than they save, and a shared inbox with discipline outperforms a configured queue without it. Above fifteen, the absence of a proper case model starts showing up in your resolution times.
Can channels be added after go-live?
Yes, and I would rather you did. Each channel added later is priced at the same figure shown in the estimator, and a channel added onto a working case model takes less time than one launched alongside four others.
Bring the estimate to the call.
Thirty minutes. Read out what the estimator gave you and I will tell you where it is optimistic, where it is generous, and which channel I would launch second rather than first.
Serhii Skrypnyk · RevOps Architect · 7 Salesforce certifications · on the platform since 2018