Decide how work arrives and how you categorize it
List the channels customers use today: email, phone, web forms, chat, social messages. For each, decide how requests become cases and what information must be captured at creation. Then design the case model: types, reasons, priorities, and statuses. Keep the lists short and meaningful, because they drive routing, reporting, and automation. A case reason list with sixty options produces unreliable data, while eight clear ones produce insight.
- Limit case types and reasons to what you will actually report on.
- Define status meanings so everyone uses them the same way.
- Capture the customer, product, and order context at creation where possible.
Routing, queues and workload
Routing decides who sees which case. Start with queues by skill or product line, and add rules for priority customers, language, and urgency. Omnichannel routing can distribute work based on agent capacity and availability. The aim is to reduce the time a case waits and avoid cases that fall between teams. Review queue ageing daily at first, because unbalanced queues reveal routing mistakes quickly.
Entitlements and service-level commitments
If customers have different levels of service, make that structured information. Entitlements record what each customer is owed and milestones track the time to respond and resolve. Agents see how much time remains, and managers see which cases risk breaching. Define business hours and holidays accurately, since time calculations depend on them, and decide what happens when a milestone is missed.
Implementation and integration services →Knowledge that agents and customers can use
Knowledge reduces handling time and creates consistent answers, but only if articles are written well and kept current. Assign authors and reviewers, set review dates, and make it easy to create an article from a resolved case. Publish suitable articles to a help center so customers can find answers themselves, and track which articles resolve cases and which are never used.
Experience Cloud for self-service →Automation, templates and quality
Automate the repetitive parts: acknowledgments, assignment, reminders, and status updates. Use templates for common responses, but keep them human, and review them regularly. Build in quality review, such as sampling closed cases against a checklist, so improvement is based on evidence and coaching is specific. Automation should remove effort from agents, not make interactions feel mechanical to customers.
Decisions to settle before configuration
- Case model. Agree the types, reasons, and priorities, and who may change them.
- Service levels. Define response and resolution targets by customer or issue, and the escalation for breaches.
- Knowledge ownership. Name authors, reviewers, and the cadence of review.
- Measures. Choose the handful of metrics you will review weekly, such as first response, resolution time, and satisfaction.
A realistic first 90 days
- Days 1 to 30. Map channels and the case model, clean customer data, and define service levels.
- Days 31 to 60. Configure routing, entitlements, and knowledge, and pilot with one team.
- Days 61 to 90. Add automation and reports, roll out to remaining teams, and review the first full month of metrics.
Pitfalls to avoid
- Overlong case reason lists. They produce unreliable data. Keep them short.
- Knowledge as an afterthought. Without owners and reviews, articles decay and agents stop trusting them.
- Ignoring agent experience. A cluttered console slows work. Design the agent page with the people who use it.
- No feedback loop. Use case data to fix product and process problems, not only to measure agents.
