Every Customer Service Management problem that is expensive to fix is a foundation data problem. Routing, SLAs, portal visibility, reporting, escalation — all of them read from the same small set of records describing who your customers are and what they bought. Get that layer wrong and you will spend years working around it, because by the time the flaw is obvious you have hundreds of thousands of cases pointing at it.
This is the first of a short series on ServiceNow CSM practices. It covers the layer underneath everything else: accounts, hierarchy, contacts, products, and entitlements.
The account hierarchy is not your customer’s org chart
customer_account has a parent field, and that single field creates the hierarchy that CSM uses for visibility, rollup reporting, and contract inheritance. The question everyone gets wrong on the first attempt is what the hierarchy should represent.
It should represent the structure you need to serve and bill. It should not be a faithful reproduction of the customer’s internal org chart, and it should not mirror your own sales territories.
A three-level hierarchy of Global Parent → Regional Entity → Site is usually enough, and each level should earn its place by answering yes to at least one of these:
- Does anything get contracted or entitled at this level?
- Does anyone need to see cases across everything beneath it?
- Do you report on this level in a way that a filter could not give you?
If a level fails all three, it is a field on the account, not a node in the tree. Regions, industries, and segments are almost always fields masquerading as hierarchy levels, and modelling them as nodes is how a clean three-level tree becomes an eight-level one that nobody can query.
Depth has real costs. Hierarchy-aware queries walk the tree, and portal views that show “all cases in my account hierarchy” get slower with every level. More importantly, every extra level is another place for a case to be filed against the wrong node — and a case on the wrong account gets the wrong entitlement, the wrong SLA, and the wrong routing. Shallow hierarchies are not just faster; they are more likely to be correct.
Contacts, consumers, and the B2B/B2C split
CSM models people two ways, and picking the wrong one is a migration, not a configuration change.
Contacts (customer_contact) are people who belong to an account. This is the B2B model: the customer is the company, and the contact acts on its behalf. Consumers (csm_consumer) are individuals who are the customer themselves, with no account above them. That is the B2C model.
Choose based on who holds the entitlement. If the contract, the SLA, and the renewal live with a company, you want contacts and accounts. If they live with the individual, you want consumers. Organisations that genuinely serve both — a manufacturer selling through distributors and directly to the public — will run both models side by side, and that is supported and normal.
Two configuration details are worth knowing early because they change how the portal behaves:
- A contact can be given visibility of child account cases as well as their own account’s. That flag is how you give a global procurement lead one view across every subsidiary without giving every subsidiary a view of each other.
- Partner accounts are a distinct account type with their own visibility rules. A partner managing cases on behalf of your customers is not the same relationship as a customer with a parent company, and squeezing partners into the parent/child hierarchy to avoid learning the partner model is a decision you will regret at the first access review.
Products, install base, and why they matter to routing
The install base — sn_install_base_item — records what a specific customer actually has: which product, which version, at which location, under which contract. It is easy to treat as optional, because CSM will happily let you create cases without it.
Skip it and you lose three things at once. Skill-based routing loses its best input, because “which product is this about” is the most reliable predictor of who should handle a case. Entitlement determination gets weaker, because entitlements are frequently product-scoped. And your case data becomes nearly useless for product feedback, since “cases by product” is the report every product manager asks for within the first month.
The pragmatic path is to populate install base for the products where support actually differs — the ones with distinct expertise, distinct SLAs, or distinct failure modes — and leave the long tail alone until there is a reason. A partial install base that is accurate beats a complete one that is stale.
Entitlements decide SLAs, so treat them as data, not configuration
An entitlement (service_entitlement) answers: is this customer allowed to open this kind of case, through this channel, right now — and what response are they owed? It sits between the account, the contract, and the SLA.
Two rules keep this layer sane.
Let entitlements drive SLAs, not case fields. The tempting shortcut is a priority field on the case that someone sets manually, with SLAs keyed off it. That works right up until a customer argues that their platinum contract was not honoured and you have no systematic answer. Deriving the commitment from the entitlement record makes the answer auditable.
Keep contract terms out of scripts. The moment “gold customers get four-hour response” lives in a business rule, changing a contract requires a developer and a release. As data on the entitlement, it requires an admin and five minutes. The same principle governs the broader question of when logic belongs in the platform versus in code — configuration that changes at the speed of commercial negotiation should never be compiled into anything.
Where account data should actually live
Almost every organisation running CSM also runs a CRM, and both want to own the account record. Resolving that cleanly matters more than any individual field mapping.
Pick one system as the master for each domain. Typically the CRM masters accounts, contacts, and the commercial relationship; ServiceNow masters cases, entitlement consumption, and service history. Then integrate one way per domain, with a real reconciliation story rather than a nightly import that silently overwrites edits.
Bidirectional sync on the same fields is where this goes wrong. Two systems that both believe they own account.name will eventually disagree, and the loser is whichever integration ran last. If you genuinely need edits in both places, split ownership at the field level and enforce it — commercial fields flow in, service fields flow out. This is unglamorous integration and automation work, and it is the difference between a CSM instance people trust and one where agents keep a spreadsheet because “the account data in ServiceNow is wrong.”
Two habits keep the layer healthy once it exists. Deduplicate accounts before go-live, because duplicate accounts split case history, break hierarchy rollups, and are dramatically harder to merge once cases point at both. And deactivate rather than delete: an inactive account keeps its history intact and out of the way, while a deleted one leaves orphaned cases and broken reports.
The test
Before you build anything on top of this layer, check that you can answer these without writing a script:
- Given a case, which entitlement applies and why?
- Given a contact, exactly which cases can they see in the portal?
- Given an account, what is the total case volume across its hierarchy this quarter?
- Given a product, which accounts have it installed?
If any answer requires a developer, the foundation is not finished — and everything you build on top of it will inherit that. Getting this layer right is exactly the kind of work our architecture and modernisation practice does before touching workflow, and it is also why routing configuration so often turns out to be a data problem rather than a queue problem.
Next in this series: case types, escalation, and closure — the lifecycle that sits on top of this foundation. If you are staring at an account model that already has eight levels and nobody remembers why, we should talk.