OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow ITSM Process Review: Establish a Useful Baseline

A ServiceNow ITSM process review establishes how work actually enters, moves through, and leaves incident, request, problem, change, and knowledge processes. The purpose is to identify decisions, ownership gaps, handoff friction, unclear rules, and improvement priorities before changing configuration.

For ITSM owners establishing a baseline review before changing processes or platform configuration..

ServiceNow ITSM process reviewServiceNow ITSM assessmentITSM process health
Discuss this ServiceNow topic

Guide map

Measuring current incident and request handling

Set the questions the review must answer

Write each question so that it points to a decision the review can inform.

Trace work from intake to closure

Pick a few representative records and follow each one from intake to closure.

Examine ownership, handoffs, and exceptions

Check who holds each record at each handoff and where exceptions go.

The practical framework

Run a ServiceNow ITSM process review around demand, ownership, workflow evidence, handoffs, priorities, knowledge, exceptions, and improvement actions.

Begin with a small set of questions the review must answer. For example: where does work wait, who can make the next decision, which information is missing at intake, and where do users or agents take a different path from the documented process?

Set the questions the review must answer

Define the services, processes, teams, records, and time period in scope. Do not promise a complete assessment if the review only covers selected workflows. State what evidence will be examined: record samples, process definitions, ownership decisions, knowledge, handoff notes, configuration, or stakeholder observations.

The ServiceNow health-check and audit route is the relevant internal destination when the baseline needs a structured assessment and evidence record.

Connect each question to a decision. If the review asks whether intake should change, examine the information needed downstream. If it asks whether a team needs another handoff, examine the decision and authority that the handoff provides.

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 state transitions, records that wait without an owner, and steps that occur outside the platform. An off-platform step is not automatically wrong, but the process should make its ownership and evidence visible.

The ServiceNow process optimization route provides an internal path when the review finds inconsistent workflow decisions or avoidable manual work.

Examine ownership, handoffs, and exceptions

For each transition, identify the person or group that owns the next decision. Distinguish assignment from accountability. A group may receive a record while a service owner remains accountable for the customer-facing outcome.

Review exceptions explicitly: incomplete information, priority changes, reassignment, reopened records, approvals that wait, failed integrations, unavailable staff, and requests outside a standard path. Exceptions often reveal where the designed process does not match the work.

The ServiceNow support and maintenance route is the appropriate internal destination when findings involve operating ownership, support handoff, or ongoing maintenance.

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 will happen next. A status may say “in progress” while no team has a current action. A knowledge link may exist while the article does not answer the question.

Compare the process promise, the platform behaviour, the record evidence, and the user explanation. Differences should become findings with an owner and a decision rather than a general statement that the process feels difficult.

Turn findings into a sequenced improvement backlog

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

The ServiceNow continuous-improvement route gives the reader an internal path for sequencing improvements and reviewing whether they solved the original problem.

Common questions

Questions teams ask about an ITSM process review

Should a review start with platform configuration?

Usually, start with the work and the decisions the process must support. Configuration can then be examined in context. Beginning with fields and scripts alone can mistake an implementation detail for the underlying process problem.

What makes a process finding actionable?

It should describe the observed condition, consequence, evidence, accountable owner, decision required, and next action. “Improve the process” is too broad to guide a release or an operating change.

The research-grounded boundary

The vetted research relevant to this subject sits in customer implementations and industry use cases and includes discussion of ServiceNow platform and ITSM. It does not establish an OBLYTECH result or a universal product promise. Its useful contribution is a boundary: a service or business outcome needs defined inputs, an accountable owner, a visible exception path, and evidence that another person can review. For the itsm process review baseline question, that means the page should name the owner, the evidence, and the point at which a person reviews or corrects the result.

Pull a sample that shows the real process, not the reporting month

A baseline review is only as honest as the records it reads. A sample taken from the last calendar month can look clean because a backlog was cleared that week, or messy because a major incident inflated one category. Build the sample on purpose. Take records from each process, from each assignment group that matters, and from both ordinary and unusual periods, then keep the selection method written down so the review can be repeated after changes.

On the platform the useful fields are the ones that show movement rather than the final state. Reassignment counts on tasks show where ownership bounced. Reopen counts show where a resolution did not hold. Time in each state shows where work waited without an owner. Comments and work notes show whether the next person knew what to do. Combine these with the closed-state field, which often hides how a record got there.

Match each evidence source to what it can and cannot show

Evidence sourceWhat it reveals wellWhat it can hideHow to pair it
Record sample with transition historyWhere work moved, stalled or came backWhy a person made a choiceInterview the groups that handled the sampled records
Standard process definitions and flowsWhat the process is meant to doWhat people actually do when the path is inconvenientCompare the documented path with the most common transitions
Reporting dashboardsVolumes and averages across the periodIndividual exceptions and the records behind the averagesDrill into the outliers and read a handful end to end
Knowledge articles linked to recordsWhether guidance existed at the moment of workWhether the article was useful once foundAsk users whether the article answered the question
Stakeholder observationThe workaround that never reaches the platformPatterns that only show up across many recordsCheck each claim against a sample before it becomes a finding

