Hello Community,
We are currently designing a ServiceNow CSM data model for a payment processing company and would appreciate feedback from those who have implemented similar scenarios in production.
Business Context
- We provide support services for merchants that use POS terminals, mobile payment solutions, QR payments, and related services.
- Our contractual relationship is with financial institutions (banks).
- Each financial institution has many affiliated merchants.
- Merchants contact our support center regarding incidents, requests, onboarding activities, device issues, and service inquiries.
- Merchants are businesses/organizations, not individual consumers.
Current Design Discussion
We are evaluating how merchants should be modeled in ServiceNow CSM.
Option 1
- Financial Institution = Account
- Merchant = Consumer
- Merchant representatives or workers are not registered as ServiceNow users
Option 2
- Financial Institution = Parent Account
- Merchant = Child Account
- Merchant representatives or workers are not registered as ServiceNow users
One of our concerns with Option 1 is related to how merchants would participate in the broader CSM model. We understand that, according to ServiceNow documentation, a Contact is a person who works for an Account. Therefore, merchants themselves should not be modeled as Contacts since they are organizations rather than individuals.
Questions:
- In similar B2B2B or B2B2C implementations, how did you model merchants (customers of your customers)?
- Did you use Consumers, Child Accounts, or another entity?
- Did you encounter limitations around:
- Assets / Installed Products
- Contacts
- Entitlements
- Contracts
- Customer Portal
- Account Relationships
- Workspace experiences
- Looking back, would you make the same design decision again?
Our primary objective is to stay as close as possible to the OOTB CSM model while ensuring long-term scalability and minimizing future customization.
During our analysis, we observed that when a Merchant is configured as a Consumer, ServiceNow OOTB already surfaces Consumer-related information across several customer service experiences. For example:
- Interaction records include both Account and Consumer fields.
- Customer Information tabs display data associated with the Consumer.
- Customer History timelines can be viewed in the context of the Consumer.
- Recent Interactions and Open Cases can be filtered and displayed by Consumer.
- OOTB customer service experiences appear to recognize the Consumer as a first-class entity for case and interaction management.
Based on this, we have additionals questions for the community:
If Merchants are modeled as another entity (for example, Child Accounts or a custom approach), would equivalent functionality remain available OOTB? Are Consumers merely an alternative data model, or are they actually a key entity leveraged by multiple OOTB CSM experiences?
We are trying to understand whether Consumers are merely an alternative data model, or whether they are actually a key entity leveraged by multiple OOTB CSM experiences and customer context capabilities.
Thank you in advance for your insights.
Hi @luishuallpa
Hi,
Based on the business context you described, I would lean toward modelling Merchants as Accounts rather than Consumers.
The main reason is that a Merchant is a business/organization, not an individual B2C customer. In the CSM data model, Consumers are generally more suitable when the supported customer is an individual person. For a merchant support model, especially where merchants have POS terminals, payment products, locations, onboarding activities, support history, installed products, and possible entitlement/contract relationships, the Account model usually gives better long-term scalability.
I would suggest looking at the design like this:
Financial Institution = Account / Contractual Account / Sponsor Account
Merchant = Account, either as a Child Account or a Related Account
Merchant representatives = Contacts, even if they are not portal users initially
POS terminals / payment solutions = Sold Products / Install Base Items linked to the Merchant Account
Contracts / Entitlements = Based on how the support agreement is structured between your company, the bank, and the merchant
One small refinement: I would not automatically use Parent Account / Child Account unless the bank-to-merchant relationship is truly hierarchical from a business and reporting perspective. If the bank does not legally own the merchant, and the merchant is only affiliated/sponsored/acquired through that bank, an Account Relationship model may be cleaner than forcing a strict parent-child hierarchy.
In other words:
If the bank owns or centrally manages the merchant relationship, Parent Account / Child Account may work.
If the merchant is an independent business affiliated with a bank, keep both as Accounts and relate them through an Account Relationship or a defined relationship model.
I would avoid using Consumer for Merchant just because the current workspace screens already show Consumer-related data nicely. Your screenshots are valid, and they show that Consumer is definitely a first-class entity in many OOTB CSM experiences such as interactions, customer history, recent interactions, and open cases. However, that does not necessarily mean it is the right long-term model for an organization like a merchant.
The risk with modelling Merchants as Consumers is that later you may face limitations or awkward design decisions around:
Contacts, because a Consumer is not an organization that can naturally have many business representatives
Account hierarchy and account relationships
Merchant locations or branches
Installed products and POS terminal ownership
Entitlements and support agreements
Customer portal access if merchant users are added later
Reporting by merchant, bank, region, product, or contract
Future onboarding and lifecycle processes
Partner/customer relationship modelling
For production scalability, I would normally model the case context like this:
Case Account = Merchant Account
Contact = Merchant representative, if known
Related/Sponsor/Contractual Account = Financial Institution, using relationship or an additional reference depending on the implementation
Product / Install Base Item = POS terminal, QR payment service, mobile payment solution, etc.
Entitlement = determined based on Merchant, Bank, Product, or Contract rules
This gives agents a clear operational view of the merchant while still preserving the bank relationship for contractual, reporting, and entitlement purposes.
For Contacts, even if merchant representatives are not registered ServiceNow users today, I would still consider creating Contact records for known merchant representatives where possible. They do not necessarily need to be enabled for portal login immediately. But having Contacts gives you better caller history, case history, communication tracking, and future portal readiness.
For Assets / Installed Products, I would usually attach POS terminals and payment products to the Merchant Account because the merchant is the operational owner/user of the device or service. If the bank owns the commercial agreement, that can be handled through contracts, entitlements, or account relationships.
For Entitlements and Contracts, the right design depends on your commercial model:
If the bank has the master agreement, keep the contract at the Financial Institution level.
If support rules differ by merchant, product, or terminal, create entitlement logic that can evaluate the merchant/product context.
If merchants have their own service levels, then merchant-level entitlements may be needed.
My preferred design would be:
Use Accounts for both Financial Institutions and Merchants.
Use Account Relationships or parent-child hierarchy depending on the real business relationship.
Use Contacts for merchant representatives, even if they are not portal users at the start.
Use Install Base / Sold Products for POS terminals and payment services.
Use Contracts and Entitlements based on the actual support agreement structure.
Avoid a custom entity unless the OOTB Account/Relationship model cannot support the requirement.
So my answer would be:
Consumers are not just an alternative display model; they are used by OOTB CSM experiences, especially for B2C-style service. But for your scenario, since Merchants are organizations, I would avoid modelling them as Consumers only to gain OOTB screen behavior. I would prefer an Account-based design and then configure the workspace/related lists/contextual components as needed.
This keeps the design closer to the long-term B2B CSM model and avoids future rework when you expand into portal access, contracts, entitlements, installed products, merchant hierarchy, reporting, or onboarding workflows.
Please mark this as Helpful if it helps.
If this addresses your question, please mark this response as Accepted Solution
or mark has helpful
if you find it helpful.
Thank you!
TejaswiniY
