How I Use AI to Map Offers, Exceptions, and Customer Commitments

Part 1 separated the name of an offer from the customer promise, service design, delivery method, support path, security boundary, and evidence underneath it.

Part 2 is how I use AI to help people do that work faster... without letting the model decide that two services are equivalent because their titles sound alike.

Read Part 1: When Two Service Catalogs Become One (https://www.voipguru.org/insights/when-two-service-catalogs-become-one/)

Begin with one decision

I do not begin by asking AI to merge two catalogs.

I begin with one decision that a person can understand and own. For example:

"Do these two managed communications offers represent the same customer promise, supported variations of one service, or materially different commitments?"

That question is narrow enough to test. It also forces the work to include more than names and descriptions.

Build the approved evidence set

The first job is deciding what the AI is allowed to read. A useful evidence set may include:

• Product and service catalog records.
• Approved pricing, discount, and eligibility rules.
• Contracts, statements of work, amendments, and support entitlements.
• Delivery plans, onboarding checklists, acceptance evidence, and runbooks.
• Licensing, identity, network, carrier, integration, security, and recovery dependencies.
• Support cases, exception records, labor evidence, billing results, adoption, and renewal data.

Access should remain read-only at this stage. Customer identifiers can be removed or tokenized when they are not needed for the decision. Missing access stays visible rather than being quietly treated as proof that a dependency does not exist.

NIST's AI Risk Management Framework says context, intended use, limitations, human oversight, and the business value of an AI system should be defined and documented. It also calls for testing in conditions similar to the real deployment setting and for executive responsibility over AI risk decisions. (https://airc.nist.gov/airmf-resources/airmf/5-sec-core/)

Give every offer the same set of questions

I use AI to build a comparison record, not a conclusion. Each candidate offer gets fields such as:

• Customer promise and eligible customer group.
• Included capabilities and supported options.
• Price structure, billing frequency, discounts, and commercial term.
• Customer, supplier, implementation, and support responsibilities.
• Identity, data, integration, network, and security requirements.
• Service objective, acceptance evidence, recovery path, and lifecycle status.
• Known exceptions, affected customers, owner, cost, risk, and review date.
• Source URL, document, section, effective date, and confidence for every material claim.

TM Forum separates product catalog, ordering, service catalog, inventory, qualification, resource, and customer capabilities in its Open API model. I use that separation as a useful check against flattening a commercial offer, a delivered service, and a technical resource into one misleading record. (https://www.tmforum.org/open-digital-architecture/open-apis)

Prompt 1: find candidates, not duplicates

I start with a prompt shaped like this:

Compare the approved offer records. Group possible matches using customer promise, included service, eligibility, price structure, delivery responsibilities, support entitlement, security requirements, dependencies, and lifecycle status. For every possible match, cite the exact evidence, identify conflicting fields, list missing information, and assign one of these labels: likely match, related but different, subset or bundle, unclear, or no match. Do not call two offers duplicates.

The word "candidate" matters. A model can find similar language quickly. It cannot know which difference carries a contractual promise, a regulatory obligation, or years of operating experience unless the evidence and the right people supply that context.

Prompt 2: make the easy answer defend itself

Next, I challenge the apparent match:

Assume the proposed match is wrong. Identify differences that could change customer experience, implementation effort, licensing, billing, support, security, recovery, or contractual obligation. Separate sourced facts from inference. State what evidence a commercial owner, service architect, security owner, delivery lead, support leader, and finance partner would need before approving a common treatment.

This is not a trick to make the AI sound skeptical. It is a practical defense against the cheapest answer winning before the full cost is visible.

Prompt 3: turn exception prose into evidence

Exceptions often contain the best information and the worst structure. AI can group recurring narratives, but I do not let it erase the source text.

Group approved exception records by the underlying customer need, affected service component, delivery work, security impact, support impact, cost driver, and outcome. Preserve a link to every source record. Highlight exceptions that recur often enough to consider as a supported option. Do not infer approval, profitability, or customer impact when the evidence is missing.

The output helps people distinguish a one-time accommodation from a feature the market keeps asking for. It can also expose a so-called standard offer that depends on repeated manual work.

Build the map after people choose the treatment

The people responsible for the service choose whether each candidate should be standard, configurable, a governed exception, a bespoke project, or declined.

Only then do I use AI to draft the integration map:

Using only the approved treatment decisions, map the target offer, service specification, options, prices, eligibility, implementation steps, support entitlement, dependencies, controls, customer communications, migration cohorts, acceptance evidence, owners, and rollback conditions. Mark every unresolved item. Do not create, retire, reprice, migrate, or communicate anything.

The map should show the transition path for existing customers, not just the future offer for new sales. A clean new catalog does not help the customer whose inherited contract, feature, number, integration, or escalation path disappeared during migration.

Keep the agent inside a real security boundary

Prompt instructions are not access controls. The agent needs a distinct identity, limited sources, read-only tools for discovery, logging, output validation, and human approval before any consequential action.

The Australian Signals Directorate's current guidance describes the agentic harness as the layer that connects a model to context, memory, data, tools, permissions, and action. It recommends least privilege, strong identity, controlled tools and data, validated outputs, human oversight for high-impact actions, continuous monitoring, and controls enforced in the harness rather than relying on model behavior alone. (https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/agentic-ai-harnesses)

In this use case, the agent should not have authority to change pricing, publish an offer, alter an entitlement, update a contract, migrate a customer, or grant access. It prepares evidence and options for experienced people.

Use Business Intelligence to test the result

Before changing the catalog, I establish a baseline. Depending on the service, that may include:

• Quote-to-activation time.
• Estimate variance and rework.
• Exception volume, age, and recurrence.
• First-pass validation and acceptance.
• Support tickets, transfers, repeat explanations, and recurring incident types.
• Cost to serve, discount behavior, billing corrections, and margin leakage.
• Adoption, renewal, expansion, and migration defects.
• Security exceptions, unsupported dependencies, and access problems.

After implementation, Business Intelligence uses the same definitions to determine whether the work reduced friction or merely moved it to another team.

AI can help people query the evidence, explain a change, find an outlier, and connect several systems. People still decide whether a customer promise was preserved and whether the risk is acceptable.

Where I help

This work sits where I have spent much of my career: between product, engineering, sales, delivery, operations, support, Customer Experience, security, and the customer.

I help define the comparison, establish the source and ownership rules, build the service and dependency model, design the prompts and guardrails, bring the right people into the decision, and connect the result to Business Intelligence that leadership can use.

The value is not an AI-generated spreadsheet. It is a service model people can explain, deliver, support, secure, price, and improve... without asking the customer to absorb the confusion created by an acquisition.