For the last six years, I’ve had the privilege of implementing Customer Service Management (CSM) for over 20 customers. Each project has brought its own unique challenges, but some lessons have consistently stood out. Like any product that’s relatively new to the market, CSM hasn’t always come with a clear-cut “best practice” playbook. Over time, I’ve developed my own set of best practices—shaped by successes, setbacks, and everything in between. With CSM now the fastest-growing product line in ServiceNow, I’m sharing some of the key insights I’ve gained, hoping they’ll help others navigate their own implementations more effectively.

1. Maintaining Data Quality

Ensuring the data integrity of customers is critical for a successful and scalable Customer Service Management (CSM) implementation. Allowing cases to be created for contacts or consumers without an associated account can lead to poor data quality, security risks, and duplicate records. Requiring account association also mitigates security risks by enforcing authentication and identity validation before case creation.

Key Considerations:

1. 1. Registration Requirement: Contacts or consumers should register through the CSM/CSP portal to establish an account before cases can be created.  Allowing anyone to email in and creating a "shell" consumer/contract record is a fast track to bad data.
   2. Identity Provider Integration: Leverage an identity provider (e.g., Okta, Azure AD) to provision and authenticate accounts securely.
   3. Email Restrictions: Cases should not be created from emails that are not linked to a registered and verified account, ensuring that only authenticated users can interact with the system.
   4. Data Quality Assurance: Validate that all required account and contact fields are completed during the registration process to maintain data integrity.
   5. Security Compliance: Implement controls to ensure compliance with security and privacy standards, such as verifying the identity of users creating cases.
   6. Required Fields: Ensure that First Name, Last Name, Email, and Account (if on contact) are mandatory fields during registration or case creation to maintain data integrity and completeness.

When to use Case Types

Case types should be used when the organization has distinct processes that vary significantly based on different work types, business units, or products, each necessitating unique workflows and UI experiences. If there are significant variations in state models, attributes, or back-end systems across these processes, creating separate case types is essential. This ensures tailored management, improved efficiency, and better access control for each specific process.

Considerations for Case Types

When starting a new implementation, one should evaluate some key questions:

1. Are there different processes based on work types or business units?
2. Are there different processes based on products and services that are being supported?
3. Do the different processes have different state models?
4. Are there a large number of attributes captured for each process that are very different from each other?
5. Is each business unit or team interacting with a different set of back-end systems to resolve the case?
6. Are there different support teams working on different case types, thereby making it
7. necessary to restrict access to cases?
8. Do the agents working on these issues need a different experience and guidance for each issue type?

If the answer to these questions is yes, then it is best to extend the case table to create new case types for each discrete process.[1]

Application Scopes

When creating new case types in ServiceNow, it's considered a best practice to place each case type in its own scope. This practice ensures better organization, modularity, and security of your configurations. By isolating each case type within a separate scope, you can avoid cross-scope access issues, which enhances the maintainability and scalability of your case management system.

Placing a case type in a scope allows you to manage and encapsulate all the related artifacts—such as business rules, client scripts, UI policies, and workflows—within a defined boundary. This modular approach not only helps in organizing the components related to a specific case type but also makes it easier to apply updates, troubleshoot issues, and maintain the system over time. Each scope can have its own set of permissions and access controls, ensuring that only authorized users can modify or access the configurations within that scope.

CSM Case Types Example:

3. Service Level Agreements

Running SLAs Between Case and Incident 

When using Service Level Agreements (SLAs) in an environment where the CSM with ITSM plugin is activated, it is important to clearly define where SLAs should be applied to ensure clarity and accountability.

1. 1. SLAs for Customer Support:
      SLAs for the customer support team should be run on the Case table. These SLAs are designed to track and ensure timely resolution of customer-facing issues, focusing on the commitments made to the customer.
   2. OLAs for Internal Teams:
      If a Case requires the creation of an Incident to address internal issues (e.g., a developer needs to resolve a bug in the codebase), the Incident should have a separate SLA. This SLA governs the internal agreement between teams within the organization and ensures the necessary work is completed to support the customer issue without directly impacting the customer-facing SLA.
   3. Separation of Responsibility:
      • The Case SLA represents the organization's commitment to the customer.
      • The Incident OLA reflects the internal operational agreement, ensuring collaboration and resolution within agreed timeframes.

