How ServiceNow ITOM and Discovery Bill, and Where the Run Rate Hides
ITOM and Discovery license on subscription units tied to base class configuration items, benchmarked at $80 to $200 per unit per year. Across the estates we benchmark, 15 to 25 percent of the ITOM run rate sits in stale CIs and oversized cloud scope before the discount conversation starts.
Prepared by Redress Compliance · June 2026 · Representative ServiceNow estate scenario (benchmark scenario, not a quote)
Executive Summary
ServiceNow ITOM does not bill the way the rest of the Now Platform does. Workflow products such as ITSM and CSM price per fulfiller. ITOM Discovery prices on subscription units tied to base class configuration items, the scanned infrastructure that lands in the CMDB, not the people who use it.
That single mechanic drives most of the overspend we see. A subscription unit benchmarks at $80 to $200 per unit per year, and a 4,000 to 8,000 unit estate carries $320,000 to $1.6 million on the ITOM line alone. The number scales with what you scan, so unmanaged scope is unmanaged cost.
AIOps stacks a second meter on top. Event Management licenses per managed node, and Health Log Analytics adds Predictive AIOps as a separate pool. Cloud Discovery adds a third meter, priced per managed cloud resource, which can double count assets you already discover on premises.
In the worked estate below, a re baselined CMDB, a right sized cloud scope, and a capped uplift reset a $1.57 million ITOM run rate and avoid about $1.2 million across three years. The deadline is your renewal date, not the vendor quarter. Start the baseline at month six so the scope cleanup is real before the first commercial conversation.
How does ServiceNow ITOM Discovery actually bill?
ITOM Discovery bills on subscription units, not seats. A subscription unit maps to a licensable base class configuration item that Discovery finds and maintains in the CMDB. The meter scales with scanned infrastructure, so the cost follows your scope decisions, not your headcount.
ServiceNow does not publish ITOM list prices, and every contract is custom. The defensible benchmark for ITOM Visibility is $80 to $200 per subscription unit per year, with the rate falling as volume rises. ITOM Health and ITOM Optimization carry their own meters and their own rate cards.
The four ITOM meters that stack
- ITOM Visibility: Discovery plus Service Mapping, priced per base class subscription unit.
- ITOM Health: Event Management and Metric Intelligence, priced per managed node.
- ITOM Optimization: cloud governance and cost, priced per managed cloud resource.
- Health Log Analytics: Predictive AIOps log analytics, priced as a separate pool.
Decompose the run rate into these four lines before any renewal. A single bundled ITOM figure hides where the cost sits and removes your ability to challenge one line without reopening the whole agreement.
| ITOM meter | Metric | Volume | Benchmark rate | Annual |
|---|---|---|---|---|
| ITOM Visibility (Discovery, Service Mapping) | Subscription unit, base class CI | 8,000 SU | $110 | $880,000 |
| ITOM Health (Event Management) | Per managed node | 3,000 nodes | $95 | $285,000 |
| ITOM Optimization (Cloud) | Per managed cloud resource | 12,000 resources | $18 | $216,000 |
| Health Log Analytics (Predictive AIOps) | Pooled log ingest | 1.5 TB per year | Pooled | $190,000 |
| Total ITOM run rate, Meridian Freight Group scenario | $1,571,000 | |||
Benchmark scenario, not a quote. Visibility is the largest single ITOM line in most estates we benchmark.
How are Discovery patterns and CMDB classes counted for licensing?
Licensing counts base classes, not every record in the CMDB. Discovery patterns populate hundreds of referenced CIs for each device, yet only the base class CI is licensable. A single compute that spawns 300 plus software, process, and file system records still costs one subscription unit.
This is the most misread mechanic in ITOM. Buyers see a CMDB with hundreds of thousands of CIs and assume the license tracks that number. It does not. The licensable count is the population of base classes such as cmdb_ci_computer, cmdb_ci_netgear, and cmdb_ci_storage.
What counts and what rides free
- Counts as a subscription unit: servers, network gear, and storage devices in their base class.
- Rides free: software install records, running processes, and relationships referenced under a base CI.
- Counts twice if you let it: a cloud virtual machine discovered both on premises and through a cloud connector.
| CMDB population | Base class | CMDB records | Licensable SUs |
|---|---|---|---|
| Physical and virtual servers | cmdb_ci_computer | 6,000 | 6,000 |
| Network devices | cmdb_ci_netgear | 1,500 | 1,500 |
| Storage devices | cmdb_ci_storage | 500 | 500 |
| Software install records | cmdb_sam_sw_install | 140,000 | 0 |
| Running processes | cmdb_running_process | 220,000 | 0 |
| Total CMDB records vs licensable subscription units | 368,000 | 8,000 | |
Benchmark scenario, not a quote. The license tracks base classes, so 360,000 referenced CIs carry no subscription unit cost.
Where the common advice on ITOM scope is wrong
The standard reseller pitch is to discover everything, because a fuller CMDB looks like more value. We disagree. Scanning everything inflates the cloud resource meter and the managed node meter, and leaves stale base class CIs that the platform keeps charging for.
The buyer move is to scope Discovery to the base classes you actually operate against. Retire stale CIs before each renewal so the subscription unit count reflects the live estate.
How does AIOps consumption stack on top of the platform?
AIOps is a second meter, not a feature of Discovery. It runs on the CMDB that Discovery populates, but it bills separately through ITOM Health and Health Log Analytics. Buyers who assume AIOps is included in Visibility are surprised by the stacked cost.
ServiceNow groups Event Management, Metric Intelligence, and Health Log Analytics into Predictive AIOps. Event Management licenses per managed node, Metric Intelligence rides within the Health pool, and Health Log Analytics meters log ingest as its own pool.
The three AIOps consumption drivers
- Managed nodes: Event Management benchmarks at $60 to $150 per managed node per year.
- Metric volume: Metric Intelligence scales with the number of monitored metrics and CIs.
- Log ingest: Health Log Analytics meters the volume of operational logs analyzed, pooled per year.
| AIOps layer | Metric | Volume | Benchmark rate | Annual |
|---|---|---|---|---|
| Event Management | Per managed node | 3,000 nodes | $95 | $285,000 |
| Metric Intelligence | Within Health pool | Monitored metrics | Pooled | Included |
| Health Log Analytics | Pooled log ingest | 1.5 TB per year | Pooled | $190,000 |
| AIOps layer stacked on the Visibility meter | $475,000 | |||
The contrarian point on AIOps is restraint. Predictive AIOps prevents 25 to 35 percent of priority one outages in mature deployments, but the value only lands when the operations team acts on the alerts.
A committed AIOps pool that outruns the team that uses it is a write off. Size the node count and the log pool to the services you actually run to ground.
How does Cloud Discovery change the multi cloud math?
Cloud Discovery adds a third meter priced per managed cloud resource. ITOM Optimization and Cloud Discovery use Service Graph connectors to pull near real time inventory from AWS, Azure, and Google Cloud into the CMDB. Each managed resource counts, and resource counts move fast in elastic environments.
The multi cloud trap is double counting. A virtual machine discovered by on premises Discovery and again through a cloud connector can land as a Visibility subscription unit and a managed cloud resource. Without reconciliation rules, the same asset bills on two meters.
How cloud resources accumulate
- Elastic scaling: auto scaling groups inflate the resource count during peak load and leave orphan records behind.
- Tag sprawl: resources without governance tags are hard to retire, so they keep metering.
- Connector overlap: cloud connectors and on premises Discovery can both claim the same hybrid VM.
| Cloud provider | Metric | Managed resources | Benchmark rate | Annual |
|---|---|---|---|---|
| AWS | Per managed cloud resource | 7,200 | $18 | $129,600 |
| Azure | Per managed cloud resource | 3,600 | $18 | $64,800 |
| Google Cloud | Per managed cloud resource | 1,200 | $18 | $21,600 |
| Total cloud resources and ITOM Optimization spend | 12,000 | $216,000 | ||
Set a reconciliation rule that picks one meter per hybrid asset, and put a cloud resource ceiling in the contract so elastic growth does not silently expand the bill. A defined scope clause is worth more here than a deeper unit discount.
How do you negotiate ITOM inside a workflow bundle without overpaying?
ITOM is usually sold inside a broader Now Platform bundle, which hides the per meter rates behind one figure. Pull the ITOM lines out and price them against the four meter benchmark before you discuss any discount. A bundle discount on an inflated baseline is not a saving.
Three contract mechanics decide the outcome. The uplift escalator runs at 7 to 12 percent a year and compounds untouched unless you cap it. The subscription unit pool is a true up, not a true down, so you rarely get mid term credit for retired CIs. The order timing rewards a close in ServiceNow's fourth quarter, which ends in January.
The moves that hold the number
- Cap the uplift: negotiate a fixed annual escalator of 3 to 5 percent in the master agreement.
- Right size before signing: retire stale base class CIs and orphan cloud resources first.
- Write a substitution right: let unused ITOM units convert to other Now Platform value.
- Define cloud scope: set a managed resource ceiling so elastic growth needs a true up, not an open meter.
Run the rationalization before the discount conversation. In the worked estate, retiring stale CIs and orphan cloud resources removes about 18 percent of the run rate, and a 4 percent uplift cap holds the optimized number across the term.
Benchmark scenario, not a quote. Uncapped path compounds at 10 percent; negotiated path rationalizes 18 percent then caps the uplift at 4 percent.
The renewal sequence
Baseline and clean
Decompose the four meters, retire stale base class CIs, reconcile managed nodes, and remove orphan cloud resources before any vendor conversation.
Scope and clauses
Set the target estate, draft the uplift cap, the cloud resource ceiling, the substitution right, and the meter reconciliation rule.
Leverage and close
Hold the optimized baseline, time the close to ServiceNow's fourth quarter, sign with the clauses in place, then govern the meters quarterly.
Re baseline the four ITOM meters before you accept any renewal number. Retiring stale base class CIs, reconciling managed nodes, and removing orphan cloud resources returns 15 to 25 percent regardless of the discount, and it makes the discount conversation credible. Do this work before the renewal date, not at it.
- Separate the meters. Price Visibility, Health, Optimization, and Health Log Analytics on their own benchmarks, then challenge each line.
- Hold the number in the contract. The uplift cap, the cloud resource ceiling, and the substitution right are what stop the optimized run rate from drifting back at the next renewal.
Redress Compliance runs this framework on the buyer side only: measure the four meters, rationalize the estate, then negotiate against ServiceNow with the optimized baseline already in hand. We are glad to tie a meaningful part of the fee to delivered value.
Benchmark ranges: Redress Compliance advisory engagement file, 2024 to 2025. ServiceNow does not publish ITOM list prices; rates shown are defensible benchmarks, not quotes.
