Two catalogs can use the same word and still describe different businesses.
One may describe what sales can quote. Another may describe what engineering can deliver. A third may exist mostly in contracts, support notes, pricing exceptions, and the experience of people who know which customer promise cannot be broken.
An acquisition may put all of them under one owner. It does not make them one service.
The catalog is more than a list of things to sell
In communications and cloud services, the word catalog gets used for several connected layers. There is the product offering shown to a customer, the service specification used to deliver it, the technical resources underneath it, the support entitlement that keeps it working, and the commercial rules that decide who can buy it and at what price.
TM Forum's current Open API directory treats product catalog, product ordering, service catalog, service inventory, service ordering, resource catalog, qualification, pricing, and customer management as related but distinct capabilities. Its Product Ordering API says an order is based on a product offering defined in a catalog, including pricing, options, and market. That separation matters because the thing a customer buys is not automatically the same thing engineers build or operators support. (https://www.tmforum.org/open-digital-architecture/open-apis) (https://www.tmforum.org/open-digital-architecture/open-apis/product-ordering-management-api-TMF622/v4.0)
If two acquired organizations both sell something called "managed communications," matching the names proves almost nothing. One offer may include carrier coordination, emergency-calling validation, identity integration, device logistics, monitoring, and after-hours support. The other may expect several of those responsibilities to remain with the customer.
Calling them duplicates too early can erase cost, risk, and obligation while leaving the customer-facing name untouched.
Start with the customer promise
I begin with a direct question: what does the customer believe will happen after they sign?
That answer should connect to five layers:
- The offer: what can be quoted, to whom, in which market, and under which commercial terms.
- The service: what functions, performance, support, and lifecycle activities are actually included.
- The delivery method: which onboarding steps, dependencies, tests, approvals, and customer responsibilities make the service real.
- The operating path: who monitors it, supports it, changes it, restores it, and owns an exception.
- The evidence: what proves activation, acceptance, service quality, billing accuracy, security, and renewal value.
TM Forum's catalog-lifecycle model follows a similar separation from the technical view, through the functional view, to the marketing view. It also shows why a technical solution can change without changing what the customer sees, provided that the underlying service promise remains intact. (https://www.tmforum.org/Browsable_HTML_SID_v22.0/html/EARoot/EA2/EA3/EA9/EA1/EA1131.htm)
That is the useful part of standardization. It lets a company improve how it delivers without forcing the customer to relearn the promise every time the platform changes.
Standardize the service, not the customer
I have helped turn complicated cloud communications and contact-center capabilities into a repeatable service. The work was not limited to choosing technology. It connected offer structure, subscription and pricing logic, licensing, onboarding, identity, network readiness, emergency calling, customer responsibilities, support, service assurance, and exception handling.
The practical design question was never simply, "Can this be standardized?"
It was, "Which parts must be standard for the service to be dependable, which parts should be configurable, and which differences require experienced review?"
I use five treatments:
- Standard: repeatable work that should be consistent because consistency improves quality, security, supportability, or economics.
- Configurable: supported choices that belong inside the offer, with known combinations and tested boundaries.
- Governed exception: a justified difference with an owner, price, risk decision, expiration or review date, and support path.
- Bespoke project: work that is valuable but materially outside the repeatable service and needs separate architecture, scope, testing, and acceptance.
- Decline: a request that creates unacceptable security, operational, legal, or customer risk.
This avoids two expensive extremes. One is treating every customer as a blank sheet of paper. The other is pretending every customer has the same environment, obligations, integrations, and tolerance for disruption.
Exceptions are part of the product data
Exceptions often begin as prose in a statement of work, a discount approval, an implementation note, or a support promise made during an escalation. When the exception is not connected back to the service record, the organization loses the ability to see its true cost and risk.
After an acquisition, that problem multiplies. The same exception may have different names in two companies. A feature sold as standard in one catalog may be a custom engineering task in the other. A discount may appear commercially harmless while adding licensing, support, or delivery work that the pricing record does not show.
Business Intelligence should make those relationships visible. I want to see quote-to-activation time, estimate variance, exception volume, rework, support demand, recurring incident type, cost to serve, renewal, adoption, and margin leakage using definitions both sides agree on.
The point is not to punish every exception. Repeated exceptions can be useful evidence. They may reveal a missing supported option, a customer segment the original offer did not understand, or a delivery step that should have been part of the standard service all along.
A catalog decision can also be a security decision
Services carry identities, data flows, administrative access, integrations, supplier dependencies, retention requirements, and recovery expectations. Combining two commercial entries without mapping those relationships can expand access, preserve unsupported components, or remove a control that looked like unnecessary friction.
NIST's Cybersecurity Framework 2.0 implementation examples call for maintaining inventories of supplier-provided services, updating those inventories when new external services are introduced, tracking data provenance and ownership, and managing systems, software, services, and data throughout their lifecycles. NIST also recommends identifying redundant services that unnecessarily increase attack surface and updating inventories when services are moved or transferred. (https://www.nist.gov/document/csf-20-implementations-pdf)
That is why a catalog merger cannot belong only to sales operations or only to engineering. Commercial, delivery, security, support, finance, Customer Experience, and Business Intelligence each see a different part of the same promise.
What leadership should ask to see
A useful combined catalog should answer more than, "Which offer survives?"
It should show:
- Which customer promise each offer carries.
- Which service, resource, supplier, identity, and support dependencies make it work.
- Which prices and discounts are attached to which actual delivery obligations.
- Which differences are supported configuration and which are undocumented customization.
- Which customers are using each variation.
- Who owns every exception and when it must be reviewed.
- What evidence will prove that a migration preserved service, security, billing, and support.
Open APIs can make integration easier, but even TM Forum's Open Digital Architecture guidance cautions that APIs alone do not guarantee plug-and-play interoperability. Shared interfaces do not create shared meaning by themselves. (https://www.tmforum.org/open-digital-architecture/get-started/open-digital-architecture-open-api-manifesto/)
The same is true of catalogs. Putting two lists in one system is data movement. Building one dependable service model requires judgment.
One name should not hide two promises
The combined organization does not need to preserve every inherited offer forever. It also should not erase a valuable promise simply because another catalog contains a similar label.
Start with what the customer was promised. Separate the commercial offer from the service, delivery, support, security, and evidence beneath it. Decide what should be standard, configurable, governed, separate, or declined. Then measure whether the result became easier to sell, safer to deliver, simpler to support, and clearer to the customer.
In Part 2, I will show how I use AI to compare approved catalog records, contracts, delivery evidence, and exception histories without allowing the model to invent equivalence or change a customer commitment.
Read Part 2: How I Use AI to Map Offers, Exceptions, and Customer Commitments (https://www.voipguru.org/insights/how-i-use-ai-to-map-offers-exceptions-and-customer-commitments/)