Choosing the First Helpdesk Tool

The requirements spreadsheet has eighty rows. Row one is "must have: e-mail integration", which is reasonable. Row forty-seven is "must have: gamification". Row eighty is "must have: AI", with no further detail. Every one of the eighty is marked must have, in bold, by someone who has never worked a queue and will not be the one logging in. It arrived with a request for a shortlist by Friday.

Choosing the first help desk tool is a smaller decision than that spreadsheet makes it, and a longer one than it looks. Smaller, because a greenfield desk needs about ten things. Longer, because whatever you pick will hold your ticket history, your users' habits and your intake address for years. Leaving it costs more than arriving. This article is part of our Helpdesk From Scratch series. It is about getting the requirements down to the ones that matter and testing them with real tickets instead of a demo.

It covers who is writing this, then the ten requirements that matter and the ones that depend on you. Next come the trap of buying for the company you hope to be, and a two-week trial with a scorecard to copy. Then come the cost of changing later, the hosting question, and what happened when Northgate Retail trialed two tools with the same ten tickets.

First, Who Is Writing This

QuerySolv sells help desk software, and this article was written by the people who make it. That is a conflict of interest. The honest thing to do with a conflict of interest is to say so at the top and then show the reasoning. That way, you can check it rather than trust it. Where the advice below favors tools like ours, ask whether the reason given holds for your desk. Where it does not favor us, which happens more than once below, that is the point of writing it down.

We have also tried to keep the requirements neutral. Some things on the lists below are needs our product does not meet, and they are there because some readers need them. A requirements list that matches one vendor's feature page is a brochure with checkboxes.

The Ten Requirements That Matter

A greenfield desk has ten requirements that matter, because each one either protects the ticket history or removes a reason for people not to use the desk. Here they are, with why, in roughly the order a ticket meets them. A ticket is one request with a number, an owner, a status and a history; the queue is the list of all of them.

1. One queue for every channel. Every route in creates the same kind of ticket in the same list. That applies whether it is e-mail, a web form, a phone call written up by the technician or a chat message. The count is only honest if nothing lives outside the queue. Without it the desk grows a second desk nobody can see.
2. E-mail in and out that threads. A reply to the desk's message lands on the ticket it belongs to, not as a new ticket. The desk's replies go out from the ticket with the number in the subject. Threading is the tool matching a reply to its conversation by message identity, not by hoping the subject line survived. Most users will use e-mail whatever you tell them, so without this every conversation fragments into three tickets.
3. A form users can use without an account. No sign-up, no password, no plug-in; the requester is identified by e-mail address. "I don't have a login" is the first excuse not to use the desk, and the corridor needs no login.
4. Categories, priority and status. Three fields every ticket carries: what kind of thing it is, how urgent it is compared with the rest, and where it is in its life. Triage needs somewhere to put its decision. Without them every ticket is "open" and the queue sorts itself by age.
5. Assignment and ownership. One name on every ticket, visible in the list. Ownership is the difference between a ticket that was seen and a ticket that was taken.
6. Internal notes. A note on the ticket the requester never sees, for what was tried and what was found. Without it the diagnosis lives in a chat thread and a head.
7. Search across old tickets. Full-text, across the conversation and the notes, not just the subject. The second time a problem appears, the answer is in the first ticket, if you can find it.
8. A basic knowledge base. Short articles, with at least a published-or-draft distinction and ideally an agents-only state. Without one the answers live in a shared folder with eleven versions of each.
9. Reports for three numbers. Tickets per week by category, the oldest open ticket and the count over a week old, and reopens per closed ticket. The First Three Helpdesk Metrics explains why those three. Without them you have a spreadsheet, maintained until it is not.
10. Export of your data. Tickets, conversations, notes and attachments, in a documented open format or a database you can read directly. You need it the day you leave the tool and the day an auditor asks. Without it the history is a hostage, and the ransom is renewal.

