ServiceNow Case Management for Customers Requirements Workshop Questions

A case management requirements workshop asks what kinds of cases the team will handle, how they escalate, and when they are resolved. The questions cover case types, escalation and handoffs between teams, investigation and context capture, resolution criteria, and reporting.

Case Management as a Distinct CSM Discipline

Case management handles complex customer issues that require coordination across multiple teams and multiple steps to resolution. Unlike incident management, which focuses on restoring service quickly, case management focuses on investigating, escalating, and resolving customer issues that may take weeks or months. A case might start with a customer complaint, require investigation by engineering, then coordination with legal before resolution. The workshop questions for case management focus on case lifecycle, escalation, handoffs, and follow-up to ensure nothing falls through the cracks.

Case Types and Initial Categorisation

The first set of questions focuses on what types of cases you will handle and how cases enter the system. Will all customer support requests start as cases, or only complex issues? Will some requests be handled as simple incidents and only escalated to cases if they become complex? Will cases come from support tickets, customer calls, email, or a combination? Initial categorisation decisions determine the volume of cases your team will handle and the complexity of routing rules.

Examples of case types might include: billing disputes, technical issues requiring investigation, feature requests with customer impact, account problems, complaints about service quality, and contractual disputes. Each case type may have different routing, escalation, and resolution criteria. A technical issue might escalate to engineering; a billing dispute might escalate to finance; a quality complaint might escalate to management. Clear case types help route cases to the right team quickly.

Another categorisation question is whether cases can span multiple issue categories or should be split into separate cases. If a customer reports that a feature is missing and the product is also missing functionality that prevents using that feature, is that one case or two? Linked cases that reference each other work, but the rule should be clear so support staff categorise consistently.

The warning sign is having too many case types or unclear definitions. If you define thirty case types and support staff cannot remember the differences, categorisation becomes inconsistent, and routing fails. Aim for five to ten clear case types, each with a distinct resolution path. You can always add more types as patterns emerge, but starting simple is more sustainable.

Escalation and Multi-Team Coordination

Case management is fundamentally about escalation and handoffs. Questions about escalation focus on when cases escalate, who decides, and how the case status and ownership change. Will first-level support screen cases and escalate only when needed? Will certain case types go directly to specialists? Will cases escalate automatically based on age or customer segment, or only when a team member manually escalates?

A typical escalation path might be: customer submits case, first-level support acknowledges and investigates, escalates to engineering if investigation suggests a technical issue, engineering investigates and potentially escalates to product management if the issue points to a design flaw. At each handoff, the case must include enough context that the next team understands what has been tried and what questions remain.

A critical design question is ownership and accountability during handoffs. Does the case stay assigned to the original support agent while it is with engineering, or does engineering take ownership? If engineering takes ownership, do they update the case status in ServiceNow? If the original agent keeps ownership, how do they know when engineering has finished investigating? Clear ownership rules prevent cases from stalling when teams assume the other team is handling it.

Another escalation question is bypassing normal escalation for high-value customers. Should a case from your largest customer automatically escalate to a senior engineer? Should major customers have direct escalation paths? Customer segmentation in escalation is common but requires careful communication to support staff. If it is not clear to first-level support why a case escalated immediately, they feel bypassed and may resent it.

The warning sign is cases stalling during handoffs. If a case is assigned to engineering but engineering does not update the status for a week, and the support agent cannot reach anyone to follow up, the customer gets no communication and satisfaction drops. Before going live, define clear expectations: how long can a case wait between teams? Who follows up if a case has not been touched in a certain time? What does escalation to management look like if a case is stalled?

Investigation, Troubleshooting, and Context Capture

Case investigation questions focus on how teams will document what they have tried, what they have learned, and what questions remain. Will teams use case notes, work logs, or both? Will customer communications be logged as case activities? Will cases track configuration changes attempted during investigation, or just the outcomes?

A well-structured case investigation looks like: case opened with customer description, support performs initial troubleshooting, documents findings, escalates with all findings included. The escalated team reads the history, identifies gaps, and performs their own investigation. Each team adds findings and next steps. The history grows as the case progresses, creating a complete audit trail.

The design question is how to make case history readable and useful for busy teams. Long, rambling notes are hard to scan. Structured approaches (investigation log with dates, actions, results) are clearer. Some teams use a case summary that gets updated as new information emerges, with detailed notes separate. The structure you choose affects how quickly teams can understand case history.

Another consideration is whether to attach files to cases: troubleshooting logs, diagnostic reports, screenshots, configuration exports. File attachments provide context but require storage management and security controls. Some teams use external file storage and link to files from cases; others attach files directly.

The warning sign is losing context during escalation. If a case escalates to engineering but the notes do not clearly explain what first-level support already tried, engineering wastes time redoing troubleshooting. Before escalating, require teams to summarise what has been tried and what the current hypothesis is.

Resolution Criteria and Customer Acceptance

Questions about resolution focus on what counts as case closure. Can support close a case unilaterally, or must the customer confirm resolution? What happens if the customer disagrees that the issue is resolved? How long do you keep a case open for follow-up questions before final closure?

One approach is: support resolves the issue (or exhausts reasonable troubleshooting), notifies the customer, and leaves the case open for a confirmation window that your team sets. If the customer responds that the issue is fixed, the case closes. If the customer reports the issue persists, the case reopens and escalates again. If the customer does not respond within that window, the case closes and the customer can reopen it if needed.

Another resolution question is what to do with cases that cannot be resolved. If a feature the customer requests is not planned for development, is that a closed case (escalated to product management) or an open case waiting for product decisions? Clarity on closure criteria prevents cases from hanging open indefinitely.

A customer satisfaction question is whether the closing team contacts the customer or whether the customer must verify resolution. Proactive contact (support reaches out to confirm resolution) has better satisfaction outcomes than waiting for customers to respond. However, it requires more effort and potentially more touches with the customer. The choice depends on your support model and customer expectations.

The warning sign is case clutter. If you have hundreds of open cases, some of which have not been touched in months, case management has become ineffective. Set and enforce closure criteria. Create a quarterly review process where old, stalled cases are either actively worked or closed with an explanation to the customer.

Case Metrics, Reporting, and Knowledge Reuse

The final set of questions focuses on what metrics you will track and how you will use case data to improve. Will you track case volume by type? Case resolution time? Customer satisfaction? Will you analyze closed cases to identify common issues that should become knowledge articles or product improvements?

Case analytics is valuable when used well. If ten cases report the same issue, that is a signal that the issue is common and either a knowledge article should be created or a product change should be made. If cases of a certain type consistently take longer than others, that is a signal that you may need specialist training or workflow changes for that type.

Another reporting question is whether you will share case metrics with the customer. Some organisations publish monthly case summaries showing what issues were handled, how many, and average resolution time. This transparency builds trust. Others keep case data internal. The choice depends on your customer relationships and what you are comfortable sharing.

A final consideration is knowledge capture. When a case is closed, should the resolution be documented in a knowledge article so future cases of the same type are resolved faster? This requires discipline and ownership of the knowledge base. If the knowledge base is not actively maintained, it becomes outdated and teams ignore it, wasting the opportunity to use case data to improve future cases.

The warning sign is tracking metrics without acting on them. If you know that a particular case type takes three times longer to resolve than others, but you do not investigate why or make changes, the metrics become noise. Use case data to inform decisions: staffing, training, process changes, or product feedback.