Set up Service Cloud in the order a case travels: design the case record, decide which channels create cases, route each case to the right queue or agent with Omni-Channel, attach entitlements and milestones so response and resolution commitments are tracked, and give agents knowledge they can trust. Reporting comes last because it depends on all of the above. Most troubled Service Cloud orgs were built out of order, with channels switched on before anyone decided where the cases should go.
Start with the case record
Every later decision depends on how a case is described. Before configuring channels, agree on case record types (if you handle genuinely different kinds of work, such as product questions, orders and complaints), a status list that reflects real handoffs, and the few fields routing and reporting will depend on: product, severity, reason and account. Keep statuses few and unambiguous. "Waiting on customer" and "Waiting on internal team" are useful because they explain where time is going; five shades of "In progress" are not.
A biotech company we worked with started with six case record types, which later made it possible to introduce AI-drafted replies on the most common type first, internal-only, and expand from there. That phased approach was only possible because case types had been separated cleanly at the start.
Choose channels deliberately
Each channel creates cases differently and brings its own setup decisions. Turn on the ones your customers actually use, one at a time, and confirm routing works for each before adding the next. Channel availability depends on your Service Cloud edition and add-ons, so check your contract before planning around a specific one.
| Channel | How cases arrive | Decisions to make first | Common problem |
|---|---|---|---|
| Messages to support addresses become cases | Which addresses map to which queues; auto-response wording; how replies thread to existing cases | Replies and out-of-office messages creating duplicate cases | |
| Web form | A form on your site or help center creates a case | Required fields, spam protection, how the account is matched | Cases with no account because the email does not match a contact |
| Messaging and chat | Conversations routed to available agents | Hours of availability, handoff from any bot, when a conversation becomes a case | Customers repeating themselves after a handoff |
| Phone | Calls through Salesforce Voice or a telephony partner | Which telephony platform, screen pops, call logging | Calls handled with no case or activity recorded |
| Self-service portal | Customers log and track their own cases | What customers can see, which knowledge is public | Portal cases routed differently from email cases |
Route with queues first, then Omni-Channel
Queues are the foundation: one per team or type of work, each with a clear owner. Omni-Channel then pushes work from those queues to agents based on their availability and capacity, instead of agents cherry-picking from a list view. Design capacity honestly. If an agent can realistically juggle three chats or one phone call, the configuration should say so, or Omni-Channel will overload the people it is meant to protect.
Route on attributes only when you have them. Routing by product, language or severity works well when those fields are reliably filled at case creation; if they are not, cases fall back to a catch-all queue and the sophistication adds nothing. Start simple, measure where cases land, then refine.
Track SLAs with entitlements and milestones
Entitlements describe what a customer is owed, often tied to a service contract or support tier. An entitlement process applies milestones to a case, such as first response and resolution, each with a time limit that runs on the business hours you define. Milestone actions can warn the owner or a manager before a commitment is missed and escalate when it is.
The design work is agreeing on the commitments before configuring them. Which customers get which response times? Does the clock pause while you wait on the customer? What counts as a first response: an auto-reply, or a person? A payments company we worked with paired Service Cloud case routing with SLA escalations and Slack alerts, so breaches reached the right people where they were already working.
Make knowledge an owned product
Knowledge helps agents answer consistently, lets customers help themselves in a portal, and is what an AI agent will ground its answers in if you add one later. It only works if articles are accurate. Give each article an owner and a review date, write articles from real cases rather than from a documentation backlog, and retire articles that no longer match the product. For the biotech company, 19 well-maintained knowledge articles were enough to power AI-drafted responses because each one answered a question customers actually asked.
Go-live checklist
- Case record types, statuses and required fields agreed with team leads.
- Every channel tested end to end: a test case arrives, lands in the right queue and reaches an agent.
- Unmatched cases go to a monitored catch-all queue with a named owner.
- Agent capacity and presence statuses configured and explained to agents.
- Entitlement processes and business hours reviewed against the commitments in customer contracts.
- Knowledge articles for the most frequent questions published, each with an owner.
- Dashboards for open cases by queue, cases nearing or past milestones, and backlog age.
- A plan for the first weeks after launch: who watches the queues and who can change routing.
A cybersecurity company we worked with followed a similar crawl-walk-run path when it replaced a homegrown ticketing tool: email-to-case, queues, severity levels, escalations and auto-response came first, alongside Sales Cloud, and core functionality went live in roughly 6-8 weeks.
