Price the work that leaves the automated path

Follow the task after the refusal

A user who receives no answer may ask again, contact support or investigate manually. Those actions consume time and can create repeated model requests. Counting only the first declined response understates the cost of the workflow.

Measure clarification turns, successful resolution after clarification and escalation handling time. Keep waiting time separate from active work. A queue delay may need staffing or routing changes, while high active effort may indicate an incomplete handoff.

Do not frame every refusal as wasted work. Some preserve a necessary authority boundary or prevent a consequential unsupported instruction. Their value depends on the task.

Compare the two error costs

An unnecessary refusal delays a task the system could have completed. An unsupported answer can cause a wrong decision that is harder to detect and correct. The balance differs between a low-risk summary and an operational instruction.

Use concrete examples with the business owner rather than inventing one universal monetary penalty. Some consequences should be treated as constraints, not traded away for a lower average processing cost.

Keep the quality standard visible while comparing thresholds. A cheaper workflow that answers more but violates the evidence requirement is not an equivalent alternative.

Improve the next step

A focused clarification can resolve missing input more cheaply than a full escalation. A limited answer can preserve supported information while making the unresolved part clear.

For cases requiring a person, provide the question, relevant evidence and reason the assistant stopped. This reduces repeated investigation and helps route the task to someone who can resolve it.

Monitor repeated refusals on the same topic. They may indicate missing source content that can be fixed once, rather than a permanent need for manual handling on every request.

Evaluate total useful completion

Compare configurations using correct completion, unnecessary refusal, unsupported answers and human effort. Include tasks abandoned after the assistant stopped, because those represent unmet user needs.

Review the tradeoff by task class and update it when sources or capabilities change. A well-designed abstention path contains uncertainty while preserving as much useful progress as possible. Its cost is understood across the whole task, not only the model call that produced the refusal.