# Handling a request Connect cannot fulfil

Connect refuses rather than improvises. A price, a delivery commitment, a warranty or a service level that the workspace's own knowledge does not support is not invented — the request is declined in the conversation, escalated to a person, and recorded as a decision. The refusal is the designed behaviour, not a gap in coverage.

- **Status:** Available
- **Audience:** both
- **In the app:** #/needs-you, #/knowledge, #/follow-ups
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/out-of-scope-request/

## What counts as out of scope

- Commercial terms the workspace has not supplied: a price, a discount, a payment term, a warranty, a service level, a delivery date treated as a commitment.
- A factual claim about the business that no knowledge source supports — the answer would have to be produced rather than grounded.
- An action the workspace's rules do not permit on that channel, or for that contact.
- Anything requiring authority the requester has not established, such as changing details on somebody else's account.
- A request that is legitimate but simply belongs to a person: a negotiation, a complaint about a person, a decision with consequences the business has not delegated.

The distinguishing question is not whether Connect could produce plausible words. It is whether the answer would be grounded in something the business actually said. Uncertainty is a valid answer from a business agent; a confident invention is not.

## Recognition to escalation, stage by stage

1. Trigger — a customer asks for something the workspace has not authorised an answer to.
2. User event — the request arrives in an ordinary conversation. There is no special channel for a hard question.
3. Authentication and workspace resolution — already established by the conversation; the refusal rules are the workspace's own, not a global default.
4. Ingest — the message or the spoken turn is on the record before any decision, so both the request and the refusal are auditable.
5. Classification — the request is matched against what knowledge supports. A commercial term with no grounding is the clearest case and the one most tightly enforced.
6. Knowledge, memory and rules — knowledge decides what may be asserted; standing instructions can widen or narrow it; memory can carry a contact-specific direction.
7. Autonomy and approval — a refusal is a decision in its own right, and is recorded as one. It is not an error and is not retried.
8. Action — the reply says what can be answered, declines what cannot, and says a person will follow up. It does not guess, and it does not promise a time nobody agreed.
9. Escalation — the request is queued for a person, with the conversation attached rather than summarised away.
10. Result — the customer has an honest answer now and a named next step, instead of an invented one they may act on.
11. Relationship, timeline and memory — the exchange lands on the person; a recurring refusal is a signal that a knowledge source is missing.
12. Audit, usage and Needs You — the refusal, its reason and the rule that produced it are all in the decision record.

## What the customer is told

1. Answer the part that can be answered.
   - Result: A refusal that swallows the whole message reads as evasion; most out-of-scope requests are one hard question inside three ordinary ones.
2. Say plainly that the rest needs a person, without inventing a reason.
   - Result: The customer knows the request landed and is not left guessing whether it was understood.
3. Commit only to what is actually scheduled.
   - Result: A follow-up exists as a dated record with a reason attached, so the commitment survives the conversation that created it.
4. Leave the specifics to the person who has authority for them.
   - Result: The person picks up a conversation with nothing to unwind, which is much faster than correcting a number that should never have been said.

> **Note** On the realtime voice path this rule lives in the model's instructions rather than in a gate that can stop a sentence mid-flight, so a breach is *detected* rather than prevented. Lines that priced something are counted, through the same expression the carrier path checks with, so both paths agree on what a price is.

## Where the request goes next

**Needs You** — The queue of decisions and problems for a person, ranked rather than chronological. An escalated request appears with the conversation it came from.
**A follow-up on the task channel** — Work for a person to do. No drain ever sends a task, so it cannot quietly turn into a message; it shows as work for a person and waits to be completed.
**The knowledge gap** — A refusal that keeps recurring for the same question is a missing knowledge source. Adding it turns a repeated escalation into an answer.
**The decision log** — Every refusal with its reason. This is what makes the pattern visible over a month rather than felt as an impression.

## Why refusing is the correct outcome

An invented commercial term is not a small error. It is a statement a customer can reasonably rely on, made by something that speaks in the business's name, and the business is left choosing between honouring it and retracting it. Both are more expensive than a delay.

The Assistant inside the application is held to the same line for the same reason: it has narrower rights than a person, cannot quote pricing the workspace has not supplied, and cannot clear a do-not-contact entry at all. Rights that stop at the boundary of what has been authorised are what make delegation safe.

## Questions

### Can Connect be told to answer pricing questions?

It can answer from what the workspace has supplied. Put the prices, terms and conditions into knowledge and the answers become grounded rather than invented — which is the actual requirement. What it does not do is produce a number that no source supports, however clearly a customer asks for one.

### Does a refusal look like a failure in the reporting?

No. Refusals are recorded as decisions, because a refusal is a decision. Counting them as errors would create pressure to reduce the count, and the only way to reduce it without adding knowledge is to start guessing.

### What if the customer insists?

The answer does not change with repetition, and it should not. What changes is urgency: a customer pressing on the same point is a stronger signal to the person holding the escalation, and that is visible in the queue.

## Related

- [Escalating a complaint, end to end](https://connectbyjbrh.com/docs/workflows/complaint-escalation/)
- [Knowledge in Connect](https://connectbyjbrh.com/docs/knowledge/)
- [Why a sales agent should refuse to answer](https://connectbyjbrh.com/research/safe-refusals-in-sales/)
- [Why uncertainty is a valid answer from a business agent](https://connectbyjbrh.com/research/uncertainty-is-an-answer/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Follow-ups in Connect](https://connectbyjbrh.com/docs/follow-ups/)

## What this page is based on

- Connect source pack §6 — `safe_sales` refuses invented commercial terms; the voice path detects rather than prevents (`docs-source/sources/CHANNELS.md`)
- Connect source pack §8 — the Assistant's rights are narrower than a person's (`docs-source/sources/GENERAL.md`)
- Connect source pack §7 — follow-ups, the task channel and the reason a commitment carries one (`docs-source/sources/CHANNELS.md`)