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.

[TomSchnarr-IC]

I would encourage the idea that technical constraints, dependencies etc should be modelled at the Prod-Service-Resource Spec level and the commercial definitions at the PO level.  In this case we have three independent products (broadband, video, homephone).  Each of these can be sold independently (although there may be a technical limit that video and homephone require a data connection).  Because each can be (even if they are not) sold indendently they should be modelled as Product Offerings (PO:Broadband/PO:Video/PO:HomePhone).  The bundle of Home Bundle is a commercial decision - the business decides to sell the three products together  - so this should be a PO(bundle), comprising the other POs(Broadband/Video/HomePhone).  You could model PO:HomeBundle-Gold/Silver/Bronze - or allow the chars/options under the bundle to drive the pricing.

[DieterNagel]

We currently work on this matter as well and follow the strategy of Tom and use the base + upgrade bundle approach. We found this in the Implementation Guide as reasoning for the proper user of the decomposition rule:

Decomposition rules function as exclusion rules. They are used to prevent the creation of certain domain orders if the incoming order does not contain a specific characteristic or characteristic option. This allows for optional components in a product or service offering. For example, a rule can be set to only generate a service order for a specific feature if the customer explicitly selected that feature during the ordering process.
Specification relationships and decomposition rules can be defined to exclude domain orders when certain characteristics are not present. For example, if a customer or service order does not include a required characteristic such as Tenancy or WAN Optimization, the related domain order is not generated. 

Summary: The decomposition rules are intended for accessories (e.g. laptop + bag) that are not sold independently. In this case, WAN Optimization or Tenancy acts as the accessory, which can also be optionally dropped from the Domain Order.