TLDR
- The scarce resource is no longer interaction supply; it is the ability to preserve truth, legitimate attention and honoured commitments across a journey.
- Treat every material statement as a customer promise transition and bind it to current evidence, permitted authority, an executable action and a receipt.
- Compose language only after its facts, calculations, policy interpretations, options, promises and actions pass claim-level gates.
- Transfer when generation cannot carry the evidence, judgement, accessibility, relationship or institutional accountability required for resolution.
- Measure full-journey resolution, effort, repeats, broken promises, complaints, segment outcomes and redress, never containment alone.
The perfect apology and the impossible refund
A customer disputes a duplicate charge. The service responds in seconds, names the frustration, apologises warmly and promises that the money will be returned by Friday. The exchange reads beautifully. The refund system has no request. The service principal lacks authority to issue one. On Friday the customer starts again by telephone, where an employee cannot see the promise.
Generation makes this failure cheap to reproduce. Text, voice, images and personalised replies can be supplied at almost no marginal effort. Yet the organisation's scarce resources remain stubbornly physical and institutional: current account state, lawful permission, specialist attention, decision authority, capacity to act, and a repair path when an apparent promise diverges from reality. Fluent language can disguise the scarcity rather than remove it.
The design unit is the customer promise transition. This is any claim, offer or action that changes what a customer can reasonably expect from the organisation. A balance explanation may carry little new commitment if it reflects an authenticated ledger. A refund deadline, eligibility statement or assurance that an action is complete carries much more. The latter must be bound to an authoritative source, an actor permitted to commit, an executable operation and a receipt that follows the journey.
This is not a chatbot-design problem. A journey can begin in search, continue through messaging, pass to a contact centre and complete in a back-office case. The Generated Interaction Operating System spans that route. It identifies the customer and unresolved objective; constrains data and claims; separates truth from inference; protects consent and channel choice; gates promises; composes language; transfers evidence; chooses the resolution capability; records commitments; monitors outcomes; and repairs common defects.
Put the contract before the composer
The Interaction Contract declares what one class of interaction may do before a model sees the request. It names the customer goal and organisational purpose, eligible journeys, authentication required by claim, permitted data, authoritative sources, maximum freshness, allowed recommendations, available remedies, disclosure, accessibility routes, customer correction and transfer conditions. Tone belongs in the contract, but tone is not authority to simulate understanding or a relationship the service cannot support.
Paper 071 used an interaction contract as one of six conditions for product-market fit. Paper 161 develops a service-specific contract for promise-bearing touchpoints. It must survive channel transfer and connect claims to fulfilment. Papers on entitlements and data exfiltration govern what information may be retrieved or released. Here, the additional question is what a customer may reasonably rely upon after receiving that information.
| Contract dimension | Purpose and claim boundary | Data | Authority | Customer right | Failure route |
|---|---|---|---|---|---|
| Account explanation | Explain current authenticated state; do not infer an unrelated product need. | Current account fields and public product terms only. | Information authority, no mutation. | Correct inaccurate data and request a person. | Hold on conflict; transfer unresolved discrepancy. |
| Pending transaction | Separate verified status, possible causes and evidence-producing next step. | Transaction event, clearing status and permitted history. | No promise of settlement time without a valid service commitment. | Dispute, complain and receive accessible alternatives. | Specialist route if consequence window may expire. |
| Service remedy | Offer only remedies available for this case and principal. | Failure evidence, cumulative remedies and customer choice. | Deterministic amount, conditions, expiry and delegated limit. | Decline, seek review or use statutory and policy rights. | Deny unsupported offer; obtain accountable approval. |
| Vulnerable support | Resolve the stated need without using distress for persuasion. | Minimum support context with protected retention. | Specialist owns judgement and non-routine commitment. | Human access, privacy, accessible channel and safe challenge. | Urgent protected transfer with receiving acceptance. |
| Commercial recommendation | Keep service purpose separate from promotion and disclose material alternatives. | Use preference data only under an applicable purpose and permission. | Price and eligibility from authoritative services. | Choice, opt-out, explanation and complaint. | Stop on hidden purpose shift or unsupported scarcity claim. |
Break fluent answers into claims before they reach the customer
A generated paragraph can hide one dangerous sentence among nine correct ones. The Interaction Claim Graph decomposes the response into customer-supplied facts, observed journey events, authoritative account facts, retrieved information, calculations, policy interpretations, model inferences, options, reserved judgements, offers, promises, actions and fulfilment. Each node receives a source, freshness, verifier, permitted wording, authority, consequence and failure route.
The composer works only from approved nodes. It may join a verified balance, a deterministic interest calculation and a current policy condition into plain language. It must label a model inference as uncertain and cannot convert a possible cause into account state. An explanation is not evidence. A customer correction changes the state resolver or opens a dispute; it is not merely added to the transcript and forgotten.
| Claim type | Source | Freshness | Verifier | Permitted language | Consequence |
|---|---|---|---|---|---|
| Customer-stated fact | Current utterance or confirmed earlier statement. | Ask whether it still applies where time matters. | Customer; external proof only when needed. | “You told us...” rather than “our records show”. | Misattribution can corrupt the journey state. |
| Account or transaction fact | Authoritative system and record identifier. | Live read or declared observation time. | System receipt plus identity level. | State fact, timestamp and relevant limitation. | False state can misdirect money or rights. |
| Calculation | Versioned inputs and deterministic rule. | Valid while inputs and rule remain current. | Recomputation. | Amount, basis, conditions and rounding. | Error can create a false price or remedy. |
| Policy interpretation | Current policy clause and case facts. | Effective date and jurisdiction. | Policy engine or authorised role. | Conditioned conclusion, exclusions and review route. | May alter eligibility or available options. |
| Model inference | Named model, inputs and evidence scope. | Evaluation version and present context. | Independent evidence or reserved judgement. | Possible, estimated or recommended, never customer fact. | Overstatement can manufacture intent or certainty. |
| Offer or promise | Product, inventory, remedy and authority services. | Reserved at time of statement with expiry. | Promise and Authority Gate. | Exact amount, owner, deadline, conditions and next step. | Changes reasonable customer expectation. |
| Completed action | Authoritative mutation receipt. | Final or explicitly pending state. | System of record, not model narration. | “Completed” only after receipt; otherwise “requested”. | False completion can delay challenge and recovery. |
The Promise and Authority Gate recognises when proposed language changes expectation. It locates current state, confirms identity and purpose, separates information from recommendation and commitment, verifies the principal's authority, validates amount and deadline, reserves judgement, forbids premature completion, records the promise and later compares it with reality. Identity, consent, price, eligibility, remedy, irreversible action and protected rights are hard gates.
| Promise transition | Required evidence | Decision right | Receipt | Fulfilment test | Hard stop |
|---|---|---|---|---|---|
| Explain verified state | Authenticated current record and source time. | Information service. | Read and disclosure event. | Customer receives accurate relevant explanation. | Source conflict or insufficient authentication. |
| Recommend an option | Eligible alternatives, purpose, uncertainty and exclusions. | Advisory authority only. | Options presented and customer choice. | Choice remains voluntary and executable. | Hidden commercial purpose or unavailable alternative. |
| Offer price or remedy | Authoritative amount, conditions, availability and expiry. | Named commercial or service authority. | Reservation linked to customer and case. | Offer can be honoured on stated terms. | Limit exceeded or no valid reservation. |
| Promise action by a deadline | Owned work item, capacity and service commitment. | Principal allowed to bind the organisation. | Promise owner, due time and case link. | Completion receipt arrives within terms. | No accountable owner or incapable receiving queue. |
| Declare completion | Authoritative external or record mutation. | System or role that performed the act. | Immutable action identifier and final state. | Customer and dependent systems see the same state. | Model assertion without operational receipt. |
Transfer the journey, not the burden
Generation should continue only while the channel can carry the evidence, authority and care needed for resolution. A customer request for a person is itself a transfer trigger. So are repeated loops, conflicting sources, vulnerability, accessibility need, negotiation, institutional accountability and a consequence window shorter than the receiving route's delay. Transfer is successful when it reaches the smallest capability that can resolve the objective without making the customer reconstruct the case.
The Continuity Packet contains verified identity level, the customer's goal in their own terms, current state, attempts and results, verified facts and conflicts, options and choices, open promises, permissions, accessibility and language needs, urgency, transfer reason, evidence links, prohibited actions and receiving acceptance. A generated narrative may help orientation, but it cannot replace the records that support material claims.
| Packet field | Authoritative source | Receiving use | Privacy treatment | Acceptance | Expiry |
|---|---|---|---|---|---|
| Identity and authentication | Identity service and assurance event. | Know which claims and actions may proceed. | Share level and reference, not unnecessary credentials. | Receiver validates audience and current session. | Short-lived; step up for higher consequence. |
| Customer objective | Customer's own statement plus confirmed interpretation. | Continue the job rather than classify the latest sentence. | Retain only what the service purpose needs. | Customer can correct it visibly. | Refresh when journey or request changes. |
| Facts, conflicts and attempts | Systems, documents and action receipts. | Avoid repeated questions and failed steps. | Links under role-based access; no broad transcript copy. | Receiver can inspect primary evidence. | Per-source freshness and retention. |
| Promises and rights | Customer Promise Ledger and applicable policy. | Preserve deadlines, choices, complaint and appeal state. | Minimum promise record separated from sensitive content. | Named owner accepts open obligation. | Rights may outlive the interaction session. |
| Accessibility and urgency | Customer preference and observed service condition. | Provide suitable channel, format, pace and queue priority. | Do not reuse vulnerability for unrelated persuasion. | Receiver confirms capability and response time. | Review at each transfer and after condition changes. |
Thought experiment 1: the shorter conversation that creates more work
A chatbot's containment rises because it ends sessions after presenting three help articles. The dashboard reads success. Now include every customer who returns by phone, abandons silently, repeats the same question or misses a deadline. The apparent efficiency dissolves. The automation reduced visible interaction inside one channel while exporting investigation and reconstruction work to customers and staff.
The Experience Denominator begins with eligible, attempted, authenticated and admitted interactions, then follows self-service, generated, deterministic, specialist and human routes to resolution, repeat, abandonment, complaint, appeal and redress. Answer completion, task completion, authoritative action and customer resolution are separate states. A channel can complete an answer while the customer's objective remains untouched.
| Population | Route | Outcome | Repeat or effort | Complaint evidence | Segment view | Owner |
|---|---|---|---|---|---|---|
| Eligible attempts | All offered routes, including failures before admission. | Known, pending, abandoned or missing. | Authentication, evidence and channel-switch work. | Complaint access visible even without completion. | Language, accessibility and vulnerability coverage. | Journey owner. |
| Generated route | Factual, bounded promise, hold or transfer. | Answer, action and resolution recorded separately. | Loops, rephrasing and repeat contact retained. | Correction and dissatisfaction linked to claims. | Claim and promise errors by relevant cohort. | Interaction owner. |
| Transfer route | Accepted, queued, expired, rejected or rerouted. | Resolution follows the receiving capability. | Wait, repetition and reconstructed evidence. | Blocked human access is itself a service failure. | Queue performance by need and consequence. | Receiving service owner. |
| Promise cohort | Any channel that created a material expectation. | Kept, late, changed, broken, corrected or compensated. | Customer chase and evidence burden. | Dispute, appeal and redress outcome. | Broken commitments and remedies by segment. | Promise owner. |
| Incident population | All interactions exposed to the common defect. | Identified, notified, corrected and remediated. | Proactive recovery reduces repeated contact. | Complaints supplement, not define, affected count. | Search for quiet and poorly served groups. | Incident and redress owner. |
A promise ledger turns words into owned service
The Customer Promise Ledger is not a transcript archive. It stores the minimum evidence needed to reconstruct material commitments and protect rights: journey identifier, customer objective, channel and accessibility state, claims and supporting sources, options and exclusions, promises and conditions, authority, customer choices, transfer acceptance, action receipt, fulfilment, correction, complaint, redress and retention. Sensitive conversation remains under separate purpose and access controls.
Applied example: a pending payment across chat and phone
An authenticated customer asks why a card payment is pending. The contract permits explanation, not a settlement guarantee. The claim graph contains the current pending state, the authorisation time, general clearing information and several possible causes. Only the first two are customer-specific facts. The composer says what is verified, labels possible causes, explains when the status will next be checked and offers a dispute route if the customer does not recognise the payment.
The customer then asks for a person. The Continuity Packet carries the identity level, transaction reference, exact question, evidence already inspected, possible causes already described and the open promise to check status. The telephone employee accepts the packet, views primary records and does not repeat authentication beyond what the higher-risk action requires. If a dispute begins, the promise ledger switches from explanation to case commitment and records owner, deadline and receipt. The journey is resolved when the promised investigation action and customer notice occur, not when chat ends.
Applied example: common eligibility error at scale
A prompt change begins telling customers in several channels that a hardship option is unavailable. The answer cites a real policy but mistranslates one condition. Individual language appears plausible, so ordinary transcript sampling misses the pattern. Promise monitoring compares negative eligibility claims with subsequent specialist decisions and detects an abnormal disagreement concentrated in one customer segment.
The incident plane stops the affected prompt and knowledge combination, preserves the valid deterministic routes and identifies every exposed interaction from claim receipts rather than complaints alone. Teams prioritise customers near a deadline, issue corrections through suitable channels, restore options, extend time where authorised and record remediation. The old prompt, cached summaries and downstream scripts are removed. Reauthorisation requires the corrected policy mapping, multilingual claim tests, fresh transfer capacity and independent assurance. Average satisfaction never becomes the closure criterion.
Twenty boundary cases
Generated Customer Interaction Designer
The instrument tests a proposed interaction route, not the truth of a real customer case. Load one of ten scenarios or change the conditions. Its five outcomes distinguish factual generation, a bounded promise, evidence hold, continuity-preserving transfer and a stop where the channel cannot carry the consequence.
Deliver a factual generated response
The strongest rival: generation is often the wrong service
The objection rejects generation by default. Remove avoidable contacts. Fix the product or policy that causes repeat demand. Use deterministic transactions for stable tasks. Generate where language adaptation, explanation or synthesis adds value. Preserve friction where consent and consequence require reflection. Route to a person when judgement, care, negotiation or institutional accountability is the scarce service. Store less conversation while preserving more verifiable promise continuity.
This is also an economic challenge to the architecture. A generated conversation can make the visible contact cheaper while moving expensive work into verification, correction, complaints and later human queues. That is not productivity if the customer must repeat the story or if staff reconstruct an undocumented promise. The relevant comparison counts the whole journey: demand avoided by a clearer product, successful deterministic completion, generated assistance, capable human work, follow-up, recovery and the cost of unresolved obligations. A slower route can be better when it reaches a durable outcome with less total effort.
Nor should continuity mean collecting everything. A complete transcript can contain intimate context, obsolete inferences and language that was never needed to resolve the case. The system should retain the smallest evidence set that lets the next actor verify identity, understand the goal, distinguish fact from inference, honour active commitments and explain the decision. Purpose limits, access controls, retention periods and correction routes belong inside the continuity design. Memory without those constraints is surveillance presented as convenience.
Thought experiment 2: the disclosure that changes nothing
Suppose a service clearly labels every reply as AI-generated. Customers now know the speaker is a machine. Does that make an invented refund, blocked complaint route or inaccessible control acceptable? It does not. Disclosure may help calibrate expectations, but research on disclosure and anthropomorphic cues is context-dependent. Trust can fall or rise without the service becoming more capable. The operating decision remains tied to claims, authority, action and rights.
Conversely, a human voice and name do not guarantee understanding or authority. The useful comparison is not machine versus person as a badge. It is which route can establish the customer's objective, inspect primary evidence, make the permitted decision, act and own recovery. A human reviewer approving every sentence can add cost while leaving the back-office action disconnected.
An observation would weaken this architecture: materially consequential generated interactions that reliably preserve cross-channel facts and commitments, complete authorised actions, reduce total customer effort, maintain segment outcomes and resolve complaints without claim-level gates, continuity packets or a promise ledger. Containment, satisfaction or conversational preference alone would not establish that result.
Assure the journey and give the panel stop power
The Generated Experience Assurance Docket holds the objective, population and state; Interaction Contract; claim graph and sources; disclosure, identity, consent, privacy and accessibility design; authority gate; route and capacity; Continuity Packet; promise ledger; ordinary, complex, stale, adversarial and vulnerable tests; customer effort and repeats; complaints, disputes, appeals and redress; segment and common-mode results; cost and displaced demand; residual risk; and authority for suspension, correction and retirement.
The operations panel keeps answer completion, task completion, authoritative action and customer resolution separate. It shows journeys, claims, freshness, permissions, promises, receipts, transfers, queue age, continuity, accessibility, repeat contact, broken deadlines, complaints, appeals, redress, segment differences and incident populations. Its stop control must disable the affected model, prompt, knowledge and channel combination while preserving valid alternatives.
Assurance must sample journeys, not only individual replies. A sentence can be accurate when written and still contribute to a broken experience if another channel contradicts it, the promised action never executes or the receiving team lacks authority. Tests should therefore follow representative cases from eligibility and admission through authentication, decision, action, receipt, follow-up and redress. They should include customers who abandon, switch channels, use assistive technology, communicate in another language or arrive with incomplete evidence. Those paths reveal the burden hidden by average satisfaction and containment rates.
A common-mode defect changes the response. If one prompt, retrieval rule or policy mapping can fabricate the same promise repeatedly, ordinary case-by-case correction is too narrow. The organisation must identify the exposed population, freeze the affected route, preserve evidence, issue consistent corrections and provide a practical remedy. Recovery is complete only when the erroneous expectation and any downstream action have been repaired, not when the model begins producing better sentences.
NIST's voluntary AI Risk Management Framework, which is under revision, and the Generative AI Profile support contextual testing, human roles, provenance, monitoring, feedback and incident response. WCAG 2.2 provides current accessibility criteria for web content, not proof that every customer's needs are met. The CFPB's chatbot report is sector-specific evidence about consumer-finance failure and human access. The FTC applies established substantiation principles to AI claims. These materials guide tests; none certifies an interaction route.
EU data-protection and AI rules apply according to legal scope, role, system and phased dates. Their transparency, data, rights and affected-person provisions should be interpreted with counsel for the actual service. ISO 42001, ISO 10002 and ISO 10004 inform management, complaint handling and customer-satisfaction processes, but certification or process conformance is not evidence that a disputed customer was made whole. UK government and US GAO guidance likewise remains bounded to its institutional purpose.
The Generated Interaction Reauthorisation Rule applies when purpose, population, product, policy, price, remedy, channel, model, prompt, knowledge, data use, disclosure, identity, consent, language, accessibility, tone, authority, action, transfer route, queue, right or law changes materially. It also applies after invented state, unsupported promise, false completion, blocked human access, accessibility failure, complaint spike, broken deadline, redress failure or common-mode incident.
Generate only what the organisation can stand behind
Abundant language makes a polished interaction easy. A good customer experience remains difficult because it depends on institutional memory, current truth, constrained authority, suitable channels, capable people and completed action. The organisation should therefore optimise neither conversation length nor automation containment. It should reduce the customer's effort to reach a verified and recoverable outcome.
Put the contract before the composer. Decompose claims before they become prose. Lock material promises to authority and receipts. Carry evidence and rights across channel boundaries. Preserve the customer's option to correct, refuse, complain and reach a person. When the promise and outcome diverge, find the affected population and repair the journey. Generated interaction earns its place only when the organisation can prove the facts, own the promise and complete the customer's actual objective.
References
- Katherine N. Lemon and Peter C. Verhoef, Understanding Customer Experience Throughout the Customer Journey, Journal of Marketing, 2016.
- Ewa Luger and Abigail Sellen, Like Having a Really Bad PA: The Gulf Between User Expectation and Experience of Conversational Agents, CHI, 2016.
- Theo Araujo, Living Up to the Chatbot Hype, Computers in Human Behavior, 2018.
- Nika Mozafari, Welf H. Weiger and Maik Hammerschmidt, Trust Me, I'm a Bot, Journal of Service Management, 2021.
- Stephen S. Tax, Stephen W. Brown and Murali Chandrashekaran, Customer Evaluations of Service Complaint Experiences, Journal of Marketing, 1998.
- A. Parasuraman, Valarie A. Zeithaml and Leonard L. Berry, SERVQUAL: A Multiple-Item Scale for Measuring Consumer Perceptions of Service Quality, Journal of Retailing, 1988.
- Consumer Financial Protection Bureau, Chatbots in Consumer Finance, 2023.
- Federal Trade Commission, Statement on the Joint Interagency Statement on AI, 2023.
- National Institute of Standards and Technology, AI Risk Management Framework: Core.
- National Institute of Standards and Technology, NIST AI 600-1, Generative Artificial Intelligence Profile.
- World Wide Web Consortium, Web Content Accessibility Guidelines 2.2.
- European Union, Regulation (EU) 2024/1689, Artificial Intelligence Act.
- European Union, Regulation (EU) 2016/679, General Data Protection Regulation.
- International Organization for Standardization, ISO/IEC 42001:2023, Artificial intelligence management systems.
- International Organization for Standardization, ISO 10002:2018, Guidelines for complaints handling.
- International Organization for Standardization, ISO 10004:2018, Guidelines for monitoring and measuring customer satisfaction.
- UK Government, Artificial Intelligence Playbook for the UK Government.
- U.S. Government Accountability Office, Artificial Intelligence: An Accountability Framework for Federal Agencies and Other Entities.