Did the AI Assistant Actually Resolve the Request?

A customer asks to move a booking to Friday. The assistant replies that Friday is available and offers to help. The customer closes the conversation believing the booking has changed. The business still holds the original reservation.

This illustrative failure concerns the meaning of the exchange. The assistant may have supplied accurate availability while leaving the customer with the wrong understanding of the transaction.

Write the service promise before designing the conversation. Can the feature answer general questions, look up an account, submit a request or complete a change? Tell the customer what it can do when that distinction affects their next step.

Microsoft Research's human-AI interaction guidelines support clear capabilities and user control. For a customer-service feature, the test is whether someone can explain the state of their request after using it.

Give the customer a recognisable description of the assistant's role. A business does not need a long introduction, but it should avoid a human persona that conceals how the service works. If staff must approve an exception, explain that approval instead of letting fluent conversation imply authority the system lacks.

The customer should leave each exchange knowing whether anything has changed.

A visitor asking about opening hours needs a different service from someone requesting a change to a paid booking. Define when the interaction must establish identity and authority before it accesses or changes a record.

An order number or a confident account of a purchase may help locate a request. The business still needs an appropriate method for deciding whether the person may see its details or alter it. Keep that decision in the application and its established access controls.

Do not encourage customers to paste unnecessary identity documents, payment details or passwords into an open chat. Explain the information needed and use an approved collection route when the task requires sensitive information.

NIST's Generative AI Profile identifies data privacy and false generated content among the risks to manage. The service should therefore obtain account facts from authorised records and restrict what the assistant can disclose.

Plan for people acting on somebody else's behalf. A family member, colleague or travel arranger may have a legitimate reason to help without having authority over every part of the account. The business must set those permissions for its own service and jurisdiction.

If verification fails, offer a usable recovery route. Preserve non-sensitive context where appropriate, explain the next step and keep the same disclosure boundary when the request reaches a person.

A booking amendment can affect the date, price and cancellation conditions. The customer needs those material details before agreeing to the change.

Show a concise confirmation drawn from the current booking and applicable terms. Identify the affected reservation, the proposed arrangement and any charge or refund. If availability has changed during the conversation, refresh the offer before asking for consent.

Keep a request for information separate from an instruction to proceed. Asking "Would Friday cost more?" should not authorise a booking change. A confirmation action should describe the commitment clearly enough that the customer can choose it deliberately.

After submission, report the result returned by the business system. The confirmation message should distinguish a completed change from a request awaiting review. Give the customer a reference they can use outside the conversation.

A failed connection needs particular care. If the assistant cannot establish whether the change took effect, instructing the customer to try again may create another transaction. Show that the outcome is being checked and route the unresolved request to the team able to reconcile it.

These states belong in the AI service implementation. The conversation, account page and confirmation email should describe the same booking. A friendly response cannot supply a confirmation the underlying system has not returned.

"Speak to a person" creates another promise. Define where the request goes, what the receiving team sees and how the customer can tell that it has arrived.

A useful handoff record identifies the request, the relevant account or transaction reference, the steps already completed and the decision still needed. Include confirmed facts separately from the assistant's interpretation. The next person should not have to read an entire conversation to discover that a booking change is pending.

Let the customer correct an inaccurate summary before it becomes the basis of the next response where that is practical. Preserve the relevant original record for staff to inspect under the business's access and retention rules.

Explain the supported response arrangement. If staff are unavailable, say how the customer will be contacted and what they can do in the meantime. Do not present an unattended queue as live assistance.

Keep ownership visible until the receiving team accepts the work. A transfer message is useful only if somebody can find and resolve the request afterwards. Give staff a way to return a case for missing information without losing its history.

The handoff is part of the customer experience, including the period after the AI stops responding.

Review this route with the people who will operate it. Their permissions, working hours and ability to authorise exceptions determine which promises the interface can make.

Some customers will prefer a form, account page or telephone conversation. Others may be unable to complete a chat interaction. Make the alternative discoverable before they have to fail repeatedly.

The alternative should support the same important task. A general contact link is a poor substitute for a specific cancellation route if customers cannot tell whom to contact or what information to supply.

Use the Web Content Accessibility Guidelines as a technical basis for accessibility evaluation. Test the full interaction as well: reaching the assistant, reading a changing response, reviewing a transaction and obtaining a reference with the assistive technologies relevant to the audience.

Supported languages need equally careful testing. Confirm that prices, dates, policies and pending states retain their meaning. A translated greeting provides little reassurance if the assistant cannot explain an exception or the handoff returns a message in another language.

A focused service-design review can compare these routes through the same customer request. Each should reach an understandable result without unnecessary disclosure or repeated explanation.

Evaluation should continue through the recorded outcome. Check completed amendments, pending decisions, failed requests and customers returning to ask what happened.

Include cases with unavailable dates, expired sessions, disputed charges, changed details and interrupted connections. Ask participants what they believe is confirmed and compare that answer with the actual record. This exposes misunderstandings that a fluent-response score will miss.

A low handoff rate can be useful only alongside resolved requests. Likewise, a short conversation may mean the task was easy or that the customer abandoned an unclear exchange. Read those measures with the transaction and support history.

Keep a small collection of service examples for regression checks when the assistant, policies or integrations change. Include an action it must decline and a request that requires a person.

Expand the feature when the business can support the requests it creates. Customers should be able to return later, find the agreed outcome and reach someone who can act on the same account of events.