Multi-Channel AI Customer Care Inbox

Customer care has a volume problem and a trust problem. Volume is what makes teams drown. Trust is what stops them shipping any AI fix that touches the customer directly. The naive answer, drop a chatbot on the website, solves the first by creating a worse version of the second. This platform solves both by refusing to put the AI in the sender's seat.

What it is. A unified customer care inbox that pulls conversations into one workflow for the human team. Each incoming message arrives with an AI-drafted reply already prepared, anchored to the conversation history, the customer's profile, and the operation's policy. The human reads, edits if needed, and presses send. The reply goes out under their name, from their channel, never under the AI's name, never directly to the customer. Email is the live channel today; the system is built channel-neutral, so social DMs and the public comments under the operation's posts plug in behind the same brain as they come online.

The two tiers. The AI tier handles what machines do well: pulling channel context, summarising history, drafting a reply in the right tone in the right language, and flagging anything that should not be answered without human judgement. The human tier owns the send button, every escalation, every edge case, and every decision that carries real-world consequence. The boundary is not negotiable. It does not move with prompt cleverness or model upgrades.

Grounded in the operation's own knowledge base. The AI tier doesn't answer from training data alone. Every draft is built from the operation's own internal knowledge base, its services, policies, procedure handbooks, FAQs, escalation paths, and the answers it has already standardised, indexed for semantic retrieval and pulled in at draft time. What the AI proposes is what the operation has already decided, surfaced in the right place at the right moment in the right tone for the right channel. The model is not improvising; it is finding the right paragraph in the right document and putting it in front of the agent. That is what makes the drafts pass review, and what keeps the platform on-message as the operation's knowledge base grows. Each draft carries the sources it drew from, so the agent reviewing it can see exactly which documents stand behind the answer, not a black box.

Guardrails in code, not prompts. The safety boundary is enforced in code, not in the prompt. Every message runs through a fixed pipeline, and a policy gate sits early in it, before the model is ever asked to draft. Anything that touches the operation's restricted territory, regulated medical content, personal data, professional-advice questions, complaints, formal escalations, is intercepted at that gate and routed to the right human team, with the reason attached, before a machine answer is ever generated. Messages that clear the gate get a draft, and that draft then passes a second code-level check that strips anything resembling a prohibited recommendation before a human ever sees it. Prompts drift. Models change behaviour between versions. Code-level rules survive both. For a consumer-health operation, that distinction is the entire reason the system is allowed to ship.

The agent dashboard. The care team works inside an embedded panel on top of an open-source helpdesk core. Each conversation shows the AI's draft, the source documents it drew from, a confidence rating, the escalation flags it raised, and the customer history that informed it. The agent can accept, edit, regenerate it shorter or warmer or translated, reject, or hand off, and the interface adds friction where it matters: a low-confidence draft asks the agent to confirm they have reviewed it; a draft that touches sensitive territory requires an explicit attestation before it can be sent. Supervisors see a separate dashboard, throughput, review latency, how heavily agents are editing the drafts, escalation reasons, and where the knowledge base has gaps. Quality is not assumed; it is measured, and the gaps feed straight back into what the knowledge base needs next.

Channels are adapters, not the system. Each channel has its own adapter, wire format, authentication, attachment handling, rate limiting, public-vs-private visibility, but the orchestration, the retrieval, the drafting, the guardrails, and the inbox itself are channel-neutral. Email runs in production today. The next channels are social DMs and the public comments under the operation's posts, and a private DM and a public comment are handled by the same brain, with the visibility difference routed to the policy layer. Adding a channel is a new adapter, not a new system, and what gates the next one is third-party platform review and the operation's own risk sign-off, not engineering effort. That is a deliberate posture: ship the channel you can stand behind first, and make expansion configuration rather than rebuild.

Why it works for a consumer-health operation. The human stays in the sender's seat. Drafts are grounded in the operation's own knowledge base, not the model's general priors. The boundaries are written in code rather than prompt, and the riskiest messages never reach a machine draft at all. Every action is auditable from intake to outbox. And the whole stack runs in EU-region cloud, so customer data stays inside the operation's own regulatory boundary. The team gets the throughput uplift; the institution keeps its risk posture.

Customer care AI usually launches loud and gets pulled back quietly. This one was built the other way around, quietly, conservatively, with the most sensitive constraints baked in first and the safest channel shipped first. What the team sees in the inbox is calm, fast, and precise. What they don't see is the knowledge base underneath and the policy layer on top, the two things that make the whole thing publishable.