Every agency has put a chat bubble on a client's site and then watched what happens to it. The client is a six-person firm. Nobody is assigned to the inbox. A visitor types "do you do Saturday appointments?" at 21:40, gets "an agent will be with you shortly", and leaves. On Monday somebody notices the queue. That is the scene I kept coming back to when we built Support, the chat widget inside SharpOS. This series walks our workspace one surface at a time; this part is about the row on our ledger that stands in for Intercom and Zendesk, and about the feature we deliberately left out. TL;DR: Support answers from a knowledge base the client controls, cites what it used, and says plainly when it can't help. There is no human handoff, on purpose. What a helpdesk is for, and where it strains Intercom and Zendesk are built around a team: seats, queues, assignment, a shared inbox across email, chat and social. If you have people whose job is answering, that shape is right. An AI layer deflects the repetitive questions and the humans take the rest. The businesses we work with have no "rest". The owner is the support team, and the owner is also the sales team, the operations team and the person who signs the invoices. Give them a shared inbox and the bubble on their site becomes a promise the business can't keep. The handoff is the feature everyone lists first and nobody staffs. I want to be precise about that: it's a statement about a buyer, not about the tools. A team with an inbox rota should keep its helpdesk. What Support does instead Support is a chat bubble the client embeds on any site with one script tag. Visitors ask, an assistant answers from the organisation's knowledge base, and every reply cites the entries it used. When the knowledge base can't back an answer, the assistant doesn't improvise; it shows a fallback message the client wrote, with their WhatsApp, email or phone appended. The unanswered question is filed as a suggestion in the hub, where it becomes a knowledge entry in one click. Conversations land in a read-only inbox in the workspace with an AI title, a summary and the visitor's mood. Clients without a site to embed on get a hosted help page instead, and the widget ships its UI in seven European locales while the assistant replies in whatever language the visitor writes. The knowledge base is one table: authored Q&A, plus one row per item a connected source contributes. Sources can be a Page, a URL, or a Board column. That last one matters for us — a client's Blog board, Published column, becomes part of what the assistant knows, one document per card, kept in sync as cards are edited, moved or archived. You can poke at the inbox in the showcase workspace, fixtures only, nothing leaves your browser. The feature page has the walkthrough. Inside the organisation it follows the rules every SharpOS surface follows. The Support feature flag is off by default and enforced server-side. Editors read the inbox, managers configure the assistant. Once the Analytics flag is on too, Analytics gains a Support tab, read from daily rollups rather than by scanning conversations. How it works The install is the boring part, and boring is the point: one script tag on the client's site, carrying the widget's id, and the bubble is live. The script mounts the chat in a frame served from our domain, so the widget's styles never collide with the host page's, and the host page opens no live connection until the visitor actually opens the chat. The script also gives the host page a small set of controls, open the widget, send a message, say who the visitor is, listen for a reply, and it only accepts those commands from the page that embedded it, and only posts visitor text back to that same page. Two thresholds decide what the assistant is allowed to say. Each published Q&A is indexed twice: once as the question alone, so an exact question scores near 100%, and once as the full Q&A context. A match at or above the answer threshold (70% by default) grounds the reply. A best match below the capture threshold (60% by default) triggers the fallback and records the question as a suggestion for the knowledge base. Between the two it falls back quietly. The two dials are set per organisation, and the pair is ordered by construction, so no score can both answer and file a gap. The part I'd defend hardest is the read-side check. A Page or a Board card can be archived, made internal, or deleted after it was embedded, and the search index is a derived copy that none of those paths write to. So before any source match can ground a public reply, the live page, board, column and card are re-checked, and a match that can't be proven serveable is dropped, including when the check itself fails. The widget degrades to the fallback rather than answering from a copy it can't verify. The rest is the guardrails an unstaffed bubble needs. Visitor sessions are bound to the site that embedded the widget with a short-lived token and a domain allow-list. A visitor gets 8 messages a minute and 200 a conversation. An optional daily budget swaps every model call for a "high demand" message when it runs out. It all runs on the client's own OpenAI or OpenRouter key, held in their organisation, and the inbox shows an estimated cost per conversation. We don't sit between the client and their model bill. What it doesn't do It won't hand a conversation to a person. There is no agent seat, no queue, no "someone will be with you". If a customer's question needs judgement (a refund, a dispute, a change to an account), the assistant's job is to say so and give the contact channel, and the client's job is to answer that email the way they would have anyway. It isn't a multichannel inbox; email, social DMs and phone don't flow into it. And it won't answer outside the knowledge base, which means an empty knowledge base produces a polite bot that mostly says "get in touch". That's correct behaviour until the base is filled, and we fill it from the Pages and Boards the engagement already produces. If you have a support team, or your product generates conversations that genuinely need a human in the loop, keep Zendesk or Intercom. This row of the ledger is for the business that never had a support team and shouldn't pretend to. Where it sits in the service Support ships as part of SharpHaw's AI Automations work: the knowledge base is built from the client's own pages and boards, automations react to events such as conversation started and visitor identified, and captured questions feed back into the content we write next. It's included in the SharpOS workspace every subscription runs in. The question I'd like answered If you've shipped an AI-only support surface, where did you draw the "I can't help with that" line, and did your visitors respect it? I'm especially curious whether anyone has numbers on abandonment after a fallback message versus after a queue. This is part of SharpOS, surface by surface. Part 1, on the whole ledger: We replaced a 12-tool client stack with one workspace we built.