Most Service Cloud implementations cover the basics: case object configuration, queues, email-to-case, a console layout. That's enough to go live. It's not enough to go live well.
The gaps tend to show up 4–8 weeks post-launch: cases falling through the cracks, SLAs being tracked incorrectly, agents doing manual work that was supposed to be automated. Here are the 10 setup steps that prevent most of those problems.
1. Configure Case Assignment Rules With Fallback Routing
Most implementations set up case assignment rules for the standard scenarios — product type, case origin, customer tier. What they miss is the fallback rule: what happens when no assignment rule fires.
By default, unmatched cases go to the case creator or a default queue. That's often wrong and sometimes disastrous. Create an explicit "catch-all" rule at the bottom of your assignment rule list that routes to a dedicated triage queue, always staffed.
2. Set Up Escalation Rules Before Go-Live
Escalation rules aren't glamorous, but unescalated cases that age past SLA are the fastest way to damage customer relationships and trigger compliance issues.
Configure escalation rules that:
- Fire based on case age (not just priority)
- Notify the assigned agent AND their manager
- Auto-reassign if the agent hasn't responded within a defined window
Test these in sandbox with date/time manipulation before go-live.
3. Enable and Configure SLA Entitlements Properly
Many implementations add Entitlements to the data model but never fully configure them — so SLA tracking exists in name only.
Entitlements need:
- Entitlement processes with time-based milestones (First Response, Resolution)
- Stop/start triggers (clock should pause when a case is pending customer response)
- Violation actions tied to escalation rules
Without these, your SLA reporting is misleading at best.
4. Build a Knowledge Base With a Governance Process
Cases get resolved faster when agents have access to good knowledge articles. Most implementations create Knowledge but don't establish:
- Who is authorised to create and publish articles
- A review workflow for new and updated articles
- An expiry/review date process for articles that go stale
Knowledge without governance becomes a graveyard of outdated articles that agents stop trusting.
5. Configure Omni-Channel With Capacity and Skills
If you're using Omni-Channel for case routing, the default capacity settings rarely match real-world agent workloads. An agent with capacity set to 10 simultaneous cases will be overwhelmed; one set to 2 will be underutilised.
Work with your service managers to set realistic capacity per channel. Also configure Skills-Based Routing if your team has specialisations — it ensures complex cases go to agents who can actually resolve them, not just whoever has capacity.
6. Set Up Case Teams for Complex Accounts
For accounts that require cross-team collaboration on cases, Case Teams allow you to define named roles (Account Manager, Technical Lead, Customer Success) and pre-populate team members based on account ownership.
This prevents the common failure mode where a case gets escalated but no one knows who else needs to be looped in.
7. Configure Duplicate Management for Case Contacts
When customers email your support address from multiple email accounts, they end up as duplicate contacts — and agents lose the case history context they need to resolve issues efficiently.
Implement duplicate rules and matching rules for Contacts, and brief agents on how to merge records when they spot duplicates. A messy contact database is one of the biggest invisible drags on service team productivity.
8. Enable Case Feed and Activity Timeline
The Case Feed (Lightning Service Console) gives agents a unified view of all case activity. But it's often not configured to show the right channels by default — agents end up missing email replies or internal comments.
Customise the Case Feed settings to surface the most relevant activity types first, and make sure the Timeline includes activities from all connected channels.
9. Build Reports That Track What Actually Matters
Standard Salesforce reports are available from day one, but they rarely answer the questions service managers actually care about. Before go-live, build a Service KPI dashboard that includes:
- Average First Response Time by queue and agent
- Cases by status, age bracket, and priority
- SLA compliance rate (not just open/closed count)
- Escalation volume by root cause
These reports need to be usable on day one, not built retrospectively when someone asks why CSAT dropped.
10. Document the Process for Handling After-Hours Cases
This sounds non-technical, but it's consistently the gap that causes real customer harm. What happens to a high-priority case that arrives at 11pm on a Friday?
Decide before go-live:
- Which case priorities trigger after-hours notification
- Who gets notified (PagerDuty, SMS, email to personal address)
- What the SLA clock behaviour is outside business hours
Then configure it. Don't leave it as "we'll handle it when it happens."
MeetTheMind Insight 💡
The best Service Cloud implementations I've been part of had one thing in common: the service manager was in the room for the design sessions, not just the sign-off.
When the people who will use the system every day are involved in configuring it, the edge cases get surfaced before go-live. When they're kept out until UAT, the edge cases become post-go-live incidents.
If you're running a Service Cloud project, make sure your service operations lead is a collaborator in design, not just a stakeholder in delivery.
Key Takeaways
- Always configure a fallback assignment rule — don't leave unmatched cases to default routing
- Entitlements need milestone configuration and pause triggers to be meaningful
- Knowledge without a governance process becomes untrustworthy quickly
- Set Omni-Channel capacity based on real workload data, not defaults
- Build your KPI dashboard before go-live, not after the first management review