Service Cloud · the order the work goes in
Channels are the visible part.
The case model is what decides whether it works.
Most Service Cloud builds are planned as a list of channels to switch on. The channels are the cheap part. What costs is the order, because a phase built against a guess gets rebuilt at full rate three months later. Below is the sequence that avoids that, and what each phase has to produce before the next one starts.
Reviewed 30 August 2026.
Before the seven
Two sentences decide the whole build.
What counts as a case, and what has to be true before one closes. Everything else in Service Cloud is an expression of those two answers: the record types, the queues, the reports, the escalation rules and what the dashboard means.
They are usually left implicit, because they feel too obvious to write down. Then three people turn out to have three answers, and the disagreement surfaces as a reporting problem in month five rather than as a modelling conversation in week one.
The sequence
Seven phases, and the order is the point.
Each one is cheaper if the one before it genuinely finished, and more expensive if it did not. Two of them are routinely done too early, and those two account for most of the rework in this category.
Decide what a case is, and when it is finished
Before any channel exists, two sentences have to be written down and agreed: what counts as a case, and what has to be true for one to close. This sounds like paperwork and it is the whole build. Every record type, every queue and every report downstream is an expression of those two sentences, and changing them in month four means changing all three.
One channel, and it is the one that needs nothing from the customer
Email to case goes first in almost every build, because it changes nothing on the customer side: they keep writing to the address they already use. That makes it the only channel that can be switched on without a communications plan, and it produces the volume data that every later decision needs.
Queues before assignment rules
Work lands in a queue, and people pull from it when they have capacity. The alternative, assigning each case to a named person on arrival, looks tidier and quietly loses work every time somebody is on leave. Queue first is the single configuration choice that most reliably separates a support system that survives a holiday season from one that does not.
Escalation and entitlements, only once volume is known
Entitlements, milestones and escalation rules are the part of Service Cloud most likely to be built against a guess. Built in phase one they encode somebody idea of the volume. Built after a month of real cases they encode the volume. The second version is smaller, cheaper and does not need rewriting.
Knowledge written from cases that already happened
A knowledge base written before go live is written from imagination, and the articles nobody needed are indistinguishable from the ones nobody found. Written after a month of real cases it is shorter and every article answers a question somebody actually asked. Start with the ten most repeated cases and nothing else.
Reporting, and the business hours decision
Response and resolution times have to be measured with non-working hours excluded, and that decision belongs here rather than in an options screen. Raw elapsed time counts nights, weekends and holidays against the team, so a case opened at 17:00 on Friday reads as a three day failure. Exclude the hours nobody was working and the same case reads as one hour, which is what happened. A metric the team does not recognise is worse than no metric.
Handover, written while it is being built
The description of why the case model is shaped the way it is has to be written during the build, by the person making the decisions. Written afterwards it is a reconstruction, and it omits exactly the decisions that will be reversed by somebody in a year who did not know why they were taken.
Routing
Omni-Channel is a good answer to a problem you may not have yet.
When it is right it is genuinely good, and when it is switched on early it is a layer of configuration that has to be maintained, explained and debugged in exchange for nothing. Four ways it goes wrong, in the order they are usually found.
Capacity set before anything was measured
Routing distributes work against a capacity number per agent. If that number was chosen in a configuration screen rather than derived from how long cases actually take, routing will confidently overload some people and starve others while reporting that it is balanced.
Skills based routing without defined skills
Skills based routing is only as good as the skill definitions behind it. Without them it is queues with more configuration and more places to go wrong. Define the three or four skills that genuinely change who should take a case, and stop there.
Presence statuses nobody uses honestly
The routing engine believes the presence status. If the team treats it as decoration, or if there is no status that means available but finishing something, people set themselves away to get work done and the queue backs up behind a wall of unavailable agents.
Routing switched on before there are enough agents
With four agents in one queue, routing solves a problem that does not exist and adds a layer that has to be maintained and explained. It earns its keep when there are enough people and enough channels that a human cannot hold the allocation in their head.
How it turns into debt
Four habits that make year two expensive.
None of these break anything on the day. All four make the system harder to change later, which is the only definition of technical debt that means anything operationally.
Every channel at once
Email, web, chat and phone opened together means four sets of volume assumptions made simultaneously, none of them checked against reality, and no way to tell which channel is responsible when the numbers look wrong.
Auto responses that create loops
An auto response to an address that itself auto responds is a loop, and it is found in production by the case count rather than in testing. The check is cheap and almost never run.
Closing rules nobody agreed
Cases close when the agent thinks they are done, or after a timer, or when the customer stops replying, and different people use different ones. Resolution time then measures a mixture of three behaviours and is quietly abandoned.
Record types added instead of decisions taken
Each unresolved disagreement about how support works becomes another record type with its own layout and its own path. A year later the reason for the split is gone and the maintenance is not.
Where it meets the rest
Support is where the Account definition gets tested.
Sales works in Accounts and Opportunities. Support works in Cases against the same Accounts, and creates Contacts that marketing never sees. If the three were built as separate projects, this is the phase where that shows: duplicate people, entitlements against an Account model designed for selling, and attribution that stops at the sale.
Built together it is one data model and the seams do not exist. Three clouds designed as one system is 335 hours against 439 bought separately, and the difference is exactly this kind of work.
Asked often enough to answer here
Questions
Which channel should go first?
Email to case, in almost every build, because it is the only one that needs nothing from the customer and produces volume data immediately. Chat and phone should follow once there is a month of real cases to size them against. The exception is an organisation whose customers already live in one channel exclusively, in which case that one goes first and email follows.
Do we need Omni-Channel routing at all?
Not at the start, and often not for a long time. With one queue and a small team it adds a layer to maintain and solves nothing a person could not see. It becomes worth the configuration when there are enough agents, channels and skill differences that allocation stops being obvious.
When should the knowledge base be built?
After a month of real cases, from the ten questions that repeated most. Before go live it is written from imagination, and the effort goes into articles that turn out to answer nothing anybody asked. Later is cheaper and shorter, and short is what gets read.
Why does the order of phases change the cost?
Because each phase priced against a guess has to be rebuilt when the guess is wrong, and the rebuild is at full rate under time pressure. Entitlements built before volume is known and a knowledge base written before go live are the two that are rebuilt most often. Doing them later is not a delay, it is the cheaper sequence.
What is the smallest honest version of this?
7,250 euro for 145 hours: the case model, email to case, queues, reports, up to fifteen agents, training and a sixty day handover. Each additional channel, entitlements and routing are scoped on top at the same rate and shown as separate lines rather than folded in. Every price on this site is hours multiplied by fifty.
€7,250 for 145 hours at the smallest scope, which is hours multiplied by fifty like every other price here. Channels, entitlements and routing are scoped on top and shown as their own lines.
Serhii Skrypnyk · Senior Salesforce Administrator and developer · 7 Salesforce certifications · on the platform since 2018. Reviewed 30 August 2026.