OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow service experience practice

ServiceNow service level and experience management with useful measures

ServiceNow service level and experience management translates a service commitment into conditions the platform can measure and the operating team can act on. OBLYTECH helps organisations connect scope, timer rules, calendars, ownership, targets, user experience, exceptions and review evidence.

Discuss ServiceNow service-level and experience priorities

Define the service promise before the timer

State what is being promised and to whom. A response target, restoration target, resolution target and fulfilment target describe different work. Define the record types, priorities, services, assignment groups and conditions that determine eligibility. Avoid describing a service level in terms no owner can maintain.

Choose start, pause, stop and breach conditions

Write the lifecycle in plain language before configuring it. What starts the clock? Which states pause it? What stops it? What happens if the record is reopened, reassigned, cancelled or incorrectly classified? Waiting for a requester may be different from waiting for an internal team, supplier, approval or change window.

Match calendars and ownership to real work

Specify the calendar, time zone, holidays and support window that apply. A precise target using the wrong calendar produces arguments instead of useful decisions. Assign ownership for the record, service-level definition, calendar and breach response; these may be different roles.

Connect service measures to user experience

Review what the measure tells a user and what it leaves unclear. A record can meet a target while the requester does not know the next step, receives repeated handoffs or experiences an outcome that does not match the service promise. Use service-level evidence alongside communication, reopens, feedback and ownership signals.

Turn breach and feedback data into review decisions

A breach is a prompt for investigation, not a conclusion about performance. Review whether the target was appropriate, classification correct, workflow moving, information available and calendar or pause condition aligned with the service agreement. Separate a measure problem from a service problem and assign each to its accountable owner.

For the operating baseline, see ServiceNow ITSM and Service Operations. For workflow evidence, review ServiceNow Risk Assessment and Control Testing.

Discuss ServiceNow service-level and experience priorities

Bring one target, breach pattern, calendar rule or user-experience gap that is difficult to interpret. OBLYTECH can help define the service promise, conditions, ownership, evidence and review decision.

Start the conversation

Why a service target fails before it is ever configured

Service level targets are often written in a meeting, approved by a sponsor and then handed to a platform team to configure. The problem is that the target was approved without a precise definition of the work it measures. Someone asks for a four hour resolution target, and the configuration starts. Weeks later the team discovers that the target begins when a record is created, not when the request is accepted, that it stops when a ticket is placed in any waiting state, and that it applies to a request type nobody considered. At that point the target is technically working and practically meaningless.

The first decision therefore sits upstream of any timer. It is the statement of what is being promised, to whom, for which record types and under which conditions. The promise should be written in the words a requester would use, then translated into the conditions a platform can evaluate. If the translation cannot be made without an argument about edge cases, the promise is not yet ready to be measured.

Promise as written in the meetingQuestion the configuration needs answeredUsually decided by
Users hear back quicklyWhat counts as hearing back: acknowledgement, assignment or a substantive reply?Service owner with the support lead
Access requests are done in two daysDoes the clock include approval time, and which approvals are inside the service?Process owner with the approvers
Critical faults are restored fastIs the target for a workaround, a full fix or a confirmed restoration?Incident owner with the business sponsor
Premium customers get priorityWhich field identifies premium status, and who keeps it accurate?Data owner with the account team

Each row in the table is a sentence that sounds finished in a meeting and turns out to contain at least one decision that has not been made. The configuration work is mostly the process of finding those decisions and assigning them to someone who can answer.

Writing the lifecycle in plain language before configuring it

A timer has a start, one or more pauses, a stop and a breach. Describing that lifecycle in plain sentences before anything is configured reveals most of the disagreements.

Pauses deserve the most scrutiny. Waiting for the requester is not the same as waiting for an internal team, a supplier, an approval or a change window. Each of those has a different owner and a different fairness argument. A single pause state applied to all of them will hide the cause of delay, and it will make the breach figures look like a team failure when the delay sat outside the team’s control.

  • Write the start condition as an observable event, such as the moment a record is assigned to a group with an accepted status.
  • Name every pause state and give it an owner who can end the pause.
  • Describe reopening as either a new target or a continuation of the old one, and record which.
  • State what a reclassification does to the target, since priority changes are a common source of disputed breaches.

Calendars, time zones and the hours nobody remembers

A precise target calculated on the wrong calendar produces arguments rather than decisions. Support windows differ by region, public holidays differ by country, and some services run around the clock while others run on business hours with an on-call rota at night. The calendar that governs a target has to be stated explicitly, including the time zone in which the working hours are defined and the holidays the organization observes.

