Support Tickets: Getting Requests Out of Inboxes and Into a Queue Everyone Can See
On this page
The problem: support requests live in inboxes
A support request sent by email has a specific, quiet failure mode: it's visible to exactly the people cc'd on it, and invisible to everyone else — including whoever should be covering for the original recipient when they're out, and including leadership trying to get a sense of overall support load. Nothing about an inbox is designed to be a shared queue. It's designed to be one person's list of messages.
The result is predictable: requests get missed, duplicated, or handled inconsistently depending on who happens to see them first. And there's no aggregate view — no way to answer "how many open requests do we have right now" without manually counting across however many inboxes are involved.
SAVHN's Tickets module replaces that with an actual queue: support requests tracked as records, visible within your organization, and — for the platform itself — visible across every tenant using it.
What the Tickets module actually does
- Org-scoped tickets — support requests tracked within your organization, visible to whoever has access rather than confined to one inbox.
- Platform-wide ticket view — for the platform level, tickets are also visible across every tenant, giving a full picture of support activity rather than a per-organization silo with no aggregate view.
- Status tracking — each ticket carries a real status as it moves toward resolution, instead of a thread where "status" is whatever the last reply implied.
The core shift is from "message in someone's inbox" to "record in a queue." A ticket isn't owned by whoever happened to receive the original email — it's a shared object that anyone with the right access can see, pick up, and track through to resolution.
Inbox-based support vs. a real queue
| Support requests by email | SAVHN Tickets module |
|---|---|
| Visible only to whoever's cc'd | Visible to anyone with access, org-wide |
| No aggregate count of open requests | Status tracked per ticket, queue visible as a whole |
| Coverage during absence depends on inbox delegation | Tickets aren't tied to one person's inbox to begin with |
| Platform operator has no cross-tenant visibility | Platform-wide view across every tenant |
How it works
- A support request is logged as a ticket, not sent as a standalone email — it becomes a record with its own identity.
- The ticket carries a status that reflects where it actually stands in resolution, visible to anyone checking the queue.
- Within your organization, tickets are scoped to your org — your team's queue, visible to the people who need to work it.
- At the platform level, tickets roll up across every tenant, giving the platform operator a full view of support activity system-wide rather than having to check in with each organization individually.
- Status tracking continues through to resolution, so the ticket's record — not someone's memory of the thread — is the answer to "is this handled yet."
Who uses this
- Support staff, who need a shared queue they can work from instead of a personal inbox only they can see.
- Team leads, who need visibility into how many requests are open and how they're trending, without manually tallying across inboxes.
- Platform administrators, who need a cross-tenant view of support activity across the whole platform, not just within one organization.
Common mistakes and misconceptions
A common mistake is continuing to run support partly through email "for convenience" alongside the ticket queue. Once a request exists outside the ticket system, it's invisible to the queue again — the exact problem tickets exist to solve. The value only holds if requests actually go through it.
A misconception worth clearing up: org-scoped tickets and the platform-wide view aren't the same audience seeing the same thing. Your organization's team sees its own queue; the platform-wide view is specifically for the platform operator's visibility across every tenant. One doesn't substitute for the other.
It's also worth distinguishing Tickets from projects. Tickets are discrete support requests moving toward resolution; projects are ongoing bodies of work moving through pipeline stages. A ticket might surface a problem that becomes project work, but the two record types track fundamentally different things.
Why the platform-wide view matters specifically for a multi-tenant product
Most support software is built for one organization looking at its own queue, full stop. SAVHN is a platform other organizations run their operations on, which means the platform operator has a different problem: understanding support load and ticket health across every tenant at once, not just within a single org's queue. Without that aggregate view, the only way to know whether a systemic issue is affecting multiple tenants is to notice it independently in each one — which is slow, and easy to miss if the affected tenants aren't the ones that happen to escalate loudly.
The platform-wide ticket view exists specifically to close that gap. It doesn't change what an individual organization sees — your org's queue stays scoped to your org — but it gives the platform operator a genuine cross-tenant picture, so patterns that show up in three organizations at once don't have to be discovered three separate times.
Where it fits in SAVHN
Ticket activity is part of the same organizational picture that flows into reports, and clients raising requests can do so with visibility into their own tickets through the client portal rather than needing to email and wait. Internally, ticket-related work and status can be discussed directly through chat without the context living somewhere disconnected from the record itself.
For details on ticket status configuration and platform-level views, see the documentation. More on how support activity connects to reporting is in the Knowledge Center.