Embedded AI alone cannot set customer experience apart

Embedded AI makes deployment a weaker signal of customer-experience advantage

AI built into software a business already uses makes customer service easier to automate, but it also makes deployment weaker evidence of competitive advantage. When competitors receive comparable agents through existing subscriptions, access reveals less about strategy or execution. The decisions that matter remain with the business: how fully to use the capability, where it may act, which outcomes it should pursue and what customer history should inform it.

Those decisions once came with a more visible investment process. A strong digital experience usually required an explicit strategy, committed funding and a team that stayed together through implementation. Companies have always bought the same software, but substantial AI functions can now arrive through routine updates without a separate investment decision. Differences in customer experience therefore depend increasingly on how each company uses shared capability.

This shift is visible in availability claims from HubSpot, Optimizely and Shopify, which sell these platforms and benefit when customers adopt their capabilities and renew their subscriptions. HubSpot says Customer Agent’s support-question answering is available to “every Professional and Enterprise subscriber, on any hub.” Optimizely provides “more than 50 out-of-the-box agents” in “every Opal instance.” Shopify says Sidekick can create an automation workflow at a merchant’s request on “every plan from Basic through Plus.”

These broad entitlements fit Gartner’s January 2026 forecast that enterprises would receive AI most often through incumbent software providers during 2026, rather than through new projects. For customer-experience leaders, this changes what a purchase or deployment demonstrates. A capable service experience can begin with a release that competitors also receive, so the more meaningful work lies in deciding how to use it.

Decision 1: Use the capability you already have deliberately

When capability arrives through an existing subscription, the first decision is whether the business will give it a clear purpose. Embedded AI can bypass the meeting where someone would otherwise ask what an investment should accomplish and who should own the result. Deployment may then follow the supplied settings while much of the functionality goes unused. Customers can get adequate service without a reason to remember it.

An adequate experience once could reflect a deliberate decision to contain costs; now, “good enough” can describe what the software delivers automatically. Organizations commonly run embedded AI with its initial settings and use only a fraction of what is available. As capability expands faster than teams learn to apply it, buying access and building useful operating practices become increasingly separate activities.

So a platform review should start by establishing what the business already has and how it uses it. Identify which licensed AI functions are live, which have been configured for a business purpose and which are ignored. Then examine how fully the active functions are used, so the review connects access to a specific difference in customer experience.

The review needs an owner who can act on its findings. Someone must connect each deployment to a purpose, decide which functions deserve attention and assess whether their use serves that purpose. Executive oversight should also establish who owns the later decisions about authority, desired outcomes and customer information. Without clear responsibility, another purchase can look like progress while existing capability remains underused.

Purchasing scrutiny should therefore ask what additional spending changes for customers. An unnamed writer, drawing on personal experience of budget reviews, says spending labeled as differentiation is rarely challenged on whether it merely buys capabilities competitors already have. The practical question is whether the proposed investment creates a useful difference the company could already achieve with tools it owns.

Defaults can scale mistakes, while the company remains accountable

Underusing capability has a cost, but leaving its behavior unexamined can also create risk. As customer journeys divide between human and AI service, choices about acceptable uncertainty, escalation and tone move into software settings. These settings shape what customers hear and rely on, so reviewing them helps explain where service failures begin and how widely they can spread.

Failures spread differently in human service because variation is distributed across individual employees. Representatives differ in knowledge, judgment and warmth, which means customers can receive substantially different experiences from the same organization. Yet an uncertain employee may ask for help, and a manager may correct a poor decision before it reaches more customers. Organizations have long benefited from this ability to contain mistakes.

AI puts more of these choices into instructions applied across the service operation. A confidence threshold, the level of certainty required before an agent answers, can influence many conversations, as can a rule for transferring a customer to a person. If an agent may answer while unsure, one centrally selected rule can make uncertain answering a repeated behavior. The warmth once supplied by an individual representative may similarly depend on a system prompt, the instructions guiding the AI’s behavior.

This concentration of decisions makes W. Edwards Deming’s work relevant to AI service quality. According to the unnamed writer, the American statistician, whose quality methods helped rebuild postwar Japanese manufacturing, spent 40 years teaching about quality, variation and the influence of systems on outcomes. His work directs management toward the conditions that produce behavior, which means shared instructions and settings deserve attention when the same problem appears across interactions.

Shared instructions can carry the same behavior into “millions of interactions at once.” Polished language makes that reach harder to manage because an incorrect answer can sound as credible as a correct one. A flaw may therefore remain hard to notice until enough customers encounter it for the consequences to become expensive.

Because shared instructions reach so many customers, the vendor’s starting configuration becomes a consequential business choice. Vendors set defaults for a broad customer base, while individual businesses have different customers, service promises and tolerances for risk. Deploying those defaults unchanged accepts the vendor’s assumptions about how service should work. The company must decide whether those assumptions fit what it is willing to say and do.

Accepting defaults connects to the argument Richard Thaler, the behavioral economist, and Cass Sunstein make in Nudge. They describe choice architecture, the way choices are presented, as something that inevitably influences decisions and therefore cannot be neutral. In embedded AI, an initial setting likewise reflects an earlier decision about behavior. Leaving it unchanged preserves that decision, even when nobody inside the company explicitly selected it.

The company’s responsibility becomes concrete when a customer relies on an automated answer. After his grandmother died, a passenger asked Air Canada’s chatbot about bereavement fares, and it advised him to book immediately and apply for a reduced rate afterward. He relied on that advice even though it contradicted the airline’s actual policy. A Canadian tribunal held Air Canada responsible for the information its chatbot supplied.

