OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow ITSM practice

ServiceNow ITSM and service operations with a useful baseline

ServiceNow ITSM and service operations work best when teams can see how work enters, moves through and leaves incident, request, problem, change and knowledge processes. OBLYTECH helps organisations identify decision gaps, ownership friction and improvement priorities.

Discuss ServiceNow ITSM and service-operations priorities

Set the questions the review must answer

Define the services, processes, teams, records and period in scope. State what evidence will be examined: record samples, process definitions, ownership decisions, knowledge, handoff notes, configuration or stakeholder observations. Connect each question to a decision so the review does not become an inventory.

Trace work from intake to closure

Follow representative work from the first request or incident report through categorisation, assignment, investigation, resolution, validation and closure. For requests, include fulfilment and communication. For changes, include approval, execution, validation and recovery evidence. Look for re-entry, manual copying, unclear states and records that wait without an owner.

Examine ownership, handoffs and exceptions

For each transition, identify the person or group that owns the next decision. Distinguish assignment from accountability. Review incomplete information, priority changes, reassignment, reopened records, waiting approvals, failed integrations, unavailable staff and work outside the standard path.

Compare workflow evidence with user experience

Read the record and listen to the people using the process. A field may be completed while the person still does not know what happens next. A status may say in progress while no team has a current action. Compare the process promise, platform behaviour, record evidence and user explanation.

Turn findings into a sequenced improvement backlog

Classify findings by service impact, user or support friction, data or access concern, dependency, effort and confidence in the evidence. Separate a configuration correction from a process decision, ownership decision, content change or capability that needs discovery. Give every action an owner and review point.

For platform review, see ServiceNow Platform Health Check Readiness. For workflow changes, review ServiceNow Workflow Data and Context Design.

Discuss ServiceNow ITSM and service-operations priorities

Bring one incident, request, problem, change or knowledge process that has unclear ownership, repeated handoffs or uncertain closure. OBLYTECH can help trace the work and turn evidence into sequenced decisions.

Start the conversation

Should the service operations review come before any platform change?

For many IT service leaders the question arrives in a familiar form. A platform upgrade is scheduled, a new module has been proposed, or a steering group wants to know why the request queue keeps growing. The instinct is to change the tool. The more reliable order is to find out what the current process is actually doing, because a platform change will reproduce whatever process it is given, including the parts that are failing. A service operations review answers that question with evidence from real records, before any decision is made about configuration or licenses.

The review is also the cheapest point at which to disagree. If the findings show that the change advisory board is approving work that nobody validates, the platform team can see the fix and the process owner can own it. If the findings show that requests are routed correctly but fulfilled slowly, the review points at capacity and skills rather than design. Those two conclusions lead to different investments, and a platform project chosen in advance tends to hide the difference.

Question for the steering groupWhat the review examinesDecision it supports
Why do requests take longer than the catalog suggests?Sampled requests from intake to fulfilment, with each wait recordedCatalog redesign, fulfilment capacity or approval change
Why are changes reopened after implementation?Change records, validation evidence and recovery notesChange design, testing standard or ownership of validation
Why do knowledge articles not reduce ticket volume?Searches, article views and the cases opened afterwardsContent review, routing or a different self-service route
Why is the backlog hard to explain?Ownership of each open record and the age of each waiting stateQueue ownership, reporting definitions or triage rules

Each question in the table should be tied to a decision before the sampling starts. Without that link, a review tends to produce an inventory of observations that nobody is able to act on.

Choosing the sample that tells the truth

A sample drawn from the top of a report is usually a sample of the easiest work. It shows the records that closed quickly and misses the ones that waited, bounced or were reopened. A better method draws records across the full age range, across more than one team, and across the categories that the steering group cares about. Samples that include cases which were cancelled, reassigned or escalated are the most informative, because they show where the design breaks under ordinary pressure.

Sample size should follow the question rather than a fixed rule. A review of change approvals may need a few dozen records to see a pattern in validation, while a review of a single catalog item may need only the records from the last quarter. The review should state which records were excluded and why, so that the findings can be checked by someone else.

  • Include records that were reopened, reassigned more than once, or waited for an approval longer than the normal period.
  • Include a mix of teams, so that a finding is not produced by one group’s habits.
  • Record the reason for each exclusion, such as a test record or a duplicate.
  • Read the notes and attachments, not only the status fields, since the status often says less than the notes.

