# Ask Connect about a customer

Ask the Connect Assistant from the customer's own record rather than from a blank screen, because the record is what the answer is grounded in. Start with the whole history, then narrow: what was promised, what is open, what was refused, what to do next. Each of those maps to a different tool and a different set of records.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/inbox
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/ask-connect-about-a-customer/

## Ask from the record, not from nowhere

The Assistant is given the context of the screen you are on, and that context is checked against the database before it is trusted. Asking from the person's record therefore starts the answer from the right identity, which matters more than the wording of the question — one human can hold several identities across phone, email and WhatsApp, and a question asked from a blank screen has to resolve that from a name.

If you must start from a name, expect the first answer to include which person it resolved to. Read that line before the rest. A confident summary of the wrong customer is the only failure mode here that wastes real time.

## The order that gets the most out of it

1. **The whole picture first.** Ask for this customer's history across every channel. That is the Customer 360 view, assembled from the timeline rather than from one inbox.
2. **Then what was promised.** Ask what commitments are open. Every follow-up carries a reason, so the answer says why each one exists rather than just when it is due.
3. **Then what is stuck.** Ask what is waiting on a person. Held replies, approvals and operational problems for this customer all surface in Needs You.
4. **Then what was refused.** Ask whether Connect declined to answer anything. A refusal is recorded as a decision, and a refused commercial question usually means Knowledge is missing something.
5. **Then what to do next.** Ask for the next best action, and ask what it is based on. An action without evidence behind it is a suggestion; one with evidence is a decision you can defend.

## Telling an answer from a guess

| What you see | What it means |
|---|---|
| A cited record, thread or call | The answer came from a record the Assistant read. Open it if it matters. |
| An explicit uncertainty | The Assistant could not settle the question. That is a valid answer here rather than a failure — a confident guess would be worse. |
| A refusal on a commercial question | Knowledge does not support the figure. It is escalated to a person by design. |
| A summary with no citation | Read it as orientation, not as evidence, and ask which record it came from. |
| A conflict between two sources | Both are shown rather than one being silently preferred. The conflict is the finding. |

> **Note** The Assistant's authority is narrower than yours. It cannot set pricing and it cannot clear a do-not-contact entry, so an answer of the form 'a person has to do this' is the boundary working rather than a limit to argue with.

## Questions that reliably pay off

- What has changed about this customer since the last time somebody looked?
- Which of the open commitments has no channel that can actually carry it — a phone follow-up on a line that is off, for instance?
- What did the last call actually conclude, as opposed to what the transcript says was said?
- Is there a support case open under a different identity for the same person?
- What do we know about this customer that came from memory rather than from a record, and at which tier?

That last one is worth asking before any important conversation. Memory resolves at four tiers and the narrowest wins, so a note set against this one contact quietly outranks everything set for the workspace — and it is the layer nobody remembers setting.

## Questions

### Can I ask about a customer without opening their record?

Yes. The Assistant searches across records, and each tab keeps its own conversation and its own record in view, so you can hold one customer in one tab while working in another. Starting from the record is simply more accurate.

### Will asking about a customer change anything?

Reading does not. The read-only tools search, summarise and recall; the writing ones create follow-ups, send, approve or record memory, and those are visible as actions rather than happening inside an answer.

### Why does it sometimes answer about a different person with the same name?

Because two identities resolved to two people. Merging is a human decision — duplicates are proposed, never merged automatically — so the fix is to review the proposed duplicate and merge it, after which the history is one story.

## Related

- [Connect Assistant](https://connectbyjbrh.com/docs/assistant/)
- [Customer 360](https://connectbyjbrh.com/docs/relationships/customer-360/)
- [When the Assistant is not sure](https://connectbyjbrh.com/docs/assistant/uncertainty/)
- [Where an answer came from](https://connectbyjbrh.com/docs/assistant/evidence-and-citation/)
- [Check what Connect knows about a person](https://connectbyjbrh.com/docs/how-to/check-what-connect-knows/)
- [Duplicate detection](https://connectbyjbrh.com/docs/relationships/duplicates/)

## What this page is based on

- Connect source pack: overview (docs-source/sources/GENERAL.md §8 — the Assistant)
- Connect source pack: channels (docs-source/sources/CHANNELS.md §5 — relationships and CRM)
- Connect capability registry (docs-source/facts.py — assistant, customer_360)
