# Connect and a helpdesk

A helpdesk turns a message into a ticket so a human can be assigned it, measured on it and escalated through it. Connect starts from the opposite end: it drafts the answer, and only what it cannot finish becomes a **Support Case** or an item in **Needs You**. Where a helpdesk is far ahead is anything that depends on a team — routing, workload, service levels and the reporting a manager lives in.

- **Status:** Available
- **Audience:** both
- **In the app:** #/inbox, #/needs-you
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/compare/connect-vs-helpdesk/

## Two different starting assumptions

A helpdesk assumes the work will be done by a person and that the scarce resource is that person's time; everything in it — queues, assignment, priorities, SLA clocks, macros — exists to allocate that time well. Connect assumes the first attempt will be made without a person and that the scarce resource is a person's *attention*, so its queue holds only the things a person must decide.

That is why **Needs You** is ranked rather than chronological, and why entries drain by themselves as their cause clears. A helpdesk queue does not empty on its own, because every row in it is waiting for a human by definition.

## What a helpdesk does better

**Team routing and workload** — Skills-based assignment, round-robin, shift handover, holiday cover and per-agent load are a helpdesk's core competence.
**Service levels** — First-response and resolution clocks per contract, with breach alerting, pausing and reporting. Connect measures nothing of the kind.
**Manager reporting** — Volume by queue, backlog age, reopen rate, agent throughput and CSAT are the reason helpdesks are bought.
**Self-service** — A public knowledge base, a customer portal with ticket history, and community forums.
**Collaboration inside a ticket** — Internal notes, @mentions, side conversations with a supplier, and a clean handover trail between agents.
**Customer satisfaction measurement** — Survey mechanics wired into resolution.

A support organisation of any size needs most of that list, and none of it is on Connect's roadmap in this documentation.

## What Connect does instead

- **Answers first.** The reply is drafted against the thread, Knowledge and memory before anything is queued; under `ask_before_send` a person approves it, under `autonomous` it goes.
- **Keeps the sale attached to the support.** A **Support Case** hangs off the same **Person** as the deal, the calls and the follow-ups, so the answer knows what was bought.
- **Works every channel the same way.** A WhatsApp message and a phone call become the same canonical conversation record; there is no email-only assumption.
- **Holds rather than drops.** When the daily allowance is spent, work is held and the read cursor deliberately does not advance, so nothing is lost while the queue waits.
- **Logs the decision, not just the outcome.** Including refusals — a refusal is a decision.

## The two shapes side by side

| Stage | Helpdesk | Connect |
|---|---|---|
| Message arrives | Becomes a ticket, enters a queue | Becomes a canonical thread; the engine picks work by `threads.priority` |
| First response | An agent picks it up; the SLA clock runs | A reply is drafted; autonomy decides whether it goes or waits |
| Needs a human | Always, by design | Only when the rule says so, the answer is unsupported, or something failed |
| Cannot be finished | Stays open, escalates by priority | Becomes a **Support Case** with the relationship attached |
| Closing | An agent resolves and the survey fires | The case is resolved; the outcome and the decision are in the audit trail |

> **Note** Running both is normal. The usual boundary is that Connect works the front door — the shared inbox, the WhatsApp number, the phone line — and anything it cannot finish is raised as a case for the team that lives in the helpdesk.

## How this goes wrong

**Expecting SLA reporting** — There is none. If you are contractually measured on first response, keep the tool that measures it.
**Treating Needs You as a ticket queue** — It is not a backlog to burn down; items appear because a decision is owed and disappear when the cause clears. Assigning them like tickets fights the design.
**Two systems mailing the same customer** — If the helpdesk also replies from the same address, the customer gets two answers. Give each system its own mailbox or its own channel.
**Assuming case status flows outward** — A case resolved in Connect is resolved in Connect. Nothing pushes that to another system unless you build it on the public API.

## Questions

### Can Connect replace a helpdesk for a small team?

For a team small enough that assignment is obvious and nobody reports on SLAs, often yes — cases, onboarding, the timeline and the follow-up queue cover the mechanics. The moment you need to route work between people and measure them on it, you want a helpdesk.

### Does Connect have ticket numbers?

It has Support Cases with stable identifiers, opened and resolved through `journey`, and every record has a stable id you can quote. What it does not have is the ticket as an organisational unit — the thing agents are assigned, measured and escalated on.

### What happens to a case Connect cannot answer?

It is escalated rather than improvised. Anything commercial that Knowledge does not support — a price, an SLA, a warranty term — is refused and put in front of a person, and the refusal itself is recorded. See [safe sales](/docs/sales/safe-sales/).

## Related

- [Support cases](https://connectbyjbrh.com/docs/support/cases/)
- [Needs You](https://connectbyjbrh.com/docs/autonomy/needs-you/)
- [Comparisons and concepts](https://connectbyjbrh.com/docs/compare/)
- [Support in Connect](https://connectbyjbrh.com/docs/support/)
- [Connect and a call centre](https://connectbyjbrh.com/docs/compare/connect-vs-call-centre/)
- [Price, SLA and warranty: what Connect may say](https://connectbyjbrh.com/docs/sales/safe-sales/)

## What this page is based on

- `docs-source/sources/GENERAL.md` §5 — Needs You and the audit trail
- `docs-source/sources/CHANNELS.md` §1 — held work and the read cursor
- `docs-source/sources/CHANNELS.md` §5–§7 — cases, journey, follow-ups
- Connect capability registry (docs-source/facts.py)