A support case, end to end
A problem arrives on whatever channel the customer uses, resolves to a Person, and — when somebody opens one — becomes a case on that relationship. The reply is grounded in the history already attached to them, held or sent according to autonomy, and evidenced by the provider. Resolution writes an outcome that the next case will be answered from.
The stage chain#
- Trigger — a customer says something is wrong, or somebody in the workspace notices that it is.
- External event — the message arrives on a channel: an email into a connected mailbox, a WhatsApp webhook, or a call that produces a transcript and a summary.
- Authentication and workspace resolution — the route resolves the workspace before a single row is read, and the same service answers for the operator and for a customer through two thin routers.
- Ingest — the message is canonicalised onto its thread, so a reply continues the conversation instead of starting a parallel one.
- Canonical record — the sender's address is resolved as an identity to a Person; if no identity matches, a person is created rather than the message being left ownerless. Everything downstream hangs off that record.
- Classification and reasoning — triage decides what this message is. A problem produces a reply, and where somebody opens one, a case is created against the person with the problem stated.
- Knowledge, memory and rules — the relationship is read, not copied: identities, company, stage, timeline, open follow-ups, earlier cases. Grounding is assembled to roughly 2,000 characters and four facts of Knowledge, about 700 characters of memory, about 600 for the contact block. Commercial terms are bounded here.
- Autonomy and approval — the channel's rule decides. Connect sends, or holds the reply in Needs You, or stops and asks a question it may not answer itself.
- Action and provider — the reply goes out through the same send boundary a person's own message uses: the mailbox, the messaging provider or the carrier.
- Result — the provider's acknowledgement decides the outcome. Until it arrives the state is uncertain rather than sent, and nothing is reported as delivered on hope.
- Relationship, timeline and memory — the message, the case and any work recorded against it land on the person's timeline in the order the customer met them. A correction the customer makes can be stored as memory so it changes future answers.
- Audit, usage and Needs You — who decided what is in the audit trail, model and channel usage is metered, and anything still undecided stays in Needs You where it is visible as a debt.
Stage by stage, in the shape an operator needs#
| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| Message arrives | A new conversation, or a new message on an existing thread | A canonical message on a thread | A mailbox that is connected but not healthy delivers nothing; the thread is silent rather than broken |
| Person resolved | The conversation shows a known contact | An identity is linked, or a Person is created | A second record for the same human, if the address is new and nothing else matches |
| Case opened | An open case on the relationship | A record in the cases sheet | Nobody opens one, and the problem lives only as a thread |
| Reply grounded | A draft that refers to real history | Nothing yet — grounding is a read | Thin Knowledge produces a thin answer, or an escalation |
| Autonomy checked | Sent, held in Needs You, or a question | An approval item, if held | Autonomy set to ask everywhere buries real escalations under ordinary ones |
| Sent and evidenced | The message on the timeline | The provider's acknowledgement recorded | An uncertain send: the state stays uncertain until the provider answers |
| Resolved | A closed case with an outcome | The outcome, the closer and the time | Closed with no outcome, which costs the next reader an investigation |
The two places this flow most often goes wrong#
The first is identity. If the customer writes from an address nothing recognises, the case attaches to a second record and is answered without the history that would have made it easy. The symptom is an answer that reads as though nobody was listening; the fix is a merge, which brings identities, stages, follow-ups, deals, demos, cases and onboarding from both records onto the survivor.
The second is the gap between a thread and a case. A problem discussed in an email thread that nobody turned into a case is invisible to every list, count and report that reads cases — it is being handled, and it is not being tracked. No case was opened covers that specifically.
What the customer experiences#
- A held reply is invisible to them. Nothing has been handed to a provider, so there is no message in flight and no evidence of one being written.
- An escalated question is also invisible. The thread simply stays quiet, which is why the age of an item in Needs You matters more than its position.
- A sent reply arrives on the channel they wrote on, from the mailbox or number whose role covers that conversation.
- A resolution is not announced to them by the act of closing. If they should be told the matter is settled, the reply that tells them is the thing that tells them.
Questions#
Does the case have to exist before Connect can reply?
No. Replying and case-keeping are separate. Connect can answer a problem on a thread whether or not a case exists; the case is what makes the problem countable, chaseable and readable later.
Which channel does the reply go out on?
The one the customer used, on the thread they used it on. A case can span channels because it hangs off the person, but each reply continues its own conversation rather than jumping medium.
What if the customer contradicts something Connect said?
Correct the source. A fact fixed in Knowledge or stored as memory changes what every future case is answered from; editing one reply changes one reply.