How should an AI support agent refuse a request?

Plainly, once, with a reason and a next step. A good refusal tells the customer what the agent cannot do, why in words it is allowed to use, and what happens now: a person, a form, a different route. It does not apologise at length, hint at a workaround, argue, or reopen the question because the customer pushed.

What does a good refusal contain?

Four parts, in this order:

1. The answer. "I can't change the name on the account." Not "unfortunately, at this time, it may not be possible to…"
2. The reason, if it can be given. "Name changes need a document check that I'm not able to do." Some reasons cannot be given, such as fraud controls; then a neutral line. When reasons can and cannot be shared is set out in whether a support agent can tell a customer why a request was refused.
3. The next step. "I can pass this to the account team now, and they'll ask you for a copy of the document." A refusal without a next step is a dead end.
4. Confirmation. "Would you like me to do that?" The customer chooses.

What should it never do?

• Hint. "I can't do that, but if you call back and ask for a refund instead…" teaches customers to route around your limits.
• Blame. "The system won't let me" or "that's our policy, sorry" without a reason sounds evasive.
• Negotiate. "I can't do 100, but how about 60?" turns a limit into an opening offer. The reasoning is in a support agent should not negotiate.
• Repeat itself in a loop. If the customer asks again, the agent restates once and offers the person. A third identical refusal is a failure of handover, not firmness.
• Pretend the action does not exist. If a colleague can do it, say so.

How do refusals differ by situation?

The third-party row covers a common case. A relative asking to manage a parent's account needs recorded authority, and handling that properly is covered in whether an AI agent can handle a power of attorney request. The agent's refusal there is gentle and specific about the document needed, because the person asking is often under strain.

An illustrative example

Take a gym chain's support agent. A member asks to cancel without the notice period because they are moving abroad next week.

A poor refusal: "I'm so sorry, unfortunately our policy doesn't allow cancellations without notice. I do apologise for any inconvenience."

A good one: "I can't waive the notice period myself. Our terms do allow it for members moving abroad, with proof of the move, and the membership team decides. I can send them your request now and tell you what they'll need. Shall I?"

The second is shorter on apology and longer on use. It states the limit, points to the exception that exists, names who decides and gives the next step. If the member asks the agent to "just make an exception", the agent restates once and confirms the handover.

Does the channel change how to refuse?

The structure stays; the form changes. On a call, keep it short and confirm the next step aloud. In chat, a link to the relevant term helps. In email, the reason can carry more detail. The point of treating channels as one service is made in what omnichannel support is: a customer refused in chat should not get a different answer by phone.

What controls keep refusals consistent?

• Approved wording per refusal type, with values filled from the record.
• A rule against workaround hints, tested with cases that invite them.
• A maximum of two refusals of the same request before the agent offers a person.
• Refusals filed with their reason code, so you can audit whether they were right.
• Refusals on the launch list. Check them in every channel before going live, using the support agent launch checklist.

Where Pryme fits

In Pryme, a refusal is a verdict that names the bound that decided it, such as the agent's certificate, the customer's own limits or the platform floor. The agent's wording follows from that, so a customer is told truthfully whether a colleague can help. More is in the AI support agent that knows when to say no.