Three of the ten are under-weighted in almost every spreadsheet I have seen: threading, the account-free form, and export. None of them demos well. Threading looks like nothing happening, which is the point. The account-free form looks like a missing feature to someone who has never asked a warehouse supervisor to create a password. Export is for a day the buyer would rather not imagine. Notice also what is not on the list: no workflow designer, no automation engine, no asset register, no mobile app. Some desks need those, and the next section says which.

The Requirements That Depend on You

A second group of requirements is real for some desks and dead weight for others. The spreadsheet's mistake is to mark them all must have. The table states each one neutrally, with who needs it on day one and who can wait. Be honest about which column you are in; the tool does not know, and the demo will assume the expensive one.

Each of those is a legitimate need. A reader who needs an asset inventory or a tool that runs on a non-Windows server should weight it as heavily as any of the ten. ITSM, IT service management, is the broader category of tool that bundles tickets with assets, changes, problems and a configuration database. If three or more rows of this table are in your first column, you may be shopping for one of those rather than a help desk.

The Trap of Buying for the Company You Hope to Be

The most common mistake in a first tool choice is buying for the desk you expect in five years instead of the one you will have in eighteen months. A two-person desk that buys the forty-agent platform gets forty agents' worth of configuration to maintain, menus to navigate and settings to explain to the next person. The desk has two people to do it. Every feature you do not use is not free. It is a door you have to walk past.

"We'll grow into it" is the sentence to watch for. You grow into its administration first, then its bill, and only then, if the desk survives, into its features. The honest version is "we will need this when we have five agents, and we can change tools then, if we chose one we can export from". The eighty-row spreadsheet is mostly the company you hope to be, written down. Sort it by one question, will we need this in the first ninety days, and the rows that survive are your requirements. There are rarely more than fifteen. The rest go on a page titled "later", a useful page to have and a terrible page to buy from.

The opposite trap exists too: something so small it has no threading, export or search is outgrown in six months. Buy for eighteen months. It is the one horizon where both the desk and the tool are still recognizable.

Designing the Trial: Two Weeks, Ten Real Tickets, Three People

The trial is where the decision is made. A good one takes two weeks, ten real tickets and three people. Two weeks because week one is setup and tickets and week two is living with it: searching for last week's tickets, running the report, restoring the backup. Ten real tickets because invented tickets are polite and real ones are not. Three people because the agent, the requester and the administrator each find a different failure.

Take the ten from the shared mailbox. Make sure the set contains one password reset and one "my screen does not work". Include one that needs an internal note and a handoff to someone else, and one where the requester replies three times. Add one that should reopen after it is closed, and one with an attachment. Include one that arrives by phone and is written up by the agent, and one put in the wrong category and re-sorted. Finally, add one that is a request rather than a fault, and one that duplicates another and should be merged. Those ten exercise all ten requirements. A demo exercises the first one.

The three people are the agent who will work the queue, a requester from outside IT, and whoever will administer the tool. The requester matters most and is consulted least. Ask them to send the three-reply ticket from their own mailbox, open the form without help, and say honestly whether they would use it on a bad day. The administrator installs it, backs it up on day two, and restores the backup on day three. A backup that has never been restored is a theory. Every tool on the shortlist gets the same ten tickets, the same three people and the same card. Two tools is the right shortlist. Five is a procurement project, and procurement projects choose the tool with the best spreadsheet.

The Trial Scorecard

Score each row from zero to two. Give zero if the test failed or needed a workaround the requester would not tolerate. Give one if it worked with effort or explanation, and two if it worked the way the requester expected without being told. Rows one, two, three and ten are kill rows: a zero on any of them ends that tool's trial, whatever the total. The last three rows are verdicts rather than features; read them first when the totals are close.

The Cost of Changing Later

The cost of changing tools later is part of the decision now. It is made of two things: the history you lose and the habits you retrain. Neither appears on a quote. Ticket history rarely migrates cleanly. Conversations move, but notes, attachments and who-changed-what often do not. The search index starts from empty. You end up with an archive you can read and a new tool you cannot search.

