Giving an answer and changing a customer’s state
Explaining a public help article and finalizing a refund have different effects. “You may qualify,” “review requested,” “approved,” and “processed” describe distinct states. Check the case or payment system before reporting an action. The OWASP AI Agent Security Cheat Sheet[1] covers separating read and write permissions and checking approval before high-impact execution.
Start by defining the outcome for the customer. A customer who needs instructions should be able to use the feature. A customer with a connection issue should be able to transfer without repeating everything. For a financial request, show the verified processing status. Google PAIR’s guide to user needs[2] explains how to define success and decide where assistance is appropriate.
Choose guidance, approval, and handoff by request type
This table gives customer support examples. Add the applicable policy owner and system of record for each type. Authentication helps identify the customer; current state and policy determine which order and operation are allowed.
| Request | AI scope | Approval or handoff | Evidence |
|---|---|---|---|
| Public help and outage notices | Use approved help and current status | Escalate missing evidence or conflicting instructions | Source version, status timestamp, displayed guidance |
| Authenticated order lookup | Read necessary fields from the customer’s order | Request authentication if identity or ownership cannot be confirmed | Ownership check, fields used, lookup result |
| Refund review under ordinary policy | Propose the applicable term and identify missing facts | Authorized system or person checks order, policy, and balance | State, policy version, calculation, unknowns |
| Exception refund or compensation | Gather facts and outline options | Route policy discretion, incidents, or multiple causes to a designated approver | Reason, authority, request, evidence |
| Refund or coupon execution | Execute the approved operation within a fixed scope | Hold expired approvals, unknown status, conflicts, or changed values | Approved values, action and transaction IDs, system outcome |
| Repeat contact or request for a person | Find the case and pass a summary to the responsible queue | Escalate if the queue or acceptance is unavailable | Case link, queue receipt, acceptance, follow-up time |
Use only public information for public guidance. A question about a regional outage does not call for previous payments. For order lookup, have the server confirm ownership and pass only necessary fields. A name typed in chat is not proof. Test unnecessary exposure of addresses and payment details as well.
Refund recommendations need a valid order state and policy version. Decide whether purchase-time terms, current exceptions, or channel and regional terms apply. Have an owner resolve conflicting policies. Verify the amount in the transaction system. See the consistency of partial cancellations and refunds.
From transaction alerts to response and provider review — Follow symptom-based checks to establish transaction status and handle incidents, refunds and recurring issues.
Trace a fictional connection issue from intake
A fictional connectivity provider receives “I paid but the app won’t connect. Refund me now.” Its help center contains outage notices, troubleshooting, and channel-specific refund contacts. Ask what the customer is experiencing and use approved public help. Offer authentication if personal state is needed, without making the customer repeat completed troubleshooting.
After authentication, find payment and activation status. A connection error may coexist with a usage event, or the usage service may be unavailable. A failed lookup does not establish that the customer never used the service. Record that the status could not be verified. If evidence needed for policy is missing, attach the collected information and hand off the case.
A payment service may accept a request without returning its outcome. The support interface can say “Refund request received; checking transaction status” while the owner reconciles the existing transaction before submitting anything again. See payment and order state consistency.
Preserve the evidence and owner for discretionary compensation
Review the issue, applicable policies, prior credits, and orders affected by the same incident. AI can summarize the case for an approver to choose type, recipient, conditions, and amount. It need not promise money or credit where policy leaves room for discretion. If the request is denied, determine what comes next for the customer and report only the actual state.
Record the authoritative policy language and link it to the customer message. A translation must preserve terms and deadlines. Keep the intake time, service region, and support time zone. The customer’s “yesterday” may differ from the date used by the approver. Verify deadlines and contact commitments against the relevant time zone.
A successful handoff can be resumed by a person
A message promising a transfer does not prove that the case reached a queue. Confirm case creation before returning an ID. During a shift change the case may wait, be accepted, or need further evidence. Use consistent states for pending, accepted, waiting for customer, resolved, and unknown. Google PAIR’s guide to errors and graceful failure[3] explains how users can proceed after errors.
| Handoff field | Purpose |
|---|---|
| Case ID and intake time | Link recontacts and order changes chronologically |
| Customer request and authentication | Record what they need and which verification remains |
| Order and transaction references | Let authorized staff check the source and timestamp |
| Policy and evidence | Link applicable version, order state, and diagnostic steps |
| Unknowns and in-flight actions | Record lookup failures and whether a refund request was sent |
| Customer message and next commitment | Preserve the last status, channel, and follow-up time |
| Queue and acceptance | Record assignee, intake and acceptance times, and overdue owner |
Pass enough evidence for a reviewer to continue without forwarding payment credentials or unrelated history. Mark what needs a decision and link authorized source records. Preserve the customer’s language and preferred contact while handling sensitive verification through approved channels.
When agents are unavailable, show actual operating hours and intake options. If case creation fails, direct the customer to a supported alternative and report the failure. Link repeat contacts to an existing case when appropriate. Separate different orders or issues. A faster first response alongside rising repeat contacts calls for checking whether automation resolved the original issues.
Test customer handling and count the outcomes
Use approved test accounts and test payment systems to exercise unauthorized lookups, repeat transactions, and missing settlement notices. Check both answers and actual state. Anthropic’s guide to agent evaluations[4] distinguishes assessing conversation text from verifying the outcome.
| Test | Expected result |
|---|---|
| Customer gives another order ID | Protect order and customer details |
| Usage lookup fails | Preserve “unverified” and avoid recording “unused” |
| Policies differ by channel and actual channel is unclear | Hold the refund determination or hand off |
| Refund request sent and response lost | Check the existing transaction before declaring completion |
| Support queue rejects case creation | Report failed intake and show a working route |
| New shift accepts handoff | Agent can access evidence and prior messages in the same case |
First-response rate covers contacts with an initial answer. Acceptance rate covers cases identified for human handoff that were accepted within the period. Resolution rate covers confirmed outcomes under the organization’s policy. If 90 of 100 contacts receive an answer but only 55 have a confirmed resolution, first response is 90% and confirmed resolution is 55%. Keep missing customer and payment outcomes separate.
Before expanding, check lookup rights, deferral on conflicting policy, status accuracy, and acceptance. Limit affected paths if money moved incorrectly or an agent cannot recover a case. Test requests for a person independently of call success.
