Skip to main content
Account and payment support requires careful separation between general guidance and customer-specific information. An agent can explain an approved policy from knowledge, but it needs an authenticated connection to retrieve a particular customer’s record. Begin with a narrow, read-only enquiry where possible. Treat financial actions and changes to account access as separate workflows that require technical and policy review.

​
Decide what belongs in knowledge

Use knowledge for information that applies generally: how a billing process works, where customers can find a receipt, or what the published support procedure requires. Check that the content is current and matches the policy your team actually follows. Do not use general guidance to make an unsupported claim about an individual transaction.

​
Establish identity before retrieving a record

Work with your developer to define authentication and the customer identity available to the agent. Limit the connection to the fields and operations needed for the enquiry. A remembered preference or a claim made in chat is not enough to authorize a financial change. Test requests made without verification and attempts to retrieve another customer’s record.

​
Explain the result without extending it

In a fictional SaaS example, a customer asks whether a payment has been received. The agent follows the configured identity check and retrieves the approved status record. It can report what the source confirms. If the customer sees something different, or the available data is incomplete, it should preserve the relevant context and involve the support team. It should not infer a refund, duplicate charge, or account change from information that does not establish it.

​
Keep sensitive actions separate

Refunding a payment, changing access, or updating account ownership each needs explicit permissions, business rules, and any required confirmation. These operations are not automatically available because the agent can read a status. Test success, rejection, ineligible requests, and service failure before enabling a write operation. Report completion only after the system confirms the action.

​
Give the receiving team a useful handoff

Decide which cases need a person and who will respond. Review the conversation and attempted lookup so that the customer does not have to restart the explanation unnecessarily. Measure accuracy and appropriate escalation during the trial. Do not expand to more sensitive work until the selected enquiry behaves as intended. Read when you need a developer to plan the people and technical work involved.