ServiceNow Service Offering Explained

Definition and Core Concept

A Service Offering is a distinct, packaged service—such as “Laptop Deployment,” “Network Access Request,” or “Temporary Facilities Access”—that a user can request through the service portal or service catalogue. It represents a solution to a business need, bundled as something a customer can ask for and track through completion.

Service Offerings differ from underlying ITSM request types (incidents, change requests, problems) or from service items in the service portfolio. An offering is a customer-facing request category that may internally generate one or more service requests, tickets, or change records. When a user requests a service offering, the platform can route, approve, and fulfil it automatically or with human intervention.

Where Service Offerings Live in the Platform

Service Offerings are stored in the `svc_service_offering` table in the CMDB. The service catalogue presents offerings to end users; behind the scenes, flow designer or workflows orchestrate what happens when someone requests one. A service offering can trigger ticket creation in incident management, generate a change request in change management, or route to a fulfillment task queue in request fulfilment.

Each offering links to a service (in the service portfolio) and can have mandatory fields, approval rules, and conditions. Some offerings appear only to certain users or user groups based on department, location, or role.

A Worked Example: Laptop Deployment

An employee requests “New Laptop” through the service portal. The service offering is configured to require location, role title, and preferred OS. On submission, the offering triggers a flow designer workflow that checks inventory, creates a purchase order if stock is low, routes to IT procurement for approval, and once approved, creates a fulfillment task in the request fulfilment queue. The employee receives email confirmations at each step and can check the portal for status. Once fulfilled, the workflow generates an incident record linking the new asset to the employee’s active directory account.

Without the service offering abstraction, the employee would submit a generic “IT Request” and describe what they need in free text, leading to manual triage and higher error rates.

Configuring Offering Visibility and Conditions

You can show or hide service offerings based on user department, location, asset ownership, or custom field values. For example, “Manager Approval Workflow” might appear only to users with role “manager” or higher. “Executive Budget Request” appears only to users in the executive group.

Offerings can have conditional fields: if the user selects “New Hire,” the offering displays additional fields for manager name and start date. If they select “existing employee,” those fields disappear. This conditional logic reduces form abandonment and makes the portal feel responsive to user context.

Service Offering vs Request Type vs Service Record

It is easy to conflate these concepts. A catalog item is the customer-facing menu entry, while a service offering describes a service that a customer can choose. A request type (incident, change, request for service, problem) is the internal categorization. A service record represents an ongoing commitment—such as “24/7 Enterprise Support”—that an organisation provides. An offering might be a one-time request (“Add New User”) tied to an underlying service (“Active Directory Management”). You could have multiple offerings under one service if different user groups or departments require different approval workflows for the same underlying service.

Common Mistakes in Service Offering Design

Creating too many offerings makes the catalogue confusing and support costs rise because users choose the wrong offering. Grouping unrelated offerings under one category (such as “All IT Requests”) defeats the purpose of structured routing. Failing to maintain offerings when processes change leaves old workflows active, creating ghost requests that route nowhere. Set up quarterly reviews to retire obsolete offerings and consolidate related ones.

Deciding what deserves to be an offering

A catalog owner is often handed a long list of things people ask for, and the list tends to mix real offerings with questions, complaints and one-off favors. Turning every item on that list into an offering makes the catalog look thorough while making it harder to find anything. The test that works in practice is whether a requester can name the outcome they want without knowing how the organization delivers it. “A laptop for a new starter” passes that test. “Escalate a ticket to the network team” does not, because it describes the internal route rather than something a person is entitled to receive.

A second test is whether the fulfillment has a named owner who will act on each request within a defined expectation. An offering with no fulfillment owner is a form that sends work into a void, and the requesters learn quickly that it does not work.

Where a request belongs if it is not an offering

Many requests that look like offerings are better served by something else. The comparison below shows the common alternatives and the signal that points to each.

The offering-or-not decision is easier to defend when it is written down with its reason. A short note on each rejected candidate stops the same debate from restarting each quarter.

Defining an offering a fulfiller can act on

Offerings often fail at the point where the requester and the fulfiller have different pictures of what was ordered. The steps below narrow that gap before the offering is published.

1. Write the outcome the requester receives, in the requester’s words, and check that it can be confirmed when the work is finished.
2. Name the fulfillment group that will carry out the work, and the person who handles exceptions within that group.
3. List the variables the fulfiller needs. Remove any that the fulfiller can look up from the CMDB or from the requester’s profile, since asking twice is a common source of abandoned requests.
4. Decide the approval route and check that each approver has the information needed to decide from the form alone.
5. Link the offering to the service it belongs to in the service portfolio, so that its cost and its owner appear in the same place as the rest of that service.
6. Set the fulfillment expectation the requester will see, and make sure the team can meet it on a normal week, not only on a quiet one.

The service catalog design guide covers designing requests so that people can recognize the service they need. The service portfolio link in step five is easy to skip. Without it, an offering can keep running after the service it depends on has been retired, and the requests will route to a team that no longer owns the work.

Approvals that slow offerings down without adding control

Approval design is where many offerings become slow. A request that passes through three approvers, each of whom approves almost every item, has added delay without adding control. The useful question for each approval step is what decision the approver actually makes and what information they would need to make it differently. If the honest answer is that they confirm the requester’s manager is correct, that check may be handled by the requester’s profile rather than a human approval.

Conditional approvals work better than blanket ones. An offering can require a second approval only when a cost or risk field crosses a level the business has agreed, rather than asking the same people to approve every standard request. Where the level is set, record who set it and when it was last reviewed, because it will be challenged.

Retiring and consolidating offerings over time

Offerings accumulate, and each one carries a little maintenance cost in its form, its routing and its wording. A reasonable habit is to review the catalog against actual usage periodically, and to look for three patterns: offerings that nobody has requested for a long time, pairs of offerings that differ only by one field, and offerings whose fulfillment group has changed. Retiring an offering should mean hiding it from new requests and keeping the open ones running until they finish, rather than deleting it and leaving requests stranded.

The guide to service portfolio rationalization covers deciding which services to keep across the wider portfolio, which is a better scale for the decision than one offering at a time.

Questions catalog owners ask about offerings

Is a catalog item the same as a service offering?

In day-to-day talk they are often used interchangeably, but they play different roles. The catalog item is what the requester sees and orders. The offering is the commitment behind it, with an owner, a fulfillment route and a service it belongs to. Keep the two linked so that changing one prompts a review of the other.

Should a requester be able to see offerings they are not entitled to order?

Hiding an offering from the portal is a usability choice, not a control. If an offering must not be ordered by a group, enforce that in its eligibility rules, so a direct link cannot bypass the restriction. The catalog request eligibility guidance sets out how to design those rules.

How should an offering be named?

Use the words the requester would use for the outcome, and avoid internal team names or system names in the title. Keep the name stable, since a renamed offering breaks the habits and the search terms people have already learned.

Who should approve a change to an offering?

The service owner should approve changes that alter the outcome or the cost, and the fulfillment lead should approve changes to the steps. Recording both approvals on the change keeps the offering’s history readable.