Modeling a Product Offering with multiple Product Specifications in ServiceNow TMT/SOM

[VishwamitraM]

Hello Community,

I am working on ServiceNow Sales and SOM (TMT) and trying to model a product offering.

Scenario:
I have a single offering called “Home Bundle Silver”, which includes multiple components:
• Broadband
• Video
• Home Phone

Each of these components has its own characteristics, services, and resources.

Challenge:
While configuring the Product Offering, I can associate only one Product Specification. However, for this bundle, I need to represent multiple product specifications (Broadband, Video, Home Phone) under the same commercial offering.

Because of this, I’m unsure how to correctly model the structure in line with ServiceNow best practices.

Question:
What is the recommended approach in TMT/SOM to model a offering with multiple components?

Any guidance or examples would be appreciated.

Thanks in advance.

[BeingKhan]

Hello,

This is a classic and important modeling question in ServiceNow TMT / SOM, and you are correct to pause here. What you are seeing is not a limitation—it is a deliberate separation of commercial vs. technical modeling in ServiceNow.

Let’s walk through this the right way, aligned with TMT/SOM best practices.

---

First: The Key Concept You Must Internalize

In ServiceNow TMT / Service Order Management, the rule is:

A Product Offering can have only ONE Product Specification — by design.

This is intentional and aligns with TM Forum SID principles.

So your instinct is right:

• ❌ You should NOT try to attach multiple Product Specifications directly to a single Product Offering.

Instead, you model composition.

---

Correct Mental Model (Very Important)

You must separate:

Layer Purpose

Product Offering	What is sold commercially
Product Specification	What is delivered technically
Product Specification Relationships	How components are bundled

---

Recommended Modeling Pattern (Industry Standard)

✅ Use a Composite / Bundle Product Specification

This is the only correct approach for your scenario.

---

Step-by-Step Recommended Structure

1️⃣ Product Offering (Commercial Layer)

Product Offering

• Name: Home Bundle Silver

• Type: Bundle / Composite

• Audience: Customers

➡️ This represents what the customer buys.

---

2️⃣ Bundle Product Specification (Anchor Spec)

Create one Product Specification:

Product Specification

• Name: Home Bundle Silver Spec

• Type: Composite / Bundle

• Purpose: Orchestration container

➡️ This is the single spec linked to the Product Offering.

---

3️⃣ Component Product Specifications (Atomic Specs)

Create separate atomic Product Specifications:

• Broadband Spec

• Video Spec

• Home Phone Spec

Each of these will have:

• Their own Characteristics

• Their own Services

• Their own Resources

➡️ These represent real technical capabilities.

---

4️⃣ Link Components Using Product Specification Relationships

This is the most critical step.

On Home Bundle Silver Spec, create relationships:

Parent Spec Relationship Child Spec

Home Bundle Silver Spec	Bundled / Composed of	Broadband Spec
Home Bundle Silver Spec	Bundled / Composed of	Video Spec
Home Bundle Silver Spec	Bundled / Composed of	Home Phone Spec

This tells SOM:

“This offering is fulfilled by multiple technical products.”

---

How Fulfillment Works (Behind the Scenes)

When an order is placed for Home Bundle Silver:

1. SOM creates one Commercial Order Line

2. Decomposition occurs

3. SOM explodes the bundle spec into:

   • Broadband fulfillment

   • Video fulfillment

   • Home Phone fulfillment

4. Each component:

   • Triggers its own service orders

   • Allocates its own resources

   • Has independent lifecycle states

➡️ Exactly what you want.

---

Where Characteristics Should Live (Important)

Characteristic Type Where It Belongs

Bundle-level (e.g., contract term)	Bundle Product Spec
Broadband speed	Broadband Spec
Video package	Video Spec
Phone number / features	Home Phone Spec

Never overload the bundle spec with component details.

---

Common Mistakes to Avoid ❌

Mistake Why It’s Wrong

Multiple Product Specs on one Offering	Not supported
One giant Product Spec with all characteristics	Breaks decomposition
Modeling components as offerings instead of specs	Breaks fulfillment
Skipping spec relationships	No orchestration

---

Why ServiceNow Enforces This

This design enables:

• Independent fulfillment

• Partial fallouts

• Component-level changes

• Future upsell (e.g., add Video HD later)

• Clean alignment with TMF SID

Trying to “force” multiple specs into an offering will block you later during orchestration and assurance.

---

Final Recommended Architecture (One-View Summary)

Product Offering
  └── Home Bundle Silver
        └── Product Specification
              └── Home Bundle Silver Spec (Composite)
                    ├── Broadband Spec
                    ├── Video Spec
                    └── Home Phone Spec

This is the canonical TMT/SOM bundle model.

---

Strong Practitioner Opinion

If you model bundles correctly now, you will:

• Avoid rework during SOM flows

• Enable clean decomposition

• Support future promotions and add-ons

• Pass architecture reviews effortlessly

This pattern scales from triple-play bundles to complex enterprise offers.

---

[ Please Mark my post as helpful & accept it if you find it valuable ]

[GlideFather]

Hi @BeingKhan,

it's okay to get inspired by AI but the output shall be validated, can you vouch for the content that you are sharing? It seems that it's copy and pasted without any validation... wouldn't it be better to share your own experience rather than this?

[BeingKhan]

Hi @GlideFather 

Happy to vouch for what I shared. The modeling approach described aligns with TMF-aligned TMT/SOM best practices and is something I’ve seen work across real implementations.

If you disagree with a specific point, I’m genuinely open to discussing it — that’s how we all learn.
Questioning intent or authorship, however, doesn’t really move the conversation forward.

______________________________________________________
No AI was used in the writing of this post. Pure #BeingKhan only

[TomSchnarr-IC]

I would recommend creating a product offering for each of your product specs (that are sellable - broadband, video and homephone)  and then do the commercial bundling at the product offer level so , PO:Home Bundle is a bundle of PO:Broadband / PO:Video / PO:HomePhone.  Justification for this - each of the individual products are 'potentially sellable' on their own so they do deserve to be their own PO and the bundle is a commercial bundle (therefore PO-PO as opposed to technical - Voip needing broadband).  One other point - Under video - you may want a PO for the different content packages (but that would be the next level).