In The Big Picture, we saw that every step of Sales CRM — quote, order, fulfilment and inventory — reads from one product catalog. This article opens that catalog up.
If you get one thing right in a Sales CRM or SOMT implementation, make it the PSR model (Product, Service, Resource). It decides what sellers can sell, what the configurator can configure, and whether an order decomposes cleanly into fulfilment work or falls out halfway.
New to the series? Start with Sales CRM Decoded: The Big Picture.
Why a layered catalog?
Telecom and technology providers have traditionally run two catalogs: a commercial catalog in the CRM or CPQ tool, and a technical catalog in the OSS. Someone kept them in sync by hand. When they drifted apart, sales sold products that operations could not build, and orders fell out.
ServiceNow’s answer is a single PSR catalog, based on the TM Forum SID model, that defines products, services and resources in one place. Because sales and fulfilment read the same definitions, there is nothing to synchronize. The same model covers B2C mobile and wireline, B2B enterprise connectivity and beyond-connectivity services.
The core idea: separate what you sell from how you deliver it. Marketing can launch a new plan without touching the network, and the network team can swap a technology underneath without the customer’s product changing.
The four levels at glance
ServiceNow’s documentation describes four catalog levels. The service level has two types, customer-facing and resource-facing, which gives five building blocks in total.
The PSR layers, with an illustrative home fibre broadband product. Example values are adapted from the ServiceNow PSR catalog documentation.
Each level explained
Each level answers a different question and is usually owned by a different team. Keeping those questions apart is what makes the catalog easy to change later.
Level | Answers | Holds | Example | Typical owner |
Product Offering | What do we sell, at what price, to whom? | Pricing (recurring and one-time charges, ramp-up, mark-up/down, discounts), eligibility, catalog and category, distribution channels | Home Fibre 500 | Product or marketing manager |
Product Specification | What is the product? | Characteristics and options; atomic or composite (a bundle of child specs); relationships to services and resources | Fibre Broadband: bandwidth, static IP, managed router | Product catalog manager |
Customer-facing service spec (CFSS) | What service does the customer experience? | Technology-neutral service parameters, SLAs, features, customer-configurable options | Internet Access: 500 Mbps, 99.9% uptime | Service architect |
Resource-facing service spec (RFSS) | How does the network deliver it? | The technical service: protocols, activation parameters, resource interactions | Access Bearer (GPON), IP Addressing | Network or OSS architect |
Resource Specification | What does it run on? | A template for a physical or logical resource (device, port, IP block, SIM, VNF); the basis for resource inventory | ONT XYZ-GPON-1GE | Network or inventory team |
Typical owners are a common pattern from implementations, not a ServiceNow requirement.
CFSS vs RFSS: the line most teams blur
The service level is where most catalog designs go wrong. A simple test helps: if replacing copper with fibre forces you to change a CFSS, that CFSS is too technical.
| Customer-facing (CFSS) | Resource-facing (RFSS) |
Point of view | The customer | The network |
Technology | Neutral | Specific |
Examples from the docs | Voice and Text; FTTH Access; Internet Access | Home Subscriber Server (HSS); Optical Line Terminal (OLT); Access Bearer |
Changes when… | The service promise changes | The delivery technology changes |
Links to | The product specification above it | The resource specifications it requires |
One boundary worth knowing: Sales CRM for Telecommunications does not itself design, assign or provision resources. The data model lets you define and maintain RFSS and resource specifications, while the actual activation is handed to your fulfilment and OSS systems through orchestration.
The relationships that glue the levels together
Levels on their own are just definitions. Specification relationships connect them, and each relationship type behaves differently when an order is decomposed:
Relationship | What it does at decomposition |
Bundles | Creates a child product order for each bundled item |
Realized as | Creates the target product, service or resource order |
Requires | Creates the target order; can be tied to a characteristic so it is created only when that option is ordered |
Composed of | Describes structure only — it does not trigger decomposition |
Three more tools refine the picture:
- Decomposition rules are optional. ServiceNow suggests thinking of them as exclusion rules: for example, skip the SD-WAN controller service order when the Tenancy option is not selected.
- Quantity mapping controls how many child orders are created. Ordering three SD-WAN packages creates three parent product orders, each fulfilled and inventoried separately.
- Staggered decomposition defers some service orders until a fulfilment agent supplies missing characteristic values, without complex workflow logic.
Watching one order decompose
Here is what the model buys you at run time. In ServiceNow’s Managed Firewall example, a customer-facing service specification has Requires relationships to three resource-facing services. One approved order line becomes seven fulfilment orders, with no manual hand-off.
Decomposition of a single Managed Firewall order line, based on the ServiceNow order decomposition examples.
Fulfilment workflows are then chosen by decision tables using attributes such as the specification category and the line action (Add, Change or Delete). Attributes captured on the quote flow through to the order tasks, so southbound APIs receive the right data.
Design tips from the field
These are the habits that keep a PSR catalog healthy as it grows:
- Model bottom-up, sell top-down. Create and publish resource, service and product specifications before you build offerings. A specification must be published before an offering can use it, and once published it is locked — changes need a new version.
- Keep CFSS technology-neutral. Put technology in the RFSS and resource layers, so a network change never ripples up to what sales sees.
- Choose relationship types on purpose. Composed of does not decompose. When a service order is missing, a wrong relationship type is the first thing to check.
- Treat characteristics as fulfilment data. Mark characteristics mandatory when fulfilment needs them, and check that they carry through to the offering and down to the specs that use them.
- Use decomposition rules as exclusions, not as a second model. If you need many rules to make a hierarchy work, the hierarchy itself probably needs fixing.
- Check the hierarchy before you publish. In CRM Workspace, open Offerings > Product Offerings, select an offering and use the Catalog Hierarchy tab with the Show specification toggle to see the full tree.
- Plan for versions. Retired specification versions cannot be used in offerings or to create new versions, so agree on a versioning approach before the first change request arrives.
For practical setup pitfalls on the original Order Management catalog, see my earlier article Product catalog data model for Order Management.
Key takeaways
- The PSR catalog is one catalog for sales and fulfilment, based on TM Forum SID.
- Offerings say what you sell, product specifications say what it is, service specifications say how it is delivered, and resource specifications say what it runs on.
- Keep the CFSS customer-facing and technology-neutral; put technology in the RFSS and resources.
- Relationship types and decomposition rules decide which fulfilment orders are created, so design them as carefully as the specifications.
Thank you
Thank you for reading. I hope this makes the PSR model feel less like theory and more like a tool you can use on your next design.
If you found it useful, please mark it helpful, share it, and follow me on LinkedIn. I would love to hear how you model your catalog — share your questions and experiences in the comments.
References
- Sales CRM for Telecommunications PSR catalog (Australia release)
- Setting up specifications and product offerings
- Order decomposition examples
- Product catalog hierarchy visualization
- Create and publish product specifications
- Create and publish service specifications
- Create and publish resource specifications
- Retiring or archiving versioned specifications and product offerings