Mapping ownership against the way work really moves

Process documents describe an intended owner for each step. Records show who actually acted. The gap between the two is one of the most useful findings a review can produce. It is common for an approval step to be owned by a manager in the process diagram while the work is picked up by an analyst who has no authority to approve it. The analyst then waits, the manager is not aware of the request, and the record shows a state that looks like progress.

A practical technique is to draw the ownership matrix from the records rather than from the documentation. List each transition that appears in the sample, the group that held the record before the transition, the group that held it afterwards, and the role that made the decision. Where the decision role is missing, or where two groups claim it, the process has a gap that no amount of configuration will close.

Reading the measures without being misled by them

Service operations reporting usually includes counts, averages and aging buckets. Each of these can be accurate and still misleading. An average time to close can fall because the team closes records earlier with incomplete information, which will then return. An aging report can show few old records because waiting records have been moved into a state that is excluded from the report. The review should check the definition behind each measure before using it to support a finding.

A review also needs a view of the people using the process. Records show what was done; conversations show why. A short set of interviews with requesters, approvers and fulfilment staff often explains a pattern in the records, such as a form that people complete with guesses because the real answer is not available at intake. The interview notes should be treated as evidence about the process, not as a verdict on individuals.

Turning findings into a sequenced backlog

A review that ends with a long list of findings has not finished its work. The findings should be grouped by the kind of action each one needs. Some need a configuration correction that can be made within the current design. Others need a process decision, an ownership decision or new content. Some need a capability that does not yet exist and must be scoped through discovery. Separating these prevents a team from attempting a platform change to solve a problem that is really about who approves a request.

Kind of findingTypical actionOwner
Configuration errorCorrect the field, rule or form, then retestPlatform team
Unclear approval authorityDecide the authority and record it in the process definitionProcess owner
Knowledge that does not match the processRevise or retire the article, with a review dateSubject owner
Missing capability with a real needScope through discovery before any buildService owner with the platform team

Each action should have one owner and one review point. A backlog without owners becomes a second queue, and the operations team ends up managing the improvement list rather than the service. The sequence should start with the findings that affect the largest group of users and that can be fixed without a new build, because those produce visible results and build confidence in the review.

What the review should not try to settle

A service operations review is not a staffing model, and it is not a license optimization exercise. It can show that a team is overloaded, but deciding how many people it needs requires workload data that the review may not hold. It can show that a module would help a specific process, but the value of the module depends on the process being stable first. Naming those limits in the report protects the review from being used for decisions it cannot support.

How long does a service operations review take?

The duration depends on the number of processes in scope, the age of the records and how many people must be interviewed. A narrow review of two processes is a different exercise from one that covers the whole service catalog, and the scope should state which one is being done.

Should the review include the platform configuration?

Yes, but only the parts that the sampled records use. Reviewing every table and workflow adds effort without changing the findings unless the sample shows that a configuration element is involved in the problems.

What if the records do not contain enough evidence?

That is itself a finding. Missing notes, unrecorded approvals and states that do not match the work often point to a process that depends on memory. The review should record the gap and recommend the smallest change that would make the next review possible.

Who should receive the findings?

The steering group should receive the decision list, and each process owner should receive the findings for their process with the supporting sample. Sharing the full record set widely is rarely necessary and can make people defensive about their own work.

Next step for a service operations review

If a steering group is about to commit to platform work without a clear view of how requests and changes actually move, a review of real records is a sensible first step. Discuss a service operations review and bring the two or three processes that cause the most repeated discussion, along with the reports the steering group currently uses. From those the review can define the sample, the ownership questions and the decisions it must support. The change governance and release management page covers ServiceNow change governance and release management, including approval and release evidence, and the change request and service catalog management page covers ServiceNow change, request and service catalog management. For the portfolio question of which services should exist at all, the service portfolio rationalization page covers rationalizing the services an organization operates. The assignment group guide explains how tickets are assigned to a group as a whole, and the continuous improvement page covers continuous improvement of a ServiceNow instance after implementation.

ServiceNow guides on this topic

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

Related guides

More in this section