Building a Multi-Channel Inbox: Email, Chat, and Widget in One Thread

A customer starts in the website widget, follows up by email that evening, and replies to your answer two days later from their phone. To them it is one conversation. Most support tools store it as three.

Unifying channels is mostly a data-model problem, and the decisions you make early are expensive to reverse. Here is how we modeled it.

Conversations are channel-agnostic; messages are not

The core split: a conversation belongs to a contact and a topic, while each message carries its own channel, direction, and delivery metadata. The inbox renders the conversation; the send path looks at the last inbound message to decide how a reply should go out.

This means an agent never chooses a channel. They type a reply, and it returns the way the customer last wrote in — widget message if they are still on the site, email if they left. The channel chip on each message keeps the history legible.

Identity stitching without creepiness

Merging threads requires knowing that widget-visitor 4821 and jane@acme.com are the same person. We stitch on explicit signals only:

• The visitor authenticates in your product and your frontend passes a signed user hash.
• The visitor types their email into the widget's email-capture step.
• They click a magic link from an email notification back into the conversation.

We deliberately do not fingerprint devices to guess identity. A wrong merge shows one customer another customer's history — a category of bug you want to make structurally impossible, not just unlikely.

Ordering is harder than it looks

Email arrives out of order: a reply can beat the original through your pipeline, retries duplicate webhooks, and clock skew across providers is real. Every message gets two timestamps — provider-reported and received-at — and the thread renders on provider time with a monotonic tiebreaker so the UI never reshuffles after first paint.

Deduplication runs on provider message IDs with a content-hash fallback. The fallback matters: some mail servers rewrite IDs on retry, and a duplicated apology email makes your team look asleep.

What the AI sees

The payoff of one thread is that the AI agent reads the whole relationship before answering. It knows the customer already tried the reset flow yesterday in the widget, so it does not suggest it again by email today. Channel-siloed tools force the customer to repeat that context; unified ones make the second answer smarter than the first.

The unified thread is also why escalation summaries stay short — one conversation to summarize, not three fragments to reconcile.

How the widget fits the model

The widget is the most complex channel to integrate cleanly because it lives inside thousands of different host pages. Each one has its own CSS reset, z-index stack, and JavaScript scope. We render the Chattering widget in a Shadow DOM rather than an iframe — this keeps it in the same document for accessibility and scrolling, while isolating its styles completely from the host page.

What matters for the channel model is that the widget is a first-class channel. Messages arrive as channel-tagged rows in the same conversation table, the same identity stitching applies, and the same two-timestamp ordering handles the occasional out-of-sequence delivery. The Shadow DOM work is invisible at the data layer; the effect is that the widget behaves exactly like email in the conversation thread, just with lower expected round-trip times.

How we handle Shadow DOM isolation in practice →

If your team is juggling a chat tool, a shared mailbox, and a form backend, the fix is structural. See how the inbox works, or open one on the free plan and email yourself through it.