# Responding to inbound leads quickly

A new enquiry is read, triaged and answered on the same tick it arrives, grounded in Knowledge, and the parts nobody may improvise — a price, an SLA, a warranty — are refused and escalated instead of guessed. The thing that decides how fast the customer actually hears back is not the model. It is the autonomy mode on that channel.

- **Status:** Available
- **Audience:** both
- **Channels:** email, whatsapp, phone
- **In the app:** #/inbox, #/needs-you, #/pipeline
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/use-cases/inbound-lead-response/

## What speed means here, and what it does not

Under `autonomous` the reply leaves as soon as it is written. Under `ask_before_send` it is written and held, and the recipient sees nothing at all — a held draft is not a slow reply, it is no reply, and the clock the enquirer is counting keeps running. Under `draft_only` it is written and not even queued for approval. Three modes, three completely different experiences for the same enquiry.

A message is only reported as **sent** once the provider has acknowledged it. There is a third state — **uncertain** — shown as uncertain rather than guessed either way, because re-sending on a maybe is how a new lead receives the same welcome twice.

> **Note** `threads.priority` is read by the engine when it picks work, so correcting the priority on an enquiry changes what happens next rather than just re-sorting a list.

## What is safe to answer at once

| The enquiry asks | Answered immediately? | Why |
|---|---|---|
| What you do, whether you cover an area, how something works | Yes, if Knowledge carries it | Grounded answers only; an ungrounded one is refused |
| A price, a discount, an SLA, a warranty | No | `safe_sales` refuses a commercial term Knowledge cannot support and escalates to a person |
| A delivery or lead-time promise | Only if Knowledge states it | A promise is a commitment; an improvised one is the expensive kind |
| Something about their existing account | Yes, once the identity resolves | One address on one channel resolves to a Person, and their history comes with them |
| A request to stop contacting them | Yes, and it is recorded | Suppression, unsubscribe, complaints and do-not-contact are checked in one place |

The refusal is the designed behaviour, not a gap. A first reply that says what is known, names the one thing that needs a person, and creates a dated follow-up for it beats a fast reply somebody has to walk back.

## What has to exist first

1. Connect the mailbox enquiries arrive on, and give it a role and a signature. Gmail, Microsoft Graph and any IMAP/SMTP server are the options.
   - Result: Each mailbox carries its own autonomy and its own health verdicts, so the enquiry address can behave differently from the accounts one.
2. Put the answers you already repeat into Knowledge — coverage, process, what you do not do.
   - Result: Those become answerable at once. Everything absent becomes a refusal, which is visible in the decision log and is the cheapest list of gaps you will get.
3. Set the channel autonomy deliberately, then narrow it where you must. Scopes resolve narrowest-first: contact, endpoint, channel, workspace.
   - Result: You can run the enquiry mailbox autonomously while holding every message to one sensitive account for a person.
4. Decide what an unanswerable enquiry becomes.
   - Result: A follow-up with a reason and a due time, on email or phone, rather than an item somebody has to remember.

## What goes wrong in the first hour

**Nothing was sent and nothing is in the queue** — The channel is on `draft_only`, which prepares a reply and deliberately does not ask. It looks identical to `ask_before_send` on the conversation screen and is not the same thing.
**The reply is held and the allowance is spent** — The approval is recorded and the send waits. The item stays in the queue until it actually goes; the daily allowance holds work rather than dropping it.
**The reply went to the wrong history** — Two identities for one human. `duplicates` proposes a merge and a person decides it, because merging carries identities, stages, follow-ups, deals, demos, cases and onboarding from both sides.
**The draft is stale by the time it is approved** — The enquirer wrote again while it waited. Regenerating gives the model the newer messages; editing the old draft does not.
**The address is suppressed** — The enquiry came from somebody who previously asked not to be contacted. That is checked before any outreach, the origin is shown, and the Assistant cannot clear a do-not-contact entry at all.

## What this costs to run

Very little on its own. Reading and drafting mail is bounded by the daily allowance rather than by anything per-message you would notice, and the reply itself is text rather than audio. The expensive additions are optional: research on the sender, and a voice call-back.

This corpus carries no measured figure for how long a first reply takes, and inventing one would be worse than saying so. What governs it is the tick the engine works on, the daily allowance, and — dominating both — whether a person has to approve.

## Questions

### How quickly does the enquirer actually get a reply?

Under `autonomous`, as soon as the reply is written and the provider acknowledges it. Under `ask_before_send`, however long it takes a person to open Needs You — and until then the enquirer has received nothing. No measured reply-time figure is recorded here, so treat the autonomy mode as the answer to this question rather than a service level.

### Can Connect qualify the lead as well as answer it?

It can move a person along the lifecycle stages, open an opportunity on the pipeline and record what it learned as memory against the contact. What it does not do is invent the commercial part: value is stored in minor units and set from something real, and a price nobody has approved is escalated.

### What stops it replying to obvious rubbish?

Triage, priority and blocking. A block is a memory row tagged `block:<channel>` against the contact rather than a column on a thread, which is why it holds across channels and across future conversations rather than only the one you were looking at.

## Related

- [Email in Connect](https://connectbyjbrh.com/docs/email/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Sales in Connect](https://connectbyjbrh.com/docs/sales/)
- [Following up a quotation](https://connectbyjbrh.com/docs/use-cases/quote-follow-up/)
- [Knowledge in Connect](https://connectbyjbrh.com/docs/knowledge/)
- [Why uncertainty is a valid answer from a business agent](https://connectbyjbrh.com/research/uncertainty-is-an-answer/)
- [Drafting and sending](https://connectbyjbrh.com/docs/compare/draft-vs-send/)

## What this page is based on

- docs-source/sources/CHANNELS.md §1 — sending, suppression, triage
- docs-source/sources/CHANNELS.md §6 — safe_sales
- docs-source/sources/GENERAL.md §5 — autonomy modes and scopes
- Connect capability registry (docs-source/facts.py)