The Air Canada case concerns customer reliance and company accountability; the possibility of repeating an error across many conversations follows separately from centrally controlled software. Another ruling addresses responsibility in Germany: in May 2026, Germany’s Higher Regional Court of Hamm ruled that chatbot statements count as the company’s own. Each ruling applies within its jurisdiction and circumstances, while giving businesses a concrete reason to examine what their automated systems tell customers.

Responsibility also affects risk planning beyond individual disputes. The unnamed writer describes insurance underwriting beginning to treat machine-generated error as an ongoing category of insured loss. This adds a commercial consequence to choices about AI behavior: the settings a company accepts help determine the risk it takes on. Reviewing them belongs alongside the work of improving service.

Decision 2: Set the boundary between AI action and human approval

Because the company remains responsible, it must decide how much authority an agent receives. A refund makes the choice clear: the same agent may prepare it for a person to approve or issue it independently. Its underlying capability can stay the same while the customer experience and the company’s exposure change substantially. Permission determines whether the agent can commit the business to an action.

That permission must become a rule the system can follow. For a refund, the rule must establish whether preparing the action completes the agent’s task or whether it may also execute the refund. A general statement of risk tolerance leaves this decision unresolved. The business must specify which actions the agent may take independently and which require human approval.

Action rules also need a defined response to uncertainty. Before expanding deployment, leaders should review confidence thresholds and escalation rules to establish when human judgment is required and how responsibility transfers at that point. These controls connect the agent’s authority with how it handles difficult interactions. Setting them before expansion makes the intended boundary part of everyday operation.

The boundary affects both service speed and who makes the final commitment. Greater autonomy can let customers complete more tasks without waiting for approval, while retained approval leaves the decision with a person. The legal cases and insurance observation show why the resulting exposure matters. Engineering can implement the controls, but the business must own the authority they grant.

Decision 3: Optimize for why customers choose your business

Authority determines which actions an agent may take; its objective determines which results it pursues. An optimization target is the outcome a system is instructed to improve, for example, conversion, which means completing a desired action such as a purchase. A vendor’s generic target must serve a broad range of customers, so each company needs to decide what that outcome means in its own business before it guides repeated decisions.

Conversion shows why the definition matters. An experimentation agent instructed to increase conversions may favor those that are easiest to produce, even when other conversions matter more to the business. Unless the target distinguishes their value, the system can meet its stated objective while directing effort away from the customers or results the company most wants to serve.

To define that value, start by expressing in one sentence why customers choose the business. People who understand the company’s appeal and the promise customers expect it to keep should then connect that sentence to the agent’s objective. They must specify what counts as success and why that result matters to these customers. Management intent becomes useful to the system only when it shapes the outcome being pursued.

A business-specific objective brings brand promise, culture and voice into operational decisions. These qualities can then influence the choices the system makes during service, instead of remaining statements outside its operation. Competitors may have access to the same controls, but their value depends on the intent they express. Shared software can produce different decisions when companies define their goals precisely.

Decision 4: Give the system customer history competitors cannot buy

A precise objective still needs relevant information to guide each interaction. Customer conversations contain information that a generic model or vendor configuration cannot supply: what this company’s customers have already said and done. Without that history, the next interaction starts with less knowledge than the business has already had an opportunity to acquire. This limits the judgment its staff and agents can exercise.

History can be lost when a call ends or a support ticket closes without retaining what the customer communicated. The immediate workflow is complete, but knowledge gained during the interaction can disappear with it. Reporting may conceal the loss because information never recorded cannot later appear as a missing record. A completed ticket can therefore leave the business with an incomplete understanding of the customer.

Preserving the conversation allows later service to build on it, provided the information remains usable. An agent handling the next call can draw on earlier discussions to understand what has already happened. This requires retaining and structuring customer statements and actions so they can inform later work. Disconnected transcripts still leave work between storing information and using it in a decision.

Some organizations maintain this continuity through what is described as “a single, persistent Thread per customer.” A Thread is a continuing customer-specific record that keeps statements and actions across interactions and makes them available through tools teams already use. Building it requires retaining the information, organizing it into the customer’s record and providing access during subsequent interactions. Each step connects earlier service to the next decision.

The resulting record gives shared AI capability information specific to the business. Another company can buy the same platform, obtain comparable agents and change the same categories of settings, but it cannot purchase or reproduce the history of conversations between this company and its customers. With that history available during a new request, the system can interpret the request in light of what the customer has already communicated.

To make the record useful during service, connect the customer’s history to the business objective at the moment of decision. The history supplies the circumstances, while the objective identifies the outcome the company wants to pursue for that customer. Check that prior knowledge is available when the agent handles a new request and that its use serves that outcome.

Key highlights

• Give existing AI a clear purpose: Platform owners need an inventory of licensed AI functions, their actual use and the customer outcomes they support. Assign an accountable owner before approving more spending.
• Define AI authority: Business owners must specify which actions agents may complete independently, which require approval and when uncertainty triggers escalation. These rules determine service speed and the commitments agents can make on the company’s behalf.
• Set business-specific goals: Customer-experience leaders need to translate why customers choose the business into explicit agent objectives. Define which outcomes matter so optimization rewards results that serve the company’s promise.
• Preserve usable customer history: Service and platform owners need to retain customer statements and actions in a continuing record accessible during later interactions. Connect that history to agent decisions so service builds on knowledge competitors cannot buy.