ServiceNow Underpinning Contract Explained

What is an Underpinning Contract

An Underpinning Contract (UC) in ServiceNow defines the support commitment between Service Delivery (typically a service desk or customer-facing team) and IT Operations (infrastructure, database, or third-party provider teams). It establishes target performance levels, response times, escalation procedures, and escalation thresholds that the IT Operations team must maintain to support the service being delivered to end users.

The UC operationalizes the Service Level Agreement (SLA) by translating customer-facing commitments into internal operational targets. Where an SLA describes what the customer sees, a UC describes the behind-the-scenes dependencies and who must do what to meet the SLA. Without clear UCs, Service Delivery teams may promise SLAs they cannot meet because underlying infrastructure teams lack commitment to necessary support levels.

Where Underpinning Contracts Live in ServiceNow

Underpinning Contracts are configured in the Service Level Management (SLM) module or in the Contracts application, depending on your release and configuration. The UC record holds the target response and resolution times, affected Configuration Items (CIs) in the CMDB, ownership and escalation paths, availability commitments, and associated metrics tracked in Performance Analytics or Reporting.

UCs are linked to parent SLAs, incident records, and services in the service portfolio. They appear in dashboard reporting, allowing teams to monitor whether internal targets are being met. The UC also typically references the supporting contract with third parties (for example, a contract with a cloud provider or a managed service provider that guarantees uptime and response times).

A Worked Example

Consider a retail company with an SLA promising customers one-hour response to payment-processing failures. The Service Desk team owns the SLA but depends on Database Operations and the third-party payment provider to restore service. The UC specifies that Database Operations must respond within 15 minutes to a database incident affecting payments, and the payment provider must commit to a 30-minute response under their own contract. The Service Desk uses these UCs to calculate their realistic delivery of the end-user SLA and to know when to escalate if Database Operations or the provider falls behind. The UC defines escalation paths: if Database Operations does not respond within 15 minutes, the incident escalates to the Database Manager. If the payment provider does not respond within 30 minutes, the incident escalates to the Vendor Management team for real-time vendor escalation.

Common Misunderstandings

A frequent mistake is confusing the UC response time with the SLA response time. The UC is often tighter (shorter) than the SLA because it represents internal efficiency; the SLA includes communication delay and human decision time. Another misunderstanding treats UCs as one-way commitments from IT Operations, rather than mutual agreements. In practice, UCs work best when both sides have input into what is realistic.

Some teams create UCs without linking them to the CIs they affect, rendering them unactionable when an incident occurs. A third error is not updating UCs when services, infrastructure, or third-party relationships change, leaving escalation procedures pointing to obsolete teams or contacts. UCs should be reviewed annually and updated when organizational changes occur.

Related Concepts

UCs are cousins of Operating Level Agreements (OLAs), which are internal commitments between teams within IT. An OLA might specify that the Network team will restore a failed link within 2 hours; a UC builds on that by specifying what Service Delivery can promise to customers given the Network team’s OLA. Service Level Indicators (SLIs) measure whether the target is being met. Operational Level Agreements and Underpinning Contracts together form the backbone of how ServiceNow ITSM enforces accountability across service delivery chains. Contracts module links UCs to legal vendor contracts so the relationship between SLA, UC, and vendor commitments is documented.

Building a UC backwards from the customer commitment

Start from the commitment the customer actually sees, then work out how much of it each internal team can consume. Write down the customer-facing target, the points in the ticket lifecycle where the clock starts and pauses, and the handoffs between teams. A UC built the other way round, from what each team says it can do, tends to add up to a service slower than the SLA promised, and nobody notices until a breach report arrives.

The useful test is whether the internal targets fit inside the external one with room left for a handoff. If one team’s response target plus a supplier’s response target already consumes most of the customer window, the SLA is not realistic as written. The conversation then belongs with the service owner, not with the team that is being measured. The service level management guide sets out how the customer-facing side is defined.

Choosing between an OLA, a UC and a vendor contract

The three records should reference one another. The operational level agreement is the internal layer a UC often depends on. A UC that cites a vendor contract but does not match its response terms is a common inconsistency when teams review these records side by side.

Setting up the record so it can be acted on during an incident

A UC is only useful when an analyst can find it from the affected service in the middle of an incident. Link it to the business service and to the configuration items that deliver it, so a search from the incident shows the commitment without a second lookup. Put the escalation path in the record in plain language, using roles rather than named people, and the contact route the on-call engineer will actually use. Test the record by picking a recent incident and walking through the steps from the incident alone.

1. Confirm the customer-facing SLA and the service it applies to.
2. Agree the start and pause conditions with the teams that will be measured against them.
3. Enter each internal target with the owning team, the measurement point and the escalation role.
4. Link the affected configuration items and the business service, and check that the link appears from an incident on that service.
5. Run a tabletop review with the teams involved, using one realistic breach scenario, and change anything nobody could act on.

Failure modes that make a UC look healthy while it is not

A common problem is a clock that stops in the wrong place. If the internal target pauses while the ticket waits for the customer, but the customer-facing SLA keeps running, the UC reports success while the customer experiences a breach. Reconcile the pause rules on both sides before any report is trusted. The SLA breach prevention article covers the operational side of catching these early.

The second is a target measured on the wrong event. Measuring response from ticket creation, when the team only receives the ticket after an automated routing step, hides the routing delay entirely. Look at the timestamps the routing step writes, not only the ones on the incident.

The third is a contract that has changed while the UC has not. A supplier moves to a different support tier and the UC still promises the earlier response. Tie a review of each UC to any change in the supplier’s terms, so the record moves when the commitment does.

Reporting that shows whether the UC is being met

Show internal targets next to the customer SLA in the same view, so a gap appears as a comparison. A useful pattern is to show, for each breached SLA, which internal target was missed, if any, and whether that miss caused the breach or followed from it. This can separate a supplier problem from an internal scheduling problem and point the service review at the right party.

Questions service managers ask about underpinning contracts

Can a UC exist without a formal contract behind it?

Yes, for internal teams. It becomes a risk when an external supplier is involved and the UC promises a response the supplier’s terms do not cover. Confirm the external part before publishing the UC.

Who should propose the targets?

The team that will be measured should propose them, and the service owner should accept or reject them against the SLA. Targets set only by the owner tend to be ignored by the team that has to meet them.

What do we do when a UC is repeatedly missed?

Treat the miss as information about the target, the team or the SLA. Review whether the target was realistic, whether capacity changed, and whether the SLA still reflects what customers were promised.

Does every service need a UC?

Only services whose customer commitment depends on another team or a supplier to meet it. A self-contained service needs an SLA and a support process, and a UC adds overhead without a dependency to manage.

Next step

If your SLAs and internal targets disagree, reconciling a single service often shows where the gap sits.