When an AI Feature Should Refuse Instead of Guessing

A helpful draft that invents a price does more damage than a blank field. Customers treat numbers as promises. Staff then spend the afternoon undoing a sentence the tool was never allowed to write. Refusal is not a failure of the model. It is a product decision you write down before the first live run.

This guide is for a team that already has an assistant drafting replies, labels, or notes. You will define the cases it must refuse, the shape of a good refusal, and the weekly count that tells you whether it is being too shy or too confident.

Decide what a wrong answer costs

List the outputs that create an obligation: money, dates, legal claims, medical or safety advice, and statements about a named customer. Those outputs are not allowed unless the exact figure or fact is present in a source you named. A polite paragraph that 'sounds right' is still a guess.

Then list outputs that are cheap to fix, such as a subject line or a category on an internal ticket. Those can be suggested with a lower bar, because a person sees them before a customer does. Mixing the two lists is how a tool that is fine for sorting mail starts quoting discounts.

• Money, dates, and promises: refuse unless the source states them
• Other customers' details: always refuse
• Internal labels: suggest, then let a person confirm
• Anything outside the named sources: refuse

A blank is a better answer than a hedge

Do not let the draft say 'typically', 'around', or 'most customers'. Those words hide a missing fact. The allowed refusal is short: 'Not in the source' plus the original request attached for a person. Staff can fill a blank. They cannot always see a hedge.

Show the source link next to every accepted fact. If the tool cannot point at a sentence, it does not know the fact, whatever the wording feels like. Reviewers should reject any accepted fact that has no link, even when the sentence happens to be true from memory.

Hand the refusal to a named person

A refusal that lands in a shared inbox with no owner is the same as silence. Create a task with the original text, the reason for refusal, and the person who already does this job. They answer the customer. The tool does not get a second try in the same minute.

Tell that person what 'good' looks like for a week of refusals. If they are rewriting almost every draft, the instructions are too loose or the sources are incomplete. If they are answering questions the tool should have handled from the published page, the refusal rules are too wide.

A refusal policy you can paste into the instructions

Allowed facts: the services page and the published price list only.
If the price, date, or customer name is not in those pages, reply:
NOT IN SOURCE. Create a task for the duty owner. Do not estimate.
Never mention another customer's order, invoice, or call.
A hedge (typically, around, usually) counts as a wrong answer.

Replace the pages and the owner with yours. Keep the last two lines.

Score wrong answers above missed answers

Each week, sample twenty live runs. Mark each one correct, refused-rightly, refused-wrongly, or wrong. A wrong price counts as two. A rightful refusal counts as a success. Teams that only measure 'did it answer' will train the tool to stop saying it does not know.

If wrong answers are not falling after two weeks, stop adding features. Tighten the sources or the refusal lines. If rightful refusals are flooding the owner, add the missing page to the sources instead of telling the tool to try harder.

Apply it to one live case this week

Take one real item from the last month and walk it through When an AI Feature Should Refuse Instead of Guessing. Write the input, the output a colleague could use without calling you, and the name of the person who may accept or reject the result. Keep these steps in view: Name the forbidden guesses; Return a blank, not a hedge; Hand the case to a person; Score wrong answers higher than blanks. If a step has no owner, leave the workflow off. An unnamed step becomes a message nobody checks.

Save the before and after where the team already works. Note one mistake in a sentence someone can act on: a missing field, a wrong destination, or a line that should have waited for a person. Do not add another tool in the same sitting. Next week, fix only that mistake and run five more real cases. A workflow that survives those five is ready to connect to the rest of the office.

Questions people ask before they start

Will customers hate a refusal?

They hate a wrong promise more. A short handoff to a person, sent the same day, is a normal service reply. A invented date is a complaint.

Can we show a confidence percentage?

Only if you have checked that a low number really matches your wrong answers. Most model scores do not. A blank based on missing sources is easier to defend.

Who writes the refusal rules?

The person who currently answers these requests, together with whoever is accountable if a wrong fact reaches a customer.

How do we start without a large project?

Use one real case, one owner, and the steps for When an AI Feature Should Refuse Instead of Guessing. Expand only after five more cases pass with that same owner. A larger build before that test usually adds screens the team will not open.

How MadniSofts can help

An AI feature earns trust when it would rather hand the case back than invent a fact the business will have to keep. You can review MadniSofts AI development, or talk to the team from the homepage.