One inbox, many brands: designing Helpdash for multi-tenant support

Most helpdesks assume one company, one logo, one support address. That assumption breaks the moment a team supports several brands: an agency running support for its clients, an MSP covering a dozen customers, a reseller putting its own name on someone else's product. The usual workaround is one helpdesk instance per client, and the usual result is a support lead with fourteen browser tabs.

Helpdash starts from the other end. A workspace is the tenant boundary — its own domain, logo, palette and sending address — but agents work above it, in one triage view that spans every workspace they are entitled to see. Switching brands is a filter, not a login.

That design forces a discipline that is easy to skip: isolation has to be provable, not promised. Every query is scoped at the boundary rather than in the view layer, so a missing filter is a failed test, not a leaked ticket. The same rule covers file uploads, search, exports and webhooks.

If a tenant boundary depends on a developer remembering it, it is not a boundary.

The second decision was pricing shape, which is really a product decision in disguise. Per-seat pricing makes a support lead ration access — the fifth agent is a budget conversation, so tickets sit unassigned overnight. Helpdash is priced per workspace, so adding the person who can actually answer costs nothing.

What is left is the boring half: email in and out, a web widget, live chat over WebSockets, a multi-locale knowledge base, SLA timers and CSAT. None of it is novel. All of it has to survive a Monday morning.