Sales and Order Mangement (SOM) servicenow
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
What is SOM?
ServiceNow Sales & Order Management and its telecommunications-specific extension, represent a powerful, end-to-end platform designed to streamline the entire Lead-to-Cash lifecycle. By unifying product catalog management, Configure-Price-Quote (CPQ), order capture, orchestration, and fulfillment, ServiceNow eliminates traditional silos between sales, IT, and operations, offering significant business value, especially for Communication Service Providers (CSPs).
1. Foundations of ServiceNow SOM/SOMT
ServiceNow SOM is an integrated platform built on Customer Service Management (CSM) that manages the complete Lead-to-Cash process.
SOM Application Modules:
Key modules include Product Catalog Management, Pricing Management, Lead Management, Opportunity Management, Quote Management (CPQ), Order Management, Customer Lifecycle (MACD), Customer Contracts, Order Operations Cases, and the Business Portal. SOMT specifically adds advanced telecoms decomposition and TM Forum APIs.
Architecture Layers:
The SOM architecture is layered, with customer-facing elements at the top and the ServiceNow Platform (CSM, ITSM, CMDB, Asset Management) at the bottom. Critical to its deployment is the prior installation of CSM, as all SOM plugins depend on it.
It is MANDATORY to install the Customer Service Management (CSM) plugin (com.sn_customerservice) first. All SOM plugins are dependent on CSM, and their installation will fail without it.
No | Plugin ID | Name | Type |
1 | sn_ga_exp | Guided Decisions Experience | Core UX |
2 | sn_prd_pm | Product Catalog Management | Core Data Model |
3 | sn_csm_pricing | Price Management | Pricing |
4 | sn_ind_tmt_orm | Order Management Core | OM |
5 | sn_l2c_core | Lead to Cash Core | L2C Core |
6 | sn_opty_mgmt_core | Opportunity Management Data Model | Data Model |
7 | sn_opty_mgmt | Opportunity Management Application | Application |
8 | sn_quote_mgmt_core | Quote Management Data Model | Data Model |
9 | sn_quote_mgmt | Quote Management Application | Application |
10 | sn_l2c_lead_mgmt_data_model | Lead Management Data Model | Data Model |
11 | sn_lead_mgmt | Lead Management Application | Application |
12 | sn_prd_config_ui | Product Configurator UI | UI |
13 | sn_l2c_cust_flows | Customer Life Cycle Mgmt Workflows | MACD |
14 | sn_csm_price_mtrx | Pricing Matrix Management | Pricing |
15 | sn_sales_agmt_core | Sales Agreement Data Model | Data Model |
16 | com.sn_sales_agmt_wf | Sales Agreement Management | Application |
17 | sn_pss_core | Customer Contracts and Entitlements | Contracts |
18 | sn_contract_ent_wf | Contracts and Entitlements Workflows | Workflows |
19 | sn_ent_verify | Entitlements Verification | Entitlements |
20 | com.sn_som_clm | Contract Management for SOM | Contracts |
2. 1 The Lead-to-Cash Lifecycle
The Lead-to-Cash lifecycle within ServiceNow SOM/SOMT is a meticulously managed journey, from initial customer engagement to the successful completion of service delivery and subsequent post-sale activities. This process is characterized by distinct stages designed to ensure efficiency, transparency, and effective management.
Stage What Happens Record Created Who Act Completion Signal
| 1. Lead | Prospect shows interest in product/service | Lead record in CSM Workspace | Lead Agent, Sales Agent | Lead is qualified or converted |
| 2. Opportunity | Qualified lead becomes a sales opportunity | Opportunity record | Sales Agent, Sales Manager | Quote process is initiated |
| 3. Quote (CPQ) | Products are configured and priced | Quote + Quote Line Items | Sales Agent | Quote accepted → Order created |
| 4. Order Capture | Customer request is confirmed for fulfillment | Customer Order (ORD - Draft) | Order Creator, Agent | Order submitted |
| 5. Enrichment | Data validation and order verification | Auto-generated Enrichment Tasks | Order Fulfillment Agent | All tasks closed and acknowledged |
| 6. Decomposition | Order split into product/service/resource structure | Product Orders, Service Orders, Resource Orders | System (Catalog-driven) | Tasks created for each order component |
| 7. Orchestration | Task sequencing and SLA tracking begins | Order Tasks with dependencies | System + Agents | Tasks executed in defined order |
| 8. Fulfillment | Service provisioning and delivery happens | Updated Fulfillment Tasks | Fulfillment Agent, APIs, FSM | All tasks marked Closed Complete |
| 9. Completion | Service is fully delivered and billing starts | Installed Base record | System | Order marked Completed; invoice generated |
| 10. MACD | Post-sales changes (Move, Add, Change, Disconnect) | Change / Revision / Disconnect Orders | Agent, Customer (Portal) | Installed Base updated |
2.2 Order State Machine
Orders transition through various states, each triggered by specific actions or system events. This state machine ensures a structured and trackable progression of every order
State Description Triggered By
| Draft | Initial state where an order is being created | Agent fills order form or customer starts order in portal |
| Submitted | Order is sent for backend validation and processing | Agent clicks Submit |
| Enrichment in Progress | Validation and verification tasks are executed | Auto-triggered on submission |
| Acknowledged | All enrichment tasks are completed successfully | All enrichment tasks closed complete |
| In Progress | Fulfillment activities are actively being executed | Fulfillment team starts working on tasks |
| Completed | All tasks are finished and service is delivered | All fulfillment tasks closed complete |
| On Hold | Order is paused due to dependencies or approvals | KYC pending, manager approval, or customer dependency |
| Rejected | Order is stopped due to validation or business rule failure | Admin or system validation rejects order |
| Cancelled | Order is terminated before completion | Customer or agent cancels the order |
3. Product Catalog Design: The 4-Layer Hierarchy
An effective product catalog design is fundamental to the successful implementation of ServiceNow SOM/SOMT. ServiceNow advocates for a bottom-up approach to catalog modeling, which ensures that all technical dependencies are meticulously defined and structured before any commercial bundles are created. This methodology significantly reduces complexity and potential rework.
| OFFER (Top) | Product Offering (PO) | A marketable bundle of products and services sold to customers | Unlimited Mobile Bundle, Mega Cloud Storage 1TB | Published — visible to agents/portal |
| PRODUCT | Product Specification (PS) | The primary sellable item included within an offer | Mobile Plan, Cloud Storage, Router | Active |
| SERVICE | Customer-Facing Service (CFS) | A capability or service delivered directly to the customer | Online Access, Voice Service, 4G Data | Active |
| RESOURCE (Bottom) | Resource Specification (RS / RFS) | Underlying technical asset that enables the service | Storage Account, SIM Card, IP Address, MSISDN | Active |
4. Order Decomposition & Orchestration
Upon an order reaching the 'Acknowledged' state, ServiceNow SOM's decomposition engine automatically processes it. This engine, driven by predefined rule sets within the Product Catalog, breaks down the Customer Order into a hierarchical tree of sub-orders and associated tasks. This catalog-driven intelligence is a core strength of SOM, enabling precise and automated fulfillment.
4.1 The Decomposition Hierarchy
The order decomposition process creates a structured hierarchy, ensuring that every component of a customer's request is accurately translated into actionable items. This hierarchy is crucial for managing complex service delivery.
Level Component Type Description Role Output Created
| 1 | Customer Order (CO) | The original order placed by the customer | Entry point for decomposition process | Parent Order Record |
| 2 | Product Order (PO) | Logical breakdown of products within the customer order | Splits order by product offering | Product Order Records |
| 3 | Service Order (SO) | Represents customer-facing services derived from product orders | Defines service-level fulfillment scope | Service Order Records |
| 4 | Resource Order (RO) | Technical implementation level orders for backend systems | Drives actual provisioning actions | Resource Order Records |
| 5 | Task Level (Fulfillment Tasks) | Atomic execution tasks assigned to teams/systems | Executes actual work for delivery | Work Tasks (Manual/System/API) |
4.2 Setting Up Decomposition Rules
Decomposition rules are configured within the Product Catalog to define how products and services break down into their constituent parts. This involves mapping product specifications to product orders, service specifications to service orders, and resource specifications to resource orders, along with any characteristic mappings.
4.3 Order Orchestration and Timeline Views
ServiceNow provides visual tools like the Order Orchestration tab and Timeline view (Gantt chart) to monitor the progress of decomposed orders. These views display the hierarchy of orders and tasks, their dependencies, current statuses (Pending, In Progress, Complete, Error), SLA timers, and jeopardy indicators, offering real-time insights into fulfillment progress.
5. Fulfillment Execution
Fulfillment is the stage where the actual provisioning and delivery of services occur, driven by the tasks generated during decomposition. These tasks can vary significantly in nature and execution method.
5.1 Fulfillment Types
Type When Used Example
| Deliver | Provisioning a new product or service for the first time | New SIM activation, new cloud account creation |
| Change | Modifying an existing active service | Upgrade from 1GB to 5GB data plan |
| Disconnect | Terminating or removing an active service | Cancelling an internet connection or service |
5.2 Task States
Fulfillment tasks progress through their own set of states, reflecting their current status and guiding agent actions
State Meaning Agent Action
| Pending | Task created but not yet started | Wait or pick up task |
| Open | Task is assigned and ready to work | Start execution |
| Work In Progress | Task is actively being worked on | Continue execution |
| On Hold | Task is blocked due to dependency | Resolve blocker or wait |
| Awaiting Info | Requires input from customer or another team | Chase required information |
| Failed / Error | Execution failed, fallout created | Investigate issue / fallout record |
| Closed Complete | Task successfully completed | Confirm completion and close |
5.3 Types of Fulfillment Tasks
Category Examples Automation
| Automated (API) | AWS S3 provisioning, Azure VM creation, SIM activation via network API | Yes — via REST / IntegrationHub / Flow Designer |
| Manual (Agent) | Customer calls, hardware shipping, field visits | No — completed manually by agent |
| System Actions | Inventory updates, billing triggers, email notifications | Yes — system-driven automation |
| Field Service | Engineer visit, CPE installation, cable testing | Partial — handled via FSM integration |
6. MACD (Move, Add, Change, Disconnect) Lifecycle
The MACD lifecycle manages post-sale changes to existing services, allowing for dynamic adjustments to customer subscriptions. ServiceNow's intelligent handling of MACD requests often focuses on processing only the 'delta' of the change, optimizing efficiency and resource utilization.
MACD Type When Used ServiceNow Order Setup Key Difference
| Move | Relocating a service to a new address | Change order with updated address details | Same product, only service location changes |
| Add | Adding a new product or service to an existing account | New product order on existing account | New order line item added to existing account |
| Change | Modifying configuration of an existing service | Service order with change fulfillment type | Updates existing order line item (OLI) |
| Disconnect | Terminating an active service | Product/Service order with disconnect action | Ends all related sub-orders and services |
| Suspend | Temporarily pausing a service | Case-based workflow (no full order) | Service paused without full order processing |
| Resume | Re-activating a suspended service | Reinstatement order | Restores previously suspended service |
| Renew | Extending contract or subscription period | Contract renewal workflow | Extends contract term, may update pricing |
| Upgrade | Moving to higher service tier | Change order with new characteristics | Increases service level (delta pricing applies) |
| Downgrade | Moving to lower service tier | Change order with updated characteristics | Reduces service level (possible credit adjustment) |
7. Order Fallout & Jeopardy Management
Effective management of order fallout and jeopardy is crucial for maintaining service quality and meeting SLAs. ServiceNow SOM provides mechanisms to detect, investigate, and resolve issues that arise during the order fulfillment process.
7.1 Order Fallout Recovery
Order fallout occurs when a fulfillment task fails, often due to data errors or external system issues. ServiceNow automates the detection and initial handling of these failures
Example: Cloud Storage Provisioning Fallout
If an automated task to provision an S3 bucket fails (e.g., due to an invalid region), ServiceNow automatically marks the task as 'Error' and creates an Order Fallout record. The Order Fallout Manager is notified, and an agent investigates the root cause (e.g., an incorrect characteristic value). After correcting the data, the agent retries the task, and if successful, the fallout record is automatically closed, allowing the order to proceed.
7.2 Order Jeopardy & Inflight Changes
Order jeopardy refers to situations where an order is at risk of breaching its Service Level Agreement (SLA). ServiceNow proactively monitors for such risks and provides tools for intervention. Additionally, the platform supports inflight changes to orders, provided certain conditions are met.
Example: SLA Breach and Remediation
If an SLA monitor detects that a fulfillment task (e.g.,
a field engineer visit) is overdue, an Order Jeopardy record is created, and the manager is alerted. The manager investigates the root cause (e.g., engineer unavailability), takes remedial action (e.g., reassigns the task), and updates the timeline. Once the task is completed, the jeopardy record is closed.
Conclusion
ServiceNow SOM/SOMT provides a robust framework for managing complex sales and order processes across various industries, with a particular strength in telecommunications. By understanding its foundational architecture, navigating the intricate lifecycle stages, and adhering to established best practices, organizations can significantly enhance operational efficiency, reduce costs, and elevate customer satisfaction. The comprehensive guidance within the provided document serves as an invaluable resource for successful implementation and continuous optimization of these powerful platforms.
If you found this article useful, please mark it as Helpful. It helps others find the content more easily 👍👍