Make service-offering ownership visible

Service offerings in ServiceNow: Why make ownership the first priority

A service offering can describe what a service promises without making it clear who keeps that information accurate.

That becomes a practical problem when service descriptions, support arrangements, relationships, or responsibilities need updating. Someone needs to understand the offering well enough to confirm what is correct and resolve what is missing.

This article is based on an original DCM Blueprint Live walkthrough presented by Mikko Juola, CPO at Qualdatrix, recorded on 15 October 2026. The demonstration focuses on Business Service Offering data, followed by audience questions about business-unit requirements and shared responsibility.

The central idea is straightforward: establish the people and groups responsible for service offering data before asking them to maintain every other detail.

Business and technology management offerings serve different purposes

The session begins by distinguishing two types of service offering. Both use the Service Offering table, but they describe different parts of the service model.

Technology management service offerings: what IT provides and operates

Technology management service offerings describe the operational services provided to support technology and its consumers.

An offering might distinguish between production and non-production support, with different availability commitments or response times. In the session, Mikko uses these differences to show why a single technology service may need more than one offering.

ServiceNow’s Service Delivery domain documentation explains how technology management offerings can vary by environment, geography, availability, support arrangements, and other service commitments.

Business service offerings: what the business consumes

Business service offerings describe the service choices and commitments available to business consumers.

For example, desktop support might have a standard offering and another offering with a faster response commitment. The distinction is not simply another technical record: it describes a different promise to the people using the service.

ServiceNow’s Service Consumption domain documentation describes how business service offerings define commitments such as availability, scope, and pricing.

In the demonstrated Blueprints, Service classification is used to separate business offerings from technology management offerings. Both still need clear references to the people and groups that own, manage, and support them.

Keep the wider model visible, but prioritise ownership checks

A Business Service Offering Blueprint can contain many requirements: relationships to the parent service, ownership and management references, portfolio and catalog context, descriptions, lifecycle information, and product-model references.

Treating every gap as equally urgent can make that model difficult to put into practice.

In the demonstration, Mikko uses deviation mapping in the Blueprint Designer to make most checks informational, while prioritising selected responsibility-related checks as critical.

The audit still checks the wider model. Missing information remains visible, but informational findings do not reduce the compliance score in this configuration.

This gives teams two useful views at the same time: the ownership gaps they need to address now, and the other data-quality work they may need to tackle later.

For example, the Blueprint can continue checking a description or product-model reference without making those findings an immediate obligation for the person maintaining the offering.

A record can therefore meet the currently enforced baseline while still having informational findings. A high compliance score here does not mean that every aspect of the offering is complete or that every CSDM requirement has been satisfied.

Once responsibilities are established, selected checks can be changed to minor or critical so that the next set of requirements also affects the score.

What the ownership audit reveals

The recorded demonstration uses a dataset of 130 Business Service Offerings. Within that demo dataset, the dashboard shows 36 offerings meeting the current ownership checks and 94 with at least one issue.

These are demonstration results, not customer benchmarks.

Missing support groups are the largest visible problem. Other findings include missing owners and Managed by groups.

The important next question is not just how many records have an issue. It is whether there is someone who can resolve it.

In the example, many offerings already have a manager recorded. That existing reference provides a practical starting point for involving the people who can review and complete the remaining responsibilities.

An individual offering also shows why the severity settings matter. A missing mandatory support group is treated as critical, while other missing details, including description and lifecycle information, remain visible as informational messages.

Instead of giving every finding the same priority, the audit makes the current improvement task explicit.

Separate oversight from the work of fixing individual records

The person responsible for the quality of the service offering dataset is not necessarily the person who should correct every offering.

Mikko distinguishes between the data domain owner, who oversees a class, table, or dataset, and the service managers or other data providers who maintain individual records.

The domain-level dashboard provides an overview of the findings. It can then be filtered by data provider to show which offerings and outstanding issues belong to a particular person.

In the demonstrated configuration, the Managed by user is used as a data provider. This connects the overall quality picture to an identifiable person who can act on the findings.

The service manager then uses the DCM Data Quality Workspace to see the relevant offerings and their audit messages.

During the walkthrough, Mikko opens an offering with a missing support group, uses the remediation action, selects a group, reviews its details, and saves the change. He explains that the record becomes compliant once the remaining required issues are resolved, with the reported compliance score updated on the next audit run.

The purpose is to connect an audit finding to both a responsible person and a practical way to correct the data.

Should business units share one Blueprint?

One audience question asks whether different business units should use a shared Blueprint with a common baseline or separate Blueprints.

Mikko describes two approaches.

Separate Blueprints can make the scope explicit. A business-unit filter ensures that each Blueprint evaluates only the relevant offerings. This can also make sense when responsibilities or reporting requirements differ between units.

A shared Blueprint with conditional links can accommodate requirements that apply only in certain circumstances.

In the demonstration, Mikko shows how a catalog-item relationship could be required for offerings belonging to a particular business unit, such as IT, without making it mandatory for every other unit.

The condition determines whether that relationship is evaluated. The Blueprint can also be labelled to make the conditional requirement clear to the people working with it.

The choice therefore depends on more than whether the records share a table. It also depends on how requirements, responsibilities, and reporting need to be organised.

What happens when the offering owner relies on other teams?

Another audience question raises a common distinction: the offering owner is accountable, but several other teams maintain the underlying data.

That does not mean the offering owner should receive every finding and be expected to correct everything personally.

Mikko explains that separate Blueprints can focus on different parts of the model, with different data providers responsible for each part.

For example, one Blueprint can cover the information maintained by a service offering owner or portfolio owner, while another covers a different part of the model maintained by another team.

The findings and workspace responsibilities can then follow those different areas of work.

Accountability for the offering and responsibility for maintaining every related record do not have to sit with the same person.

The objective is to ensure that people receive findings they understand and can genuinely resolve, rather than passing the entire data-quality problem to whichever owner happens to be listed.

Connect ownership to the wider service model

An ownership-first approach is a starting point, not a reason to leave service relationships undefined.

As the requirements expand, the offering also needs dependable context from its parent service and the Service Instances that support delivery.

For the next layer of that model, the Service Instances in ServiceNow Blueprint Live recording explores how Service Instances connect to Business Applications, underlying infrastructure, and responsible teams.

Further down the model, the Server Relationships in ServiceNow recording looks at infrastructure records that exist in the CMDB but lack sufficient service context.

Together, these topics address different parts of the same challenge: service data needs both meaningful connections and people who can maintain them.

Start with an ownership baseline people can maintain

The first step is not to make every possible field mandatory. It is to agree which ownership and management references are essential for the service offering data you are governing.

Audit that baseline, involve the identified managers and teams, and use the remaining informational findings to understand the next phase of work.

The current Business Service Offerings – CSDM 5 Run Blueprint provides a template to adapt to your organisation’s requirements.

The aim is not simply to populate an owner field. It is to establish a workable responsibility model so that service offering information can be reviewed, corrected, and maintained by the people who understand it.