A Support Platform: Knowledge Base, Tickets, and Email

Photo: Michael Mroczek · StockSnap (CC0 1.0), via Openverse

Support was, for a long time, the place in Xircuit where I got in my own way. There were a handful of screens where an operator could ask questions, but no place where those questions converged, and no reliable path for a reply to find its way back. If someone from one of the studios or practices wrote an email, it landed in an inbox that nobody worked through in a structured way. That works fine when you have three testers and know all of them. It stops working the moment real organizations with real concerns show up.

That's why this week I didn't work on a single feature, but on a connected slice of the platform: a knowledge base that gives answers before anyone has to ask, a ticket system that keeps the dialogue traceable, and an incoming email path that automatically turns a reply in someone's inbox into the right ticket response. Three parts that only together add up to something you can reasonably call support.

Why a Dedicated Support Layer at All

One could argue that a young product doesn't need a fully built-out support system — a contact form and an email address should be enough. In practice, that's exactly the trap. A form without follow-up leaves the sender feeling like they wrote into a void, and leaves the operator with a constant fear of having missed something. Both undermine the trust that a platform handling health data and scheduling for entire businesses needs.

So from the start I wanted a flow that guarantees three things: every request gets an identity, every reply finds its way back to it, and recurring questions never become requests in the first place. That last point is why the knowledge base comes before the ticket system — the best support case is the one that's never opened.

The Knowledge Base at /help

The entry point now lives at /help. There, a knowledge base collects help articles on the topics that kept coming up in the first few weeks anyway — from an organization's first steps to detailed questions about billing and data sharing. The page is deliberately plain: a searchable overview, articles as standalone views, no bloated portal.

The point that mattered to me here is where the content comes from. The articles aren't maintained by hand in the database, and they're not hard-wired into markup — they're delivered through a HelpContentSeeder. The seeder runs at startup, checks the existing inventory, and inserts new or changed articles without duplicating what's already there. That has a concrete benefit: a help article becomes versioned code, just like everything else. I write an article in a branch, it goes through the same review, and at the next deploy it appears identically in every environment. No manual upkeep in production, no drift between test and live.

The fact that the knowledge base runs on the same .NET 10 stack as the rest of the platform makes this seeder mechanism unspectacularly reliable — it hooks into the initialization that already runs on every Aspire boot, with no special path required.

Tickets That Keep a Thread

Photo: Tom Hermans · StockSnap (CC0 1.0), via Openverse

For everything the knowledge base doesn't catch, there's the ticket system. The core idea here is that tickets are threaded: a request isn't a single message block, but an ongoing dialogue between the member and the operator. Every reply attaches to the history, and both sides see the same chronology in the same order.

That sounds obvious, but technically it isn't quite. A ticket is therefore not a status field on a form entry, but an entity with an ordered list of contributions that can come from different actors — sometimes from the requesting member, sometimes from support on the operator's side. That traceability is exactly the point: anyone who opens a ticket later sees the entire history, not just the last line. When there's a follow-up on an earlier case, nobody has to reconstruct what was actually discussed.

A threaded model also pays off when a case goes dormant for a while. If the member gets back in touch days later, the new message lands in the same thread instead of a second, half-redundant ticket. That keeps the queue clean and the context intact.

Email as a Full-Fledged Inbound and Outbound Channel

The part that occupied me longest this week is the incoming email path. Real users' expectations are clear: if I get a notification about a ticket reply by email, I want to simply hit "reply" and type — not log in somewhere to copy my own sentence into a text field. For that to work, an incoming email has to be mapped to the correct ticket reliably.

That's exactly what VERP addressing does. Instead of a generic support address, every outgoing notification carries a uniquely encoded sender or reply address that has the ticket mapping baked into it. When someone replies to it, the recipient address alone tells the system which ticket the text belongs to — even before the content is looked at. The incoming email is then hooked into the existing thread as a new reply, as if it had been written directly in the interface. That way, a classic back-and-forth email exchange turns into a cleanly logged ticket history, without the sender having to do anything differently than usual.

The appeal of VERP is that the mapping doesn't depend on error-prone parsing of the subject line or quoted text blocks. The address itself is the key, and it's machine-generated and machine-readable.

What Production Additionally Requires

An honest note here, because the incoming path isn't pure application code — it depends on infrastructure that has to be configured outside the repository. For incoming mail to reach Xircuit at all, production needs three things: an MX record that points the support domain to receiving, SendGrid Inbound Parse to accept incoming messages and forward them to our endpoint, and a webhook secret that protects that endpoint against spoofed calls. If any one of these three pieces is missing, the outgoing path keeps working flawlessly, but replies by email won't arrive. That's a deliberate operational prerequisite, not a guess — the wiring in the code is in place, and the DNS and SendGrid side is a separate, well-understood step.

The outgoing path, in turn, relies on a rule that applies to the entire platform: all product emails run through the verified domain xircuit.com. That's not a cosmetic decision. A single, authenticated sender domain is the foundation for our mail not getting lost in spam folders, and for the VERP reply addresses to flow back through that same reliable delivery path in the first place. A ticket system whose notifications don't arrive would only be worth half as much.

The Parts Work Together

Looking back, what's satisfying about this week is less any single building block than how they work together. The knowledge base lowers the number of requests; the remaining requests become threaded tickets with full context; and the email bridge means a member never has to know the path through the interface to stay part of that history. Each part on its own would be half a feature. Together they form a flow I trust to grow along with a rising number of users, without me having to keep a personal eye on every single email.

The operational step for the incoming path deliberately remains open — until MX, Inbound Parse, and the webhook secret are set in production, email replies are a capability that lives in the code but doesn't yet breathe live. That's the honest state of things, and it's a good feeling that this gap is the only notable one.

What's Next?

Next week: organization contact data and profile pages across every industry. Now that support has a framework, the focus turns back to the organizations themselves — and to how they present themselves within the platform.