By maintaining this separation, organizations can effectively manage both external customer expectations and internal team responsibilities, ensuring a seamless and scalable approach to SLA management.

4.     Shared Tables

ServiceNow Customer Service Management (CSM) utilizes several shared tables that are pivotal in managing customer and vendor information. These tables include the Account [customer_account], Consumer [csm_consumer], and Contact [customer_contact] tables. Proper management and configuration of these tables ensure data integrity, appropriate access control, and efficient data display tailored to different stakeholder groups.

Customer Accounts

In ServiceNow Customer Service Management (CSM), the shared Account [customer_account] table is a crucial component for managing customer and vendor information. To ensure data integrity and appropriate access control, it is essential to separate account data based on specific stakeholder groups without relying on access controls or before queries. This guide outlines the best practice for achieving this separation by leveraging the out-of-the-box Vendor Type field and creating new choice values for each stakeholder group.

Leveraging the Vendor Type Field

Step 1: Understanding the Vendor Type Field

The Vendor Type on the Customer table is a choice field designed to categorize accounts. By default, this field includes various vendor types, which can be extended to include new stakeholder groups. This allows for dynamic filtering and display of account data based on the selected vendor type.

Step 2: Creating New Choice Values

To separate data for different stakeholder groups, you need to create new choice values in the Vendor Type field. Each choice value will represent a specific stakeholder group. Follow these steps:

1. Navigate to the Vendor Type field:

• Go to Accounts > Vendor Type -> Configure Dictionary.

2. Add New Choice Values:

• Click on New to create a new choice.
• Enter the Label and Value for each new stakeholder group (e.g., "Retail Customers," "Wholesale Vendors," "Partners").
• Save the new choice values.

Step 3: Updating Existing Records

Ensure that all existing records on Account table are updated to reflect the correct Vendor Type. This may involve:

• Bulk updating records through a fix script.

Dynamically Displaying Account Data

Step 1: Configuring Module Conditions

To dynamically show account data to each stakeholder group, add conditions to the modules that display account records. This can be done by configuring the module's conditions based on the Vendor Type field. Follow these steps:

1. Navigate to the Module:

• Go to the application navigator and locate the module you wish to configure (e.g., Accounts).

2. Add Conditions:

• Click on the module to edit its properties.
• In the Link type, select List of Records.
• In the Condition field, add a condition to filter records based on the Vendor Type (e.g., Vendor Type is "Retail Customers").

3. Save the Module Configuration:

• Save the changes to apply the condition.

Contacts

For the Contact [customer_contact] table, you can leverage dot-walking to dynamically show contacts based on the parent Vendor Type. This allows you to filter contacts by the Vendor Type of their associated account or consumer. Follow these steps:

1. Navigate to the Module:
   • Go to the application navigator and locate the Contacts module you wish to configure.
2. Add Dot-Walk Conditions:
   • Click on the module to edit its properties.
   • In the Link type, select List of Records.
   • In the Condition field, add a dot-walk condition to filter contacts based on the parent Vendor Type (e.g., Account.Vendor Type is "Retail Customers" or Consumer.Vendor Type is "Wholesale Vendors").

Shared CSM Data Model Example: 

5.     Authentication 

Avoid Local Authentication, Leverage SSO

Leverage Single Sign-On (SSO): Single Sign-On (SSO) authentication should always be utilized for consumers and contacts to streamline and secure the authentication process. SSO enables users to log in with a single set of credentials across multiple platforms, enhancing security by enforcing centralized password policies and reducing the risk of password-related breaches. For consumers and contacts, this also means a smoother and more efficient login experience, reducing friction and improving satisfaction.

Avoid Local Authentication: In the context of Customer Service Management (CSM), it's best practice to avoid using local authentication for consumers and contacts due to security risks and management complexities. Local authentication can result in inconsistent password policies, higher chances of unauthorized access, and increased administrative overhead in managing user credentials.

Provisioning Best Practices: Implement automated user provisioning through SSO to ensure that consumer and contact accounts are consistently and securely managed. This includes automatic creation, updating, and deactivation of user accounts based on their status in the identity provider. Automated provisioning reduces the risk of orphaned accounts, ensures compliance with access policies, and simplifies user account management, particularly for large and dynamic consumer bases.