The habits cost more, because they belong to other people. Every user re-learns the form and every agent re-learns the queue. For a month the shadow mailbox comes back, because the old way is the way people remember under pressure. A tool change is a second launch, with the first launch's goodwill already spent.

So treat the first tool as a three-year decision, and insure it with requirement ten. In month three, with a hundred tickets, a change costs an afternoon and some apologies. In month twelve, with a thousand tickets and three hundred users who know the address, it costs a quarter. The window for a cheap change closes quietly.

The Hosting Question, Plainly

Where the tool runs decides the shape of the cost, and there are three honest shapes. A cloud help desk runs on the vendor's servers and is paid per agent per month. A self-hosted commercial desk runs on your own server and is bought once, as a license, then run by you. An open-source self-hosted desk costs nothing to download and is paid for in operations: installing, integrating, upgrading and supporting it yourself. No names and no prices here, by our own rules.

Cloud is fastest to start and asks nothing of your servers. The data lives elsewhere, the cost rises with every agent you add, and the roadmap is the vendor's. It suits a desk with no server team, no rule about where data lives, and a headcount small enough for per-agent pricing to make sense.

Self-hosted and bought once gives you a server to patch, a backup to test, a certificate to renew and a person to do all three. In return the data stays on your network and the cost does not move when the team grows. It suits a desk that already runs servers, has rules about data, or expects to add agents. It does not suit a desk with nobody to run the server. A tool nobody patches is a liability with a login page.

Open source suits a desk with a person who has the hours and wants to spend them this way. That is not a small qualification. The license is free; the integration, the upgrade that breaks the theme, and the support forum are yours. Done by someone who enjoys it, it is the cheapest option by far. Done by someone who was told to, it is the most expensive, paid in evenings. You can guess which shape we sell, so discount accordingly and check the reasoning. The cheapest option is the one whose hidden cost you already pay. If you run servers, you already pay for self-hosting. If you have the enthusiast, open source costs their weekends, which are theirs to spend.

A Short War Story: Two Tools at Northgate Retail

Lena ran the tool trial for Northgate Retail's new desk with the same ten tickets in two tools, the last ten from the store managers' shared mailbox. The first tool had an asset register, a mobile app, a workflow designer and a ninety-minute demo. The second had none of those and a twenty-minute demo. In the first tool, the ticket where a store manager replied three times became three tickets, because he had retyped the subject line and the threading relied on it. In the second it stayed one ticket, because the threading used the message identity. Lena scored both. The first tool lost on a kill row, and Northgate chose the second. The asset register went on the "later" page, where it still is, and nobody at the stores has ever asked about the workflow designer.

I have sat on the vendor side of trials like that one. The feature list wins the demo. The threading wins the year.

Deciding

Run the trial, score the card, read the three verdict rows first, and choose. Then write the reason on the card, date it and keep it. In a year it is the answer to "why this tool", and the test the next tool must pass. The decision is for the next few years, not forever. The day-zero decisions that go with it are set out in Day Zero: What You Need Before the First Ticket. The processes you run on it are independent of the tool; The First Five Helpdesk Processes work on whichever one wins.

Since we said we would show our hand, here is where our product sits against the list, in both directions. QuerySolv's requester portal needs no account, no password and no JavaScript, which is requirement three. QuerySolv is licensed once per installation, with a Free edition for two agents and a 30-day trial of the full product. That is the self-hosted cost shape described above. In the same breath: it is not an ITSM platform, so there is no asset inventory, configuration database or change management. The server side is Windows only. And there is no mobile app. If any of those is in your first column, this article sends you elsewhere. That is what the table is for.

The spreadsheet with eighty rows will still exist on Friday. Hand back one with fifteen, a filled-in scorecard, and a ticket where somebody outside IT replied three times and it stayed one ticket. That is a shortlist. The other sixty-five rows were a wish list, and the desk will write a better one in a year, from tickets.

Frequently Asked Questions