Choosing service desk software as an MSP

Every service desk platform demos well. The features that decide whether you are happy two years in are rarely the ones on the comparison grid, and the questions that surface them are unglamorous. Here is the list worth working through, roughly in the order that the answers matter.

Does it model the way an MSP actually works?

The first fork in the road: was this product built for a company supporting its own staff, or for a company supporting other companies? Almost every well-known help desk is the former, retrofitted. You can tell within ten minutes of a trial:

• Is there a first-class concept of a customer, with sites beneath it, or are your clients modelled as tags on a ticket?
• Can a contact belong to one client and not accidentally see another's tickets?
• Can you say which people at a client are allowed to authorise things, as data rather than as a note?
• Does reporting slice by client without a spreadsheet export?

If the answers involve custom fields and workarounds, you are buying a project rather than a product. That structural fit is what an MSP CRM is for, and it is not something you can bolt on later.

What happens at the moment of trust?

This is the question missing from nearly every buyer's guide, and it is the one your insurer will eventually ask about. Your desk performs actions that hand over access — resets, MFA re-enrolments, new admins, credential releases. Ask the vendor:

1. Where in this product does an engineer confirm the person asking is who they claim to be?
2. Is the result of that check stored as structured data, or as a free-text note someone might write?
3. Can we require sign-off from a named person at the client for specific request types — and is that a setting, or a habit?
4. If we are asked in a year who authorised a particular reset, what exactly can we produce?

A reasonable answer to question one is "we do not do that, you would use a process" — plenty of good products are honest about it. An unreasonable answer is a vague gesture at custom fields. The gap it leaves is covered in more depth under caller verification.

How many systems does the answer span?

Count the tools a single sensitive request touches on your current setup. For most MSPs it is three or four: the ticketing system, the CRM or client list, the password manager, and something informal that records who is allowed to approve what. Every boundary between them is a place a check gets skipped, because skipping it saves a context switch.

Controls fail at the seams between tools, not in the middle of them.

That does not mean you need one vendor for everything — bundling has its own costs. It means the systems involved in a trust decision should be one system. The record, the request and the credential belong together; billing and project planning do not have to join them.

The operational questions people forget

• Getting out: can you export everything, including ticket history and attachments, in a usable format? Ask for a sample export during the trial, not a promise.
• Where the data lives: which country, including backups, and can they name their sub-processors in writing? Your clients will ask you, so ask them first — the reasoning is set out under UK data residency.
• Pricing shape: per seat, per client, per contact or per ticket. Per-client pricing punishes exactly the growth you want.
• Onboarding effort: how many hours to get one client fully modelled, honestly measured on the trial rather than quoted.
• Who answers the phone: when the platform running your desk breaks, what is the actual support path?

How to run the trial

Feature checklists reward the vendor with the most features, which is rarely the right choice. A better test is to take three real requests from last week — one routine, one sensitive, one that went wrong — and run each through the trial end to end. Time them. Note where you had to leave the tool.

Then have someone try to socially engineer your trial desk. If the platform does nothing to stop a plausible stranger getting a password reset, that is not a criticism of the product, but it is a fact about what you will be relying on your engineers to carry unaided.