Business use cases
Connect is one worker across email, WhatsApp, phone and inbound SMS, so a use case here is a shape of work rather than a product tier. Every page in this section names the channels involved, what has to exist before any of it runs, what Connect refuses or cannot do, and where the money actually goes on that shape of work.
What a page in this section has to tell you#
Five questions, in the same order on every page, because those five decide whether a shape of work is possible for a particular business rather than interesting in the abstract.
- The work — what happens, described as a sequence a person could watch.
- The channels — which of email, phone, WhatsApp and SMS take part, and which one the first contact usually arrives on.
- The setup — mailboxes, a number, Knowledge, autonomy, follow-up rules: what must exist before the first message is handled.
- What will not work — the refusals, the provider-dependent gaps and the measured floors. Read this part first if you are deciding.
- Where the cost goes — which part of the shape is expensive and which is close to free.
None of these pages is a claim about a particular business. They describe what Connect does and the honest edges of it; the judgement about whether that fits stays with the person reading.
The shapes, and the channel each leans on#
| Shape of work | First contact usually arrives on | The part people underestimate |
|---|---|---|
| Missed calls | Phone | Reply speed on a live call has a measured floor |
| After-hours enquiries | Phone and email | What waits for the morning has to be a follow-up with a reason, not a memory |
| Inbound lead response | Half the answer is safe to send at once and half is not | |
| Outbound prospecting | Email, outbound | Refusing to guess an address costs volume on purpose |
| Quote follow-up | Email and phone | Connect does not restate a price Knowledge cannot support |
| High-volume inbox | The daily allowance holds work rather than dropping it | |
| Support continuity | Any channel | Continuity is an identity problem before it is a memory problem |
Six limits that decide more use cases than any feature#
- Outbound SMS
- Provider-dependent, and the carrier on the live account carries none at all.
readiness.messagingsays so on the Phone screen rather than presenting a thread that cannot send. A shape of work whose whole point is a text message needs a provider that carries SMS, and in India needs DLT registration as well. - Call recording
- Foundation. The capability is asked of the provider rather than assumed, and it is not enabled on the live carrier. A use case that depends on replaying the audio cannot be built on it today; the transcript and the summary are what exist.
- A completed human transfer
- Foundation. An escalation phrase queues a transfer and the supervisor panel can act on a live call, but the finished warm hand-over depends on a provider capability that is not enabled.
- Reply speed on a live call
- The floor on the realtime path is the model first token plus its end-of-turn detection: 3.3 s median on the best measured call, not one or two seconds.
- A guessed email address
- Never produced, tested or sent to. A prospect with no discoverable address stays a researched prospect with a different next action.
- An invented commercial term
safe_salesrefuses a price, an SLA or a warranty that Knowledge does not support, and escalates to a person. The refusal is the designed behaviour, not a gap.
Where the cost actually goes#
Voice dominates. A live call is priced on audio tokens, which are metered at several times the rate of text, and a call runs until somebody hangs up or the thirty-minute ceiling stops it. Two four-minute calls cost more than a day of email on most workspaces.
Research is the second place. Prospecting routes its spend (prospect_cost_router.py) so a deeper pass runs only where it can change a decision, which is why a hundred shallow prospects and ten researched ones are not the same purchase.
Email and WhatsApp replies are the cheap part. What bounds them is the workspace daily allowance rather than the model: when it is spent, work is held rather than dropped and the read cursor deliberately does not advance, so nothing is lost while the ledger resets.
Everything in this section#
39 pages, each with its own status and the date it was last checked against the running system.
| Page | What it covers |
|---|---|
| A B2B sales team | A sales team using Connect for pipeline hygiene and follow-through, with the commercial escalation that keeps the agent out of the negotiation. |
| A business whose people are not at a desk | When the people who do the work are on site rather than at a desk: what the phone covers, what the browser covers, and what genuinely cannot be done. |
| A business with a season | Handling a season that is ten times the rest of the year: what you widen, what capacity actually limits you, and the rules that must not move. |
| A business with several locations | Several branches inside one workspace: a line and a mailbox each, branch facts that stay local, and one relationship record the customer never sees split. |
| A clinic or practice | Scheduling-shaped enquiries for a clinic or practice, the privacy questions to settle first, and the clinical work that must never leave a person. |
| A franchise network | A network of independently run branches: one workspace each, what genuinely cannot be pooled across them, and why there is no franchisor console. |
| A high-volume inbox | An inbox with more mail than anyone can read: how work is picked, why the allowance holds rather than drops, and what to automate first. |
| A small organisation with no support desk | Coverage for an organisation where answering enquiries is nobody's actual job, and the decisions that have to stay with a named person anyway. |
| After an event or exhibition | Turning a box of cards from an exhibition into researched, evidenced records and a first message, without a single invented email address. |
| After-hours enquiries | What a caller and an emailer actually get outside working hours, what is held until morning, and the promises Connect must not make at midnight. |
| An agency with several clients | Running several clients from one product: why each client is its own workspace, what isolation actually enforces, and what deliberately cannot be shared. |
| Asking for feedback | Asking customers what they thought: when the request is triggered, which channel can carry it, and why a reply should rarely become Knowledge. |
| Booking appointments | What Connect can agree, confirm and chase around an appointment, why it does not hold your diary, and the read-back rule that keeps a booked time honest. |
| Chasing appointments and commitments | Chasing appointments, call-backs and commitments across channels, with the duplicate, staleness and reason rules that keep the chasing honest. |
| Chasing suppliers | Outbound follow-up aimed at people who owe you something rather than owe you money: what drains automatically, what expires, and what the record proves. |
| Communication you must be able to explain | Work where every message may have to be explained later: what is recorded, what evidence exists, and the certifications this documentation does not claim. |
| Covering a small team's inbox | Covering a shared inbox with a handful of people: mailbox roles, per-mailbox autonomy, and the queue that keeps a human in charge of what goes out. |
| Delivery and order status enquiries | Answering where-is-it questions from records you actually hold, refusing the ones you do not, and why an answer from a sample is worse than no answer. |
| Education and admissions | Admissions-season enquiry volume, families who write in several languages, and the decisions a school must keep out of software entirely. |
| Following up a quotation | Following up a quotation without letting the agent restate the price: the sequence, the refusal rule, and how a commercial question escalates. |
| Handing work between colleagues | Giving a colleague a customer relationship mid-flight: what the record already carries, what does not transfer at all, and who ends up accountable. |
| Handling applicants | Handling applicants at volume: the correspondence Connect takes on, the records it keeps, and the hiring decisions it must never be given. |
| Manufacturing and B2B enquiries | Technical enquiries and requests for quotation: which specification questions can be answered from documents, which are refused, and how the engineer gets involved. |
| Never miss a business call | Answering every inbound call in hours and out: what the caller gets, what still needs a person, and the three limits that shape the whole thing. |
| Operating in India | Operating in India: what DLT registration actually requires, why outbound SMS does not work on the live carrier, and which channels do the job instead. |
| Order and delivery enquiries | Where is my order, and can I change it: answering from real data, refusing what is not known, and the order lookup Connect does not have by default. |
| Outbound prospecting without buying a list | Finding and approaching new organisations from public research rather than a bought list, and the refusals that cap the volume on purpose. |
| Payment reminders | Reminding customers about unpaid invoices: the factual part that automates safely, the regulated part that cannot, and the evidence a dispute will need. |
| Professional services enquiries | Enquiries for advisory and professional work: scoping without committing, reading what the client sends, and the decisions that must stay with a person. |
| Property enquiries | Portal enquiries answered in minutes, qualified in the reply, and turned into a viewing commitment — with the listing-accuracy problem stated plainly. |
| Reaching dormant customers | Reaching customers who have gone quiet: the compliance checks that run first, the evidence that makes a message worth sending, and which channels can carry it. |
| Reseller and partner enquiries | Inbound approaches from would-be resellers and partners: qualifying them with evidence, and the commercial terms that never leave a person. |
| Responding to inbound leads quickly | Answering a new enquiry before it goes cold: what Connect can say straight away, what it refuses, and why a held draft is not a fast reply. |
| Running a business on your own | One person, no colleagues to approve anything: the settings that give the widest cover for the least risk, and where the single-approver problem bites. |
| Serving customers in several languages | Serving customers in more than one language across phone, email and WhatsApp: how the language is chosen, what it costs, and what is not claimed. |
| Software trials and onboarding | Trial and onboarding nudges that are worth receiving: what they can be grounded in, the stop rules, and the product data Connect does not have. |
| Support that remembers the sale | Carrying what was learned during the sale into support: how one person stays one record across channels, and what breaks the thread when it breaks. |
| Trades and installers | Enquiries answered while you are up a ladder: qualifying a job, arranging a visit, and chasing the quote afterwards without ever naming a price. |
| Working with partners and suppliers | Pointing the same machinery at counterparties who are not customers: suppliers, partners and agencies, with the scoping and refusals that differ. |
Questions#
Do these use cases cost different amounts to run?
They differ in what they consume rather than in what they cost to switch on. There is one feature set and both audiences reach it over the same implementation; a customer workspace is bounded by its plan allowances. A phone-led shape of work spends its budget on audio tokens; an inbox-led one spends it against the daily mail allowance.
My business is not on the list. Which page should I read?
Read the nearest shape by *channel*, not by industry. The setup and the limits transfer almost completely between two businesses whose first contact arrives the same way, and barely at all between two in the same trade whose first contact does not.
Can two of these run in one workspace at once?
Yes, and most do. Because autonomy and memory both resolve narrowest-first, a workspace can run outbound prospecting under ask_before_send while inbound support replies autonomously, and still hold every message to one named account for a person to read.