Platform
Multi-tenant permissions for hosting teams
Who can suspend a customer, who can issue a refund and who can read a credential are three questions. Collapsing them into admin-or-not is the usual mistake.
10 min read · Reviewed 2026-09-21
In short
Give every conversation exactly one named owner and make the owner visible on the board. Columns should describe who is blocked — us or the customer — rather than how hard the work is. Two people each assuming the other replied is a failure that one visible owner prevents by construction.
Picture support at a small host as people are added. With one person, the queue lives in their head. With two, there is occasional duplication. Add more and conversations can start falling through — and when they do, the first thing to check is whether anybody owns them.
Columns that say who is blocked
The useful question a board answers at a glance is what needs us. So the columns should be about who the work is waiting on:
| Useful | Why | Less useful |
|---|---|---|
| Open | Nobody has picked it up | Low / medium / high — priority is a field, not a column |
| Waiting on us | We owe a reply | In progress — indistinguishable from waiting on us |
| Waiting on customer | The clock is theirs, not ours | Escalated — ambiguous about who is acting |
| Resolved | Done, and reopenable | Closed and Archived as separate columns |
"Waiting on customer" is the column that earns its keep. It stops the queue looking alarming when it is not, and it makes a stale conversation visible: something that has been waiting on a customer for two weeks needs a nudge or a close, not a daily glance.
One owner, always
Every conversation has exactly one person responsible for the next move. Not a team, not a rota — a name. If that person goes on holiday, the conversation is reassigned explicitly, which is a small act that prevents the failure this article is about.
- Unassigned means nobody has picked it up. It is a valid state and it should be visibly uncomfortable.
- Assigning is a recorded act with a timestamp, so "who had this" is answerable.
- The customer never sees the owner's workload, only that somebody answered.
Link the conversation to the thing it is about
A ticket that names the customer is useful. A ticket that names the service is far more useful: it means the person answering can see the server, the plan and the billing state without three searches. It also means that when you retire a server you can find every open conversation about it.
What to measure, and what not to
Two numbers are worth watching: time to first reply, and conversations older than a week. The first is what customers actually experience. The second is where the reputational damage accumulates.
Do not measure tickets closed per person. It rewards closing conversations rather than resolving problems, and the fastest way to a good score is to close something the customer will have to raise again.
Reopening is normal
A resolved conversation that the customer replies to should reopen, keep its history, and return to its previous owner by default. A system that creates a new ticket on reply throws away the context that made the first reply possible.
Where GENV is
GENV ships a support desk with a queue, one owner per thread, assignment recorded as an act, and threads that link to the customer and the service they are about. Replies, notes, assignment and resolution all happen on the thread's own page and each leaves a line. A resolved thread reopens on a customer reply and keeps its history.
Questions
How many columns should a board have?
Four or five. Every additional column is a decision somebody has to make on every ticket, and the marginal value drops off fast.
Should customers see the board?
No. They should see their own conversations and the state of them in plain words. An internal board exposed to customers invites arguments about priority.
Do we need service level agreements?
Not at small scale. A published response time you actually meet is worth more than a formal agreement you miss, and it is far cheaper to operate.