# Property enquiries

Property enquiries are won on the first reply and lost in the gap between one portal alert and somebody getting back to their desk. Connect closes that gap on email, WhatsApp and phone, asks the qualifying questions in the same message, and books the viewing as a dated follow-up. It answers only from the listing information you supply, which is where the real risk sits.

- **Status:** Available
- **Audience:** both
- **Channels:** email, phone, whatsapp
- **In the app:** #/inbox, #/relationships, #/follow-ups
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/use-cases/real-estate/

## Speed, and what it is actually made of

There is no queue-jumping trick here. Mail is fetched, canonicalised into threads and messages, and the engine picks work using `threads.priority` — which means correcting a priority changes what gets handled next rather than just re-sorting a list you are looking at. On a channel set to `autonomous`, the reply goes out under the ordinary send boundary; on `ask_before_send` it waits in Needs You, which for portal leads is usually the wrong trade.

> **Note** A held draft is not a slow reply, it is no reply. The clock the enquirer is counting keeps running while it waits, and on a portal lead they are counting it against three other agents.

## Qualifying without advising

The qualifying questions are the safe part of this trade and Connect can ask all of them: what they are looking for, the area, the timing, whether there is a property to sell, whether they have spoken to anyone about finance. Asking is not advising, and the answers land on the Person rather than in a separate form.

- **One person, several identities.** A portal enquiry arrives from a forwarding address, the same person then rings from a mobile and later writes from work. Identity resolution attaches all three to one Person, so the third conversation knows about the first.
- **Customer 360 and the timeline** carry the history into every subsequent contact, which is what stops the fourth conversation asking the same three questions.
- **Memory at the contact tier** holds the durable preferences — no ground floor, must have parking — so they apply to the next property as well as this one.
- **A follow-up with a reason** carries the viewing, the call-back, or the promise to send something. `task` carries anything a person must do.

## The listing-accuracy problem, stated plainly

Connect answers from Knowledge — the sources a workspace supplies. There is no property-database integration in the capability registry, so if your listings reach Connect as an uploaded document or a set of facts, then a property that went under offer this morning is still available as far as Connect knows until the source changes. It will answer confidently, because it is answering from a source, and the source is wrong.

| Question | Grounded in | Failure to plan for |
|---|---|---|
| Is it still available | Whatever you last supplied | Sold or withdrawn since; there is no live feed to correct it |
| What is the asking price | Knowledge, if it is written down | A reduction not yet reflected in the source |
| Can I view on Saturday | The hours on the line and your diary | Connect has no calendar; double-booking is still yours to prevent |
| What is the service charge | Knowledge, or refused | Refused rather than estimated — `safe_sales` blocks unsupported terms |
| Will they accept an offer of X | Nothing | Refused and escalated. Not a question software should be answering |

Two ways to live with this. Keep the Knowledge source narrow and current — facts that change weekly rather than a prospectus that changes hourly — or instruct Connect to treat availability as something to confirm rather than assert. Source conflicts are surfaced rather than silently resolved, so two documents disagreeing about a price is visible.

## What must stay with an agent

**Negotiation** — Any movement on price, terms or conditions. `safe_sales` refuses commercial terms Knowledge does not support and escalates them, which is the behaviour you want on the one conversation where a stray sentence is expensive.
**Anything that resembles financial or legal advice** — Not grounded, not refusable safely by tone alone. Scope those contacts to `ask_before_send` so a person sees them.
**Accepting or relaying an offer** — A message that reads as acceptance is a problem even when it was not meant as one. Keep offers on a human path.
**Removing somebody from contact** — A person clears a do-not-contact entry, recorded against their name. The Assistant cannot clear one at all.

> **Careful** Viewing confirmations by SMS do not work on the live carrier, which carries no SMS. WhatsApp is the practical substitute where the provider's session window allows an outbound message; email always works.

## Where the money goes

Volume is email and it is cheap per enquiry — one model call, grounded, with the daily allowance as the ceiling rather than a speed limit. The expensive part is voice: audio tokens at four times the text input rate, a session re-billed for its whole context every turn, and a duration charge even on a call that reports no tokens. An agency that answers portal leads in writing and reserves calls for qualified viewers spends a fraction of one that rings everybody.

## Questions

### Will it tell someone a property is available when it has just sold?

Yes, if that is what your Knowledge still says. There is no listing-feed integration, so the source is only as current as you keep it. The two safe patterns are a narrow, frequently updated set of facts, or a standing instruction that availability is always confirmed by a person rather than asserted in a first reply.

### Can it handle the same buyer across email, WhatsApp and phone?

Yes — that is what identities are for. One Person holds many identities, one per address or number, so the phone call knows about the portal enquiry. Where two records do end up for one human, duplicates are proposed and the merge is a human decision that preserves both sides.

### Can it negotiate on the vendor's behalf?

No. Commercial terms that Knowledge does not support are refused and escalated, and on a negotiation there is rarely a source to support anything. Treat that refusal as the feature: an agency's exposure on a stray sentence about price is larger than the time saved by automating the sentence.

## Related

- [When two sources disagree](https://connectbyjbrh.com/docs/knowledge/source-conflict/)
- [One person across phone, email and WhatsApp](https://connectbyjbrh.com/docs/relationships/cross-channel-identity/)
- [Held drafts](https://connectbyjbrh.com/docs/email/held-drafts/)
- [Responding to inbound leads quickly](https://connectbyjbrh.com/docs/use-cases/inbound-lead-response/)
- [Price, SLA and warranty: what Connect may say](https://connectbyjbrh.com/docs/sales/safe-sales/)
- [Claims Knowledge does not support](https://connectbyjbrh.com/docs/knowledge/unsupported-claims/)

## What this page is based on

- docs-source/sources/CHANNELS.md §1 and §5 — triage, identities, relationships
- docs-source/sources/GENERAL.md §3 and §5 — the record model and autonomy
- docs-source/sources/CHANNELS.md §6 — safe_sales
- Connect capability registry (docs-source/facts.py)