# Connect and a chatbot

A chatbot is bounded by one conversation on one surface, usually a website widget. Connect is bounded by a workspace: it reads email, WhatsApp, SMS and phone, resolves the sender to a person it already knows, decides under an autonomy rule what it may do, and records the decision. A chatbot that is well built and narrow will still beat it on one thing — instant, cheap answers to the same twenty questions.

- **Status:** Available
- **Audience:** both
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/compare/connect-vs-chatbot/

## Four differences that actually matter

|  | A chatbot | Connect |
|---|---|---|
| Scope | One surface, usually one language of interaction, one session | Email, WhatsApp, SMS, phone and the softphone, over one canonical record of the person |
| Memory | The session, sometimes a stored transcript | Four tiers — workspace, channel, endpoint, contact — resolved narrowest-first and readable and editable by a person |
| Actions | Usually answers; sometimes hands off to a form or a human | Sends replies, opens opportunities and cases, books follow-ups on any channel, creates and modifies files, places calls |
| Accountability | A transcript | A decision log naming what was decided, under which rule, by what, and what happened — refusals included |

The row that surprises people is the third one. The difference between answering and acting is not a bigger model; it is that every action goes through the service that owns the record, under a permission check, with the result written down.

## What a good chatbot does better

- **Immediacy on a web page.** A widget replies in the same second, in the browser, with no channel to resolve and no mailbox to sync.
- **Cost per answer.** Twenty repeated questions answered from a scripted tree cost close to nothing.
- **Determinism.** A scripted flow does exactly the same thing every time, which is the right property for a returns policy or an opening-hours answer.
- **Containment.** A chatbot that cannot do anything cannot do anything wrong. That is a real safety property, and it is why narrow bots survive in regulated front doors.
- **Website conversion tooling.** Proactive prompts, page targeting and A/B testing on the widget are a discipline of their own.

If the job is *answer the same question on the pricing page faster*, a widget is the better tool and Connect is not a widget.

## Where a chatbot runs out

It runs out at the point the conversation leaves the page. Somebody asks a question in the widget on Monday, emails on Tuesday and rings on Thursday; three sessions, three transcripts, no shared person. Connect resolves all three to one **Person** through their **Identities**, so the reply on Thursday knows about Monday.

It also runs out at commitment. A chatbot can say somebody will call you back; nothing in it makes that call happen. In Connect a commitment is a **follow-up** with a reason, a due time and a channel, and the phone drain rings it — or closes it as missed rather than ringing a day late, because a very late call-back is worse than none.

> **Note** Connect has an in-app conversational surface of its own, the [Connect Assistant](/docs/assistant/), and it is deliberately not a customer-facing chatbot: it is the workspace's own staff talking to their own records, with narrower rights than the person using it.

## Running both

1. Keep the widget for the top of the funnel: hours, stock, delivery windows, the answers that never change.
   - Result: Cheap answers stay cheap and nothing leaves the page unnecessarily.
2. Hand off anything that needs a person, a price or a history — into email or WhatsApp, not into a second bot.
   - Result: The handoff lands on a channel Connect works, and the person is resolved to their existing record.
3. Put the answers the widget uses into Knowledge as well.
   - Result: Both surfaces answer from the same written source, so the widget and the emailed reply do not contradict each other.

> **Careful** Do not point a customer-facing widget at Connect and expect the safety of a scripted tree. Connect refuses to invent commercial terms, but it is a worker with actions, not a containment device.

## Questions

### Is Connect just a chatbot with more integrations?

The integrations are not the difference. The difference is the canonical record: one person, their identities across channels, their memory tiers, their commitments and a log of what was decided about them. Bolting channels onto a session-shaped tool does not produce that.

### Can Connect answer on my website?

Website enquiries addressed to JBRH are handled at platform level and sit outside every workspace by design. For your own site, the ordinary route is that the form or widget sends mail to a mailbox Connect works — the enquiry then behaves like any other inbound message.

### Which is safer?

A narrow scripted bot, on any single measure of blast radius, because it cannot act. Connect's answer to that is not to claim equal containment but to make the boundary explicit: autonomy modes per channel, approvals for anything held, and a decision log that records refusals as well as actions.

## Related

- [Connect Assistant](https://connectbyjbrh.com/docs/assistant/)
- [The four memory tiers](https://connectbyjbrh.com/docs/memory/tiers/)
- [Comparisons and concepts](https://connectbyjbrh.com/docs/compare/)
- [Agent and assistant](https://connectbyjbrh.com/docs/compare/agent-vs-assistant/)
- [One person across phone, email and WhatsApp](https://connectbyjbrh.com/docs/relationships/cross-channel-identity/)
- [The four autonomy modes](https://connectbyjbrh.com/docs/autonomy/modes/)

## What this page is based on

- `docs-source/sources/GENERAL.md` §5–§7 — autonomy, memory, follow-ups
- `docs-source/sources/GENERAL.md` §8 — the Assistant and its rights
- `docs-source/sources/CHANNELS.md` §5 — person and identity
- Connect capability registry (docs-source/facts.py)