Usually yes. A customer told no deserves to know why, and in some cases the law requires specific reasons. A support agent, AI or human, should give the reason in approved words and say what the customer can do next. The exceptions are reasons that would tip off a suspect, reveal a security control or disclose someone else's information.
Whose refusal is it?
Start by separating two kinds of no, because the agent explains them differently.
The agent's own limit. "I can't approve a refund of that size, but a colleague can." Here the request may well succeed; the agent just is not the one allowed to grant it. The honest reason is the agent's scope, and the next step is a person. Hiding that behind "our policy doesn't allow it" misleads the customer into thinking the answer is final. The difference between a request that is refused and one that is held for a person is set out in allowed, held, refused, withheld.
The business's decision. "Your claim was declined because the damage was caused before the policy started." Here the reason belongs to whoever decided, and the agent relays it from the record. It should not compose its own explanation.
Which reasons can the agent give?
| Reason type | Can the agent explain it? | How |
|---|---|---|
| Outside the agent's own bounds | Yes | "That's beyond what I can do; I'll pass it to someone who can decide." |
| Policy rule | Yes | State the rule from the policy source and where the customer can read it |
| Eligibility criteria not met | Yes | Name the criterion that was not met, in approved wording |
| Credit decision | Only the recorded reasons | Relay the reasons the decision-maker recorded; a person handles challenges |
| Suspected fraud or financial crime | No | Fixed neutral wording; route to the team |
| Security control triggered | Partly | "We couldn't complete that for security reasons," without saying which check |
| Involves another person's data | No | Explain that it cannot share details about others |
Credit decisions carry specific duties in several markets. In the United States, ECOA and Regulation B require specific reasons when credit is denied, including when a model is used. Under the GDPR, Article 22 gives people rights around decisions based solely on automated processing with legal or similarly significant effects. The agent's job is to relay the recorded reasons faithfully, never to generate a plausible one.
The fraud row is the one teams most often get wrong. Explaining that a payment was blocked "because it matched a scam pattern involving cryptocurrency platforms" tells a criminal how to rephrase the next attempt. A fixed, neutral line protects the control and the customer.
An illustrative example
Take a buy-now-pay-later provider's chat agent. A verified customer asks why their application to increase their spending limit was turned down.
The decision record shows two recorded reasons: a recent missed payment and a short account history. The agent gives both, in the approved wording, and explains that the customer can ask for the decision to be reviewed by a person. It does not add "if you make three more payments on time you'll probably be approved", which no rule supports.
The customer then asks why an earlier purchase was declined at checkout. The record shows a fraud rule fired. The agent says only that the transaction could not be completed for security reasons, that their account is not restricted, and that they can try again or contact the team if it happens again.
What controls make it safe?
- Reason codes, not free text. Each refusal carries a code mapped to approved customer wording. The agent selects; it does not write.
- A blocked list. Codes for fraud, financial crime and some security checks map only to neutral wording.
- Next step every time. Every explanation ends with what the customer can do: ask for review, provide information, complain.
- Disclosure of the agent's nature. Customers should know an AI is explaining, and how to reach a person; see whether an AI support agent should tell customers it is an AI.
- Filed explanations. What the agent told the customer is recorded beside the verdict.
The tone of the refusal matters as much as the reason; how an AI support agent should refuse a request covers wording and structure, and what "refused" means for AI agents covers the verdict itself.
Where Pryme fits
In Pryme, every verdict names the bound that decided it, so the agent can tell a customer truthfully whether the no came from its own limits or from the business. Reasons that must not be disclosed map to fixed wording at the platform level. More is in the AI support agent that knows when to say no.
Questions people ask
Should the agent say "computer says no"?
No. If an automated decision was made, say so plainly and explain how the customer can ask a person to look at it.
Can a customer insist on knowing a fraud reason?
They can ask, and the agent should route the request to a person. That person decides what can be shared; the agent does not.
What if there is no recorded reason?
Then the agent cannot give one. It should say it does not have the reason and route the question to whoever made the decision.