Calendars also change. A regional office opens a new site, a service moves to a follow-the-sun model, or a holiday policy is revised. Each change can alter every open target, and the team should know whether a calendar change applies to records already in progress. A simple rule is that changes apply to new records only unless the service agreement says otherwise, and that rule should be written into the definition.

Calendar elementDecision to recordTypical failure if left implicit
Working hoursThe hours for each service and regionTargets breached overnight that nobody was staffed to meet
HolidaysWhich holidays apply, and to which locationA regional holiday counted against a global team
Time zoneThe zone in which hours are definedBreaches that appear shifted by several hours
Change of calendarWhether new rules affect open recordsHistorical reports that change after publication

Who owns what in a service level

A service level has at least four owned parts: the record that carries it, the definition of the target, the calendar it uses and the response when it is breached. These may belong to different roles, and treating them as one responsibility is a common cause of slow correction. The person who maintains the calendar may not be able to change the target, and the person who receives the breach alert may not know whether the target itself is correct.

Breach response should be defined before the first breach happens. A breach is a signal that prompts a review, not a conclusion about performance. The review asks whether the target was appropriate, whether the classification was correct, whether the workflow moved as designed, whether the information needed to act was available, and whether the pause conditions matched what the agreement says. Only after those questions are answered should a team decide whether the problem is in the measure or in the service.

Measuring the record and measuring the experience

A record can meet every target and still leave the requester confused. The status may show resolved while the requester is waiting for a confirmation email that was never sent. A target may be met on the day when the request was assigned, while the person who needs the outcome has been passed between three teams. Service level evidence tells part of the story, and the rest sits in communication, reopens, feedback and the number of handoffs a request endured.

Experience measures should be defined with the same care as the targets. A requester survey sent after closure reflects the last interaction more than the whole journey. Reopen rates reflect the quality of closure. The count of handoffs reflects the design of the routing. Each signal needs to be read alongside the target it is meant to test, so that a meeting target is not treated as proof of a good experience.

MeasureWhat it tells youWhat it does not tell you
Target met rateWhether the clock ran within the defined conditionsWhether the requester knew the next step
Reopen rateWhether closure matched the outcomeWhether the wait before closure was acceptable
Handoff countHow often ownership movedWhether each move was necessary
Requester feedbackHow the journey felt at the point of askingWhether the outcome was technically correct

Turning breach and feedback data into review decisions

Breach reports become useful when each breach is assigned to a review category, such as measure problem, service problem, data problem or calendar problem. The category decides who acts. A measure problem goes to the person who owns the definition, a service problem goes to the delivery lead, and a data problem goes to the owner of the field that was wrong. Without the categories, every breach is discussed by everyone and resolved by no one.

Patterns matter more than single breaches. A cluster of breaches on one day of the week may indicate a rota gap, a cluster on one request type may show a definition that does not fit the work, and a cluster after a particular change may reveal an unintended side effect. A short monthly review of the top breach patterns, with a named owner for each, keeps the service levels aligned with the work they describe.

Should every service level have a pause for waiting on the requester?

Usually yes, but the pause should be time-limited or should require a recorded reason, so that a request cannot wait indefinitely outside the target while looking like it is progressing.

How many targets should one service carry?

Enough to distinguish the main stages the requester cares about, and no more. A target for every internal handoff tends to create a dashboard full of breaches that nobody can act on.

Can a service level be changed mid-period?

It can, but the change should be recorded with its effective date, and the review should say whether the change applies to open records. Silent changes make historical reporting impossible to trust.

What is the right first target to configure?

The one whose promise is easiest to state in a sentence that both the requester and the delivery team would accept. A simple, well-understood target builds the habits needed for the harder ones.

Next step for service level and experience design

If targets exist but nobody agrees what a breach means, the useful next step is to define one service promise from intake to closure. Discuss your service level and experience design and bring one target that is regularly disputed, the calendar it uses, and the last three breaches with the reasons recorded. That is enough to decide which conditions need to be rewritten first. The change window guide and the blackout window guide explain change windows and blackout windows, the periods when changes may or may not be deployed to production. For the reporting layer, the dashboard guide explains what a ServiceNow dashboard is, a workspace that combines charts, scorecards and tables in one view. The proactive monitoring and maintenance route covers monitoring a ServiceNow instance for performance issues, security vulnerabilities and bottlenecks, and the value realization operating model route connects platform work to service ownership, workflow evidence, exceptions and decisions.

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

Related guides

More in this section