ServiceNow Service Level Management Requirements Workshop Questions

A Service Level Management requirements workshop is the session where a team settles which services need SLAs, what response and resolution times they can honestly commit to, and how breaches escalate. The page gives the question sets for each of those decisions, the warning signs in the answers, and how to turn the answers into a requirements register.

The question sets below cover SLA scope, response versus resolution and multi-tier targets, escalation actions, calculation and exclusions, and reporting and accountability. Each set says what the answers decide, and the later sections cover warning signs in the answers, choosing attendees by what they can commit to, follow-up questions that expose vague answers, and turning the answers into a requirements register.

The workshop focuses on: what services need SLAs (all services or just critical ones?), what response and resolution timeframes are realistic (can we commit to 1-hour response for critical incidents?), how should SLAs vary (by service, by customer criticality, by time of day?), and how should escalation work (when does an at-risk incident escalate?). Each question reveals current performance and commitments, sometimes creating tension between what the business wants and what IT can deliver.

Questions About Service and SLA Scope

Scope questions establish which services need SLAs. Do all services need SLAs or just customer-facing services? Do internal services (HR systems, finance systems) need SLAs? Are SLAs mandatory (all incidents tracked against SLAs) or optional (some incidents outside SLA scope)? Should SLAs apply only during business hours or 24/7? These questions define the footprint of SLM.

A critical question: are current SLAs realistic? If the organisation commits to 1-hour response for critical incidents but typically responds in 4 hours, the SLA is not credible. The workshop should establish what is actually achievable, then decide whether to commit to it or invest to meet it. Starting with realistic SLAs that are met builds credibility; overly aggressive SLAs that are always missed create cynicism.

Questions About Response, Resolution, and Multi-Tier SLAs

Response versus resolution questions establish different SLA milestones. Response SLA (acknowledge the incident, assign to a team) can be faster than resolution SLA (actually fix the problem). Should we have both or just resolution? Multi-tier SLAs (a first response, regular updates, then a resolution target) acknowledge that showing progress matters even if resolution is slow. Do they align with business expectations?

Differentiation questions address how SLAs should vary. Critical incidents might have aggressive SLAs (1-hour response, 4-hour resolution); medium incidents looser SLAs (4-hour response, 24-hour resolution). Premium customers might have shorter SLAs than standard customers for the same incident severity. Should SLAs differ by time of day (stricter during business hours, looser after hours)? These questions determine SLA complexity and fairness.

Questions About Escalation and Escalation Actions

Escalation questions establish what happens when an SLA is at risk. Should escalation be automatic (when SLA timer reaches most of deadline, alert the supervisor) or manual (management reviews at-risk incidents)? Should escalation automatically move the incident to senior teams or just notify them? Should breached SLAs trigger management review or just reporting? These questions shape how SLM changes operational behaviour.

Another question: what is the escalation path? (At-risk alert goes to the incident owner, then to supervisor, then to management?) Who can override escalation procedures? (Can management approve working on an incident past SLA deadline?) Escalation clarity prevents confusion during outages when quick decision-making matters.

Questions About SLA Calculation and Exclusions

Calculation questions address how SLA time is measured. Does time stop when the incident is waiting for customer response, or does it count against the SLA? Do we exclude weekends and holidays from SLA calculation, or count them? If an incident is paused while waiting for hardware to arrive, does SLA pause also? These rules affect fairness and whether SLAs are achievable.

Exclusions questions establish when SLAs do not apply. Should system outages that affect all customers (not a failure to respond, but infrastructure failure) be excluded from SLA reporting? Should SLAs apply during planned maintenance windows? These questions recognise that some incidents are outside the control of the support team.

Questions About Reporting and Accountability

Reporting questions establish what metrics matter. Should we report SLA compliance by team, by service, by customer, or all three? Should we track trend (compliance improving or declining)? Should root causes of SLA breaches be investigated, or just reported? These questions shape what data is captured and how accountability is assigned.

An important question: what happens if SLA compliance is low? Is it a trigger for investigation and improvement, or for blame and punishment? Teams that fear punishment for SLA breaches will game the system (close incidents prematurely, set unrealistic data, slow down improvements). Teams that see low SLA compliance as a signal that something is broken will investigate and improve. The workshop should establish a culture of continuous improvement, not blame.

Warning Signs from Workshop Answers

Red flags include: teams cannot articulate what the current SLAs are (indicating SLAs exist on paper but are not enforced), business stakeholders expect SLAs that IT cannot realistically deliver (1-hour response 24/7 with current staffing), or there is no clear escalation procedure (indicating SLM will track metrics but not change behaviour). These signals require deeper conversation before proceeding with implementation.

Setting up a session that produces usable answers

A requirements workshop produces value only if its answers survive the room. Many workshops generate a lively discussion and a whiteboard photograph, and then the implementation team is left to guess what was agreed. The fix is to treat the workshop as a capture exercise. Every answer that bears on a target, a calculation rule or an escalation path is written down in a form that can be checked later, tagged with its source and with whether it was agreed or only offered. A workshop that ends with a register of twenty clear answers is worth more than one that ends with a long list of opinions.

Run it in a fixed order. Start with the services and their owners, because every later question depends on knowing what is being measured and by whom. Move to the commitments the business believes it has, then to what the support teams actually deliver, and only then to the targets. Reversing that order invites people to set targets before anyone has established what the current performance is.

Choosing attendees by what they can commit to

Invite the people who own a service, the people who run the queues that will carry the work, and at least one person who speaks for the business consumer of each service. Do not rely on a manager to answer for their team’s calculation rules if the team does the work. The people who will be asked to hit a target need to hear the question in the room, because a target agreed by someone who does not carry it can be renegotiated within a quarter. An internal audit or compliance representative is worth including when SLA timelines may be used as evidence.

Follow-up questions that expose vague answers

Many workshop answers arrive in a form that sounds complete and is not. The table pairs the answer a facilitator often hears with the follow-up that tests it, and the gap the follow-up reveals. Use it to stop the workshop accepting an answer that will break at implementation.

Turning answers into a requirements register

After the session, convert the notes into a register with one row per requirement. Each row needs the service it applies to, the decision it supports, the exact wording of the agreed answer, the person who agreed it, and a status of agreed, provisional or open. Provisional items are the ones where the owner accepted a position but the data to test it does not yet exist. Open items need a closing owner and a date attached. The register is the document the configuration team works from, so it should be shared, versioned and reviewed before any configuration begins.

Resist the urge to tidy the register into a single summary. Keep the raw wording of each answer, because it is the evidence of what was agreed if a dispute arises later. The governance expectations for changing a requirement after it is agreed are covered in the governance model guide.

Questions a workshop cannot settle on its own

Some questions need data that does not exist in the room. How often does the current process breach its targets? Which tickets lack a usable priority? How many contracts carry the same service under different terms? Log these as open items, each with a named analyst and a deadline. A workshop that tries to settle them by discussion often produces targets that are argued into place and then fail the first time the data is examined.

Another group of questions is about trade-offs that only the business can make, such as whether a faster response is worth additional staffing cost. Put those to the sponsor directly, with the options and their consequences written out, rather than leaving them for the implementation team to resolve.

Common workshop questions people ask afterwards

How long should a requirements workshop run?

Long enough to cover every service on the scope list with its owner present, and no longer than the owners can keep their attention. Several shorter sessions with the same people often produce better answers than one long session, because the follow-up work between sessions gives the owners time to check their data.

What if two service owners give contradictory answers?

Record both answers and mark the item as open. Do not pick one to keep the session moving. Contradictions often mean the services overlap or the customer is shared, and the resolution is a design decision that belongs to the sponsor.

Should the workshop agree final targets?

It should agree the logic for targets and the reasoning behind them. Final numbers should follow once the current performance has been measured, because a target agreed before that measurement can be unrealistic in one direction or the other.

Questions about the requirements session

Background on what SLM covers is in the plain-language introduction to Service Level Management.