Multi-client help desk for MSPs: requirements

Supporting one company requires tidiness. Supporting twelve requires boundaries: between one client and the next, between a technician and the clients they do not look after, between a contract that promises a fast reply and one that does not. A help desk that cannot hold those boundaries does not break immediately — it breaks the day one client reads another client’s name.

This guide lists the five requirements worth being inflexible about when choosing a tool for multi-client support, and how to verify each one in a trial rather than in a tender document.

1. Separation, the requirement the others depend on

That clients cannot see each other sounds obvious, and hardly any supplier would deny it. The question that separates real answers from polite ones is a different one: where the separation is applied.

If a technician not enabled on a client cannot see their tickets in the list but finds them by searching, or receives them in a notification, or gets them from an API, the separation is an interface filter. A trial settles it in five minutes: two fictitious clients, one technician enabled on only one of them, and a search for the other client’s name from that account. A single result is already the answer.

The other half of the requirement concerns your clients: one company’s contact must not be able to reach another company’s requests, not even by guessing a URL. It is worth actually trying — open a request with one account and try to open its address with the other.

2. Technician scope, and who decides it

Separation between clients is one axis; a person’s scope is the second, and the two multiply. A technician can be enabled on three clients and see, within those three, everything or only what has been assigned to them.

The combinations a multi-client operation really needs are few:

• Everything on every client — whoever coordinates, and whoever is on call.
• Everything on some clients — the normal setup for a technician who has their own accounts.
• Only assigned requests — a contractor, or somebody who has just arrived.
• Only what they opened — people who send you work without doing it.

What matters more than the list is that scope is composed from two independent axes rather than baked into a single role. A product offering “junior technician” and “senior technician” as fixed roles will force you, at the first exception, to give somebody more visibility than you intended.

3. Different times for different contracts

Multi-client operations almost always carry different contracts, and a tool that accepts a single set of response targets forces you either to pick the tightest and miss it, or the loosest and notice nothing.

So targets belong per client and, within the client, per priority. Three things to clarify before signing, because they change what the number means:

• When the clock starts, and whether it stops. If counting is continuous, twelve hours opened on Friday evening end on Saturday: legitimate, but it has to be known and told to the client.
• Does waiting on the customer count? If you are waiting for information from them, that time is not yours. A tool that does not separate it teaches the team to close requests quickly.
• What happens at the threshold. In nearly every product an alert is sent, and that is all: nothing closes, reassigns or raises priority on your behalf. That is fine, as long as the supplier says so and you have not promised your client otherwise.

And the contract stays a different thing from the number set in the software: the first is owed to the client, the second is an internal reminder that helps you keep it. The distinction is worked out in the guide on priorities and response times.

4. History does not belong to whoever wrote it

This requirement is discovered late and costs the most: when the technician who looked after three clients goes on holiday, changes job or falls ill, the conversation with those clients must not leave with them.

Three things make a setup absence-proof. The conversation with the client lives in one place, not in a personal mailbox. The notes the team exchanged live on the same request, marked as internal. And handovers stay on the record with a date, so whoever takes over rebuilds the story by reading instead of phoning.

The same applies on the client’s side: when their contact person changes, open requests belong to the company and not to the individual who wrote them. Check it, because not every product behaves that way.

5. Your brand, which is a requirement and not a flourish

Anyone reselling support needs the end client to see their own name: on the address, in the portal, and in the notifications they receive. It is not an aesthetic matter — an unknown supplier writing to your client generates a phone call to you.

This section is deliberately short: exactly what to ask about the address, the sending address, the privacy notice and the consistency between both faces is worked out in the guide on evaluating a white-label help desk. What makes a tool usable with twelve clients are the four requirements above; branding is what makes your offer usable.

When a help desk is not enough

Half the disappointment in multi-client support comes from the fact that “help desk” and “platform for IT providers” are searched with the same words and are not the same thing. These capabilities sit outside a ticketing system almost everywhere, and if you need them it is better to know first:

• Monitoring: a server alert that opens a request by itself. It is a different product, and the integration has to be built.
• Device inventory and remote access: two more products again.
• Inbound email: turning the messages that reach the support mailbox you already use into requests.
• Time tracking and billing from the request.
• Several channels: phone, chat and social in the same place as written requests.

Platforms covering all of it exist, cost more per person and ask for weeks of onboarding. The question to ask is whether today’s problem is the absence of those features, or the fact that client requests are spread across three mailboxes: in the second case a complete platform is an expensive way of not solving it.

What you can verify in OglutTicket

The first four requirements are verified in the trial, and these are the facts to put under test. Separation runs through the project — one per client — and the filter is in the query: a technician enabled on three clients does not find the others through search or through the REST API either. Scope is composed from two axes, the projects and how much is visible inside each, and roles are six and fixed rather than a permission editor.

Response times are switched on per project and per priority, therefore per client: one contract can carry a tighter threshold than another. Hours are continuous rather than office hours, waiting on the customer has a separate target, and at the threshold an alert is sent — the software does not close, reassign or change priority. The client never sees that a threshold was passed.

On continuity: history lives on the request rather than in a mailbox, internal notes never reach the client’s browser, and removing a person’s access to a project clears their open assignments there while the tickets stay. Who did what is kept in a record that cannot be edited.

The limits are exactly those of the previous section: no monitoring, no inventory, no remote access, no inbound email, no billable hours and no channel beyond the portal and the public form. Integrations go through a REST API and webhooks, which have to be written.

The commercial page for providers putting their own name in front of clients is white-label help desk. Anyone developing their own software instead of supporting somebody else’s will find the right angle in ticketing for software houses.