Run the baseline in a fixed sequence

  1. Write the questions the review must answer, such as where incidents wait for a second team, or which requests are approved twice.
  2. Define the scope by process, service and group, and state plainly what the review will not cover.
  3. Draw the stratified sample and record the selection rule, so the same rule can be used at the next baseline.
  4. Trace each sampled record from intake to closure, noting every handoff, reassignment and state that lacked a current action.
  5. Read the outliers in full, and separate a one-off event from a repeating pattern before classifying anything.
  6. Check each finding with the group that owns the step, and agree whether the fix is a configuration change, a process decision or a question for discovery.

What usually surfaces in the first pass

The first pass often finds the same few problems. Incidents bounce between two groups because the routing rule sends a category to a team that no longer owns the service. Change requests wait in an approval state for a person who has left the role but remains a named approver. Requests are re-keyed into a second tool because the catalog item does not carry the data the fulfilment team needs. None of these is unusual, which is why the sampling step matters: a finding that appears in a handful of records and one that appears across most of the sample need different responses.

Signs the review has become a report

A review becomes a report when its findings cannot be traced to specific records, when the recommendations are not assigned to owners, and when the same findings come back in the next baseline without any recorded decision. Another sign is a findings list where every item is rated high. Use the sample to rank items, and be willing to say that a concern is real but small.

When to delay the baseline

Postpone a baseline if the platform is about to change in a major way, such as a migration of a whole process, because the baseline would describe a state that will not last. It is also wise to wait if the team reviewing the process is the same team that will be judged by its results and cannot step back. In that case bring in a reviewer from outside the immediate team, and say so in the scope.

How large should the record sample be?

Large enough that each process and each important group appears more than once, and small enough that every record can be read end to end. A sample that cannot be read properly is worse than a smaller one that is.

Should the review include records that were rejected or cancelled?

Yes. Cancelled and rejected records show where requests were misunderstood at intake, and they often reveal the workarounds that people use to avoid the designed path.

Who should receive the findings?

The owner of each process step named in the finding, plus the process owner who approves the improvement order. Findings sent to a general mailing list rarely lead to a decision.

How often should the baseline be repeated?

After any significant change to routing, approvals or the service catalog, and on a fixed review cycle agreed by the service owner. Compare each repeat with the previous sample to see whether the same findings are still present.

Scoping the baseline

If the ITSM process has drifted from its design and the team is not sure where the drift starts, start by writing down the questions the review must answer and what it will not cover. The ServiceNow health checks and audits page describes a related assessment of a ServiceNow instance, and the knowledge quality review guide covers reviewing knowledge articles for accuracy and usefulness.

ITSM process review: task fields, tables and values to read first

An ITSM process review reads movement, not just outcomes: how often a record changed hands, reopened or sat waiting. On the platform those signals sit in a handful of standard fields and tables, so a first pass can start from data already stored.

The names below are common out-of-box values. Check them on your own instance and release, because labels, choice lists and defaults change between releases and many sites have renamed or extended them.

NameWhere it livesWhat it shows a reviewer
reassignment_countIncident tableHow many times the record changed assignment group, a rough marker of bounced ownership
reopen_countIncident tableHow often a resolution did not hold
sys_auditAudit history tableField-level changes on audited tables, including who changed state or group and when
task_slaTask SLA tableWhich service level agreements attached to a task and whether they were breached
metric_instanceMetric results tableTime spent in a measured state or group, where metric definitions are active
New, In Progress, On Hold, Resolved, Closed, and, on some releases, CanceledIncident state choicesThe standard lifecycle to compare with what the sampled records actually did

Example (hypothetical): a reviewer pulls a set of incidents from a service desk and sorts them by reassignment_count. The records with the most reassignments are read first. Many start in a general queue and move twice before reaching a team that owns the service. The finding is not that the queue is slow. It is that intake never captures the affected service, which is a decision for the service owner, covered in the incident management guide.

Why read reopen counts as well as closure dates?

A closure date only says a record ended. A reopened record says the earlier resolution was accepted by the system but did not hold for the person who raised it, which points to weak validation or unclear close notes.

Can a review rely on reports over the incident table alone?

Only as a start. Incident reports show state, group and dates, but request and change work lives in other tables. Cover every process the review claims to assess.

How does assignment history differ from ownership?

The assignment group field names who holds the record now, and audit history lists earlier holders. Neither names who is accountable for the outcome. Add the service owner recorded for the service and confirm it with the group; the incident priority explanation shows how impact and urgency set priority, which decides how quickly a hand-off should happen.

When findings cross several records, take them to problem management, and repeat the same sample after changes using the ITSM service operations baseline as the working route.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

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

More from the blog

Related reading