Home › Topics › Open Source vs Commercial Helpdesk Tools › Deciding

Deciding for a Small Team: Free or Commercial, and the Exit Plan

Thursday, 16:10, at Bellweather Logistics. Lena has two browser tabs open. One is the download page of an open-source ticketing tool, with a green button and a paragraph about how many organisations use it. The other is the sign-up page for a cloud help desk, with a green button and a paragraph about how many organisations use it. Omar, the operations director, wants a recommendation by Monday, because the old tool's subscription ends in six weeks. He has stopped enjoying the e-mails about it. Lena's desk is four people across two depots, about sixty tickets a week, and a Windows server with room on it. A technician called Dev looks after that server and would, given the chance, look after another. Both buttons would take four minutes to press. Neither page has asked a single question about Bellweather.

Deciding between free and commercial for a small team is not a choice between two tools. It is a choice between categories. You answer questions about the desk rather than about the software, and then choose one tool inside the category that wins. The questions are few. They are about time, money, risk and horizon, and they settle most decisions before anyone watches a demo. This article is part of our Open Source vs Commercial Helpdesk Tools series. And it is the last one, because it is the one where the decision gets made.

It covers why the decision is about your desk, not the tools, then the frame, which is four questions. Next come the specific questions that settle it, with a table, scoring without fooling yourself, and the exit plan either way. Three small desks with three different right answers and a short war story follow. Then come the decision sheet to copy and what to do in the first quarter after deciding, in that order.

The Decision Is About Your Desk, Not the Tools

Every page you will read while deciding was written to describe the tool. The tool is the part of the decision that matters least. Any category can supply a tool that holds a queue, assigns tickets, sends replies, keeps notes and draws three reports. A desk of four needs little more. The rest of this series has been about what each category costs to run and when those costs come due. What differs between desks is whether the hours exist and how the money can be spent. What the data is and how long the answer needs to last also differ. Those are facts about Bellweather, and no download page knows them. The decision is therefore made by writing down what is true about the desk and reading off which categories survive.

Doing it in that order also protects you from the tab you already like. Everyone arrives at this decision with a preference. It is formed by the last tool they used, a colleague's recommendation or the green button that happened to load first. A preference left unexamined becomes a decision with reasons attached afterwards. Answer the four questions before opening either tab. If the preference survives the questions, it was a judgement. If it does not, it was a tab.

One disclosure before the frame, since this is the article where the choice is made. The publisher of this library sells a commercial, self-hosted help desk, QuerySolv, which belongs to one of the four boxes below. The frame is written so that it would eliminate that box for some desks. And it should; a method that always recommends the author's product is a brochure. Check every step against your own desk.

The Frame: Four Questions

The first question is time. Does someone on the desk have hours in the week, protected on a calendar, to run a server and the software on it? Not "could find", not "in a quiet week", but hours that exist now and would survive a busy month. A self-hosted tool of either kind, open-source or commercial, needs those hours. An open-source one needs more of them, for the reasons in The Hidden Costs of Free. If the answer is no, both self-hosted boxes close and the decision is between a cloud help desk and finding the hours. That is the single most decisive question in the frame. Most desks answer it in under a minute once they are honest about the calendar.

The second question is money, and it is about shape rather than size. Can the organisation sign a recurring subscription without a procurement round every year? Or does it prefer a one-off sum from a capital budget? Or does it genuinely have neither? Finance departments differ, and the difference closes boxes. An organisation that approves monthly spend easily and capital spend slowly leans towards a subscription. One with an equipment budget and a dislike of recurring lines leans towards a licence bought once. One with no budget at all is choosing open source whether it likes the hours or not. Ask the person who signs, not the person who wants the tool. They are rarely the same person and they rarely give the same answer.

The third question is risk: what is in the tickets, and what happens when the tool breaks at 16:40 on a Friday? A desk's tickets may contain customer data, clinical notes or a contractual promise to keep information in a particular country. In that case, the desk has a data-location question that may close the cloud box on its own. A desk with nobody able to fix the mail connection when it fails has a support question that may close the open-source box on its own. Risk is the question that most often produces a hard "no" for one category. A hard no is a gift, because it shortens the list.

The fourth question is horizon: how long must the answer last, and how certain is the desk's shape over that time? A desk that is four people and will be four people for five years can afford a front-loaded cost and a long-term tool. A desk that may double, halve, be outsourced or be absorbed in eighteen months should prefer whatever is cheapest to leave. That usually means short terms, a tested export and no suite. Horizon does not close boxes so much as it sets the term and the weight you can afford. It is also the question that is most often answered with a forecast, and a forecast is not an answer. The previous article in this series, on when commercial is expensive, is largely about contracts signed on forecasts.

The Questions That Settle It

The four questions above become ten in practice, and the table below is the ten, each with where a yes and a no point. The table does not score; it eliminates and leans. Work down it with the desk's honest answers and mark which categories each row closes. Most desks finish with two boxes open, and the last section before the sheet shows what to do with those two.

QuestionA yes points toA no points to
Does someone already run a server here, with hours protected for it each week?Self-hosted, either kindCloud help desk, or find the hours first
Could that person read a log, edit a configuration file and apply an upgrade without help?Open-source is possibleSelf-hosted commercial or cloud
Does the organisation approve recurring monthly spend without a yearly procurement round?Subscription models are easyLicensed once, or open source
Is there a capital or equipment budget that could carry a one-off sum this year?Licensed once is possibleSubscription or open source
Do the tickets hold data that must stay on your premises or in your country?Self-hosted, either kindAny category
When the mail connection fails on a Friday afternoon, must a contracted person be obliged to help?Commercial, either kindOpen source is possible
Do you need to change how the tool works, not just configure it?Open sourceAny category
Does the organisation run several formal IT processes with named owners today?An ITSM suite is possibleA help desk, not a suite
Is the desk's size and existence certain for the next three years?Longer terms and front-loaded costs are safeShort terms; cheapest to leave
Has a full export from the candidate been run, opened and checked?The candidate may be chosenNot yet, whichever box it is in

Two rows deserve a note. The second row is the one desks most often answer with hope. That is because the person who runs the server is a good technician and good technicians can learn anything. They can. The question is whether they will have the hours to learn it in the same week the queue is full. The honest answer is the one Dev gives when asked directly, not the one Lena gives on his behalf. The last row is not a question about the desk at all. It is a gate. No category passes through it until the export has been opened on a screen and an attachment found inside it.

Scoring Without Fooling Yourself

Once two categories are left, pick one tool in each and run them side by side on real work. A decision between categories made on paper is a decision between averages, and you will be running a particular tool. The trial has rules of its own. The chief one is that both candidates get the same tickets, the same people and the same fortnight. And those rules are in Designing a Fair Trial. The purpose here is narrower: the trial is where the hours become visible. The open-source candidate's install, mail setup and first upgrade take real hours from a real person during the trial. Those hours are the best forecast of the yearly cost you will ever get. Write them down as they happen. Dev's estimate before the trial and his timesheet after it will differ, and the timesheet is the one that counts.

Weight the rows before you score, and weight them in writing, because the candidate you already like will otherwise acquire the weights it needs. If data location is a hard requirement, say so at the top of the sheet. In that case, a cloud candidate's excellent reporting cannot buy its way back in. If support at 16:40 on a Friday matters more than the licence fee, say that too. In that case, the open-source candidate's zero does not win the money row by default. Weights decided after the scores are not weights. They are a story about why the preferred tool won.

Then convert everything to one unit and sum over the horizon, as the first article in this series does with the trade-off table. Two candidates whose five-year totals differ by less than the error in the estimate are tied on cost. A tie on cost is useful information. It means the decision is being made on risk, support or control. Those should be named as the reason rather than disguised as a number. A desk might write "we chose the self-hosted tool because the client contract requires in-country data, and the cost was about the same either way". That desk has made a decision it can explain in a year. A desk that writes "it scored 84 against 79" has made a decision it will have to re-derive.

The Exit Plan Either Way

Whichever category wins, write the exit plan before you sign, and it has four lines. Where the data lives, named precisely: a database on a server with a name, or a vendor's service in a stated country. How it comes out: the export that was run during the trial, what it contained, and what it did not. How long leaving would take, estimated in hours and revisited each year, covering data, process and integrations. And the date you will revisit the decision, which is a calendar entry, not an intention. A category chosen with those four lines filled in is a decision with a door in it. A category chosen without them is a room.

The exit plan is the same length for every category and a different shape for each. For an open-source tool the database is yours and the export is your work. So the plan names who will write the extraction and confirms they did it once during the trial. For a cloud help desk the export is the vendor's. So the plan names what the export contains, in writing from the vendor, and schedules a yearly copy. For a self-hosted commercial tool the database is on your server and the export is the vendor's to provide. So the plan covers both. If you run a self-hosted tool such as QuerySolv, the database sits on a Windows server you name on the sheet. That fills the first line in one word and makes the yearly backup of that database the second line's proof. The habit that keeps history readable once the old system is gone is in Keeping History Without the Old System. The plan should point at that article.

Write the decision itself down too, on one page. Include the answers to the four questions, the categories eliminated and why, and the two trialled. Include the hours recorded, the weights, the reason, and the exit plan. The format and the reasons for keeping such a record are in Writing the Decision Down. The page is for the person who runs the desk in three years. They will be asked why the tool was chosen and will otherwise have to answer "I think Lena liked it".

Remember: answer time, money, risk and horizon about the desk before opening any tool's page. Let the answers close categories. Trial one tool from each category left. Weight in writing before scoring. And write the exit plan before you sign, whichever way you go.

Three Small Desks, Three Right Answers

Oakfield Academy, a secondary school, has one administrator, Priya, who runs three servers already and enjoys it. She has Friday afternoons protected for systems work because term-time mornings are for the classrooms. The budget for software is zero and will stay zero. The tickets are about projectors and logins, not about anyone's medical history, and the school will be the same size in five years. Every row of the table points the same way. Priya has the hours and the skills. There is no money of either shape, the data is unremarkable, and the horizon is long. Oakfield chose an open-source tool, self-hosted. Priya's worksheet from The Hidden Costs of Free shows about three working weeks a year spent on it. She budgets that time, and the school gets it back in control it would not otherwise have. That is the right answer for that desk.

Lantern Travel, a small travel agency, has a desk of two who are also the only IT staff and no server of their own. Its finance director approves monthly subscriptions in an afternoon and capital requests in a quarter. The agency has a plausible chance of being bought by a larger agency within two years. Nobody has hours for a server and nobody wants them. The tickets contain booking references and nothing a regulator would ask about. The table closes both self-hosted boxes on the first row, closes the suite on the process row, and leaves one box open. Lantern chose a cloud help desk on a one-year term with an export tested during the trial and scheduled yearly. Its exit plan is a file it already has. That is the right answer for that desk. And the fact that it was the only box left is not a failure of the method. It is the method working.

Bellweather Logistics is the third, and Lena's four answers were as follows. Yes, Dev has three hours a week for the server and a Windows server with room. The money answer was capital, because Bellweather's equipment budget is generous and its appetite for new recurring lines is not. The risk answer was yes: a contract with the company's largest customer requires that customer's data stay in-country. The horizon answer was stable: four people, perhaps five, for the foreseeable future. The first and third answers closed the cloud box. The second leaned towards a licence bought once. The question that remained was open-source against self-hosted commercial, and the two were trialled side by side for a fortnight. Dev's timesheet for the open-source install and first upgrade came to nineteen hours, which was within his budget. What settled it was the support row. Bellweather's depots work Saturdays and nobody on the desk wanted to be the person reading a forum at 07:30 on one. Bellweather chose a self-hosted commercial tool, licensed once. That was the right answer for that desk. For a desk with Dev's hours but without the Saturday depots, the other answer would have been just as right.

None of the three needed a suite, and that is the ordinary result for desks of this size. The suite box closes on the process row for almost every desk of one to ten. That is not because suites are poor but because a desk that size does not run the processes they implement. If your table leaves the suite open, check the process row again with the names of the people who own each process. If the names are all the same person, close it.

A Short War Story: The Two Tabs at Bellweather Logistics

Before Lena, Bellweather's ticketing tool had been chosen by her predecessor, Craig, in the time it took a trial sign-up page to load. A customer's complaint about a lost request had reached the operations director that morning, and Craig wanted a queue by the afternoon. He got one, a cloud help desk on a per-agent subscription, configured by lunchtime and never written about anywhere. Eighteen months later Bellweather signed its largest customer. The contract required that the customer's data, which was in every ticket about their deliveries, be kept on servers in the country. The cloud tool's data was not. Lena inherited the problem. The migration off the cloud tool took about a hundred and twenty hours of Dev's time over a quarter. Those hours were mostly spent on two discoveries. The export did not include attachments. The proof-of-delivery photographs in two years of tickets had to be retrieved one at a time. There was also a customer visit at which Omar explained why the deliveries history was temporarily incomplete. The four-minute decision had cost a quarter of Dev's hours and an afternoon of Omar's credibility. Lena's decision, the one with the sheet, took a fortnight. The sheet's third line, written before anything was signed, read "data: on the server named in the plan, in this building". That was the whole reason the contract could be kept.

The Decision Sheet

Fill this in before opening a trial page and finish it after the trial. File it with the exit plan where the next desk lead will find it. Every line is a fact about the desk or a thing you did, and none is a feeling about a tool. The feelings go in the reason line at the end, in one sentence, after the facts have had their say.

THE DECISION SHEET — FREE OR COMMERCIAL, ONE PAGE
Desk: ______________   People: ____   Tickets a week: ____   Filled in by: ________  on: ________

THE FOUR QUESTIONS
  Time:    hours per week protected for a server and its software: ____   whose: ________
           could that person upgrade a tool from its documentation alone?  [ ] yes  [ ] no
  Money:   recurring subscription approvable without a yearly round?       [ ] yes  [ ] no
           one-off sum possible from a capital or equipment budget?        [ ] yes  [ ] no
           who signs: ________
  Risk:    data in tickets that must stay on premises or in-country?       [ ] yes  what: ______
           contracted support required when the tool fails out of hours?   [ ] yes  [ ] no
  Horizon: years the answer must last: ____   desk size certain for that long?  [ ] yes  [ ] no

CATEGORIES AFTER THE QUESTIONS
  [ ] open-source, self-hosted     closed by: ______________  or open
  [ ] cloud help desk              closed by: ______________  or open
  [ ] self-hosted commercial       closed by: ______________  or open
  [ ] ITSM suite                   closed by: ______________  or open

THE TRIAL
  Candidate 1 (category ________): ______________   Candidate 2 (category ________): ______________
  Same tickets, same people, same fortnight:  [ ]
  Hours recorded during the trial:  candidate 1 ____   candidate 2 ____   by: ________
  Export run, opened and checked:   candidate 1 [ ]    candidate 2 [ ]
  Weights written before scoring:   [ ]   hard requirements listed first: ______________________

THE RESULT
  Five-year total in hours:  candidate 1 ______   candidate 2 ______   tied on cost?  [ ]
  Chosen: ______________   category: ______________
  The reason, in one sentence: ______________________________________________

THE EXIT PLAN
  Data lives at: ______________________   Export method: ______________   contents checked: [ ]
  Hours to leave, estimated: ____   (data ____  process ____  integrations ____)
  Yearly export scheduled for: ________   Decision revisited on: ________   by: ________
  This sheet filed at: ______________

Lena's sheet had three boxes closed by the first page and one line in the reason box. It read: "Dev has the hours, the contract needs the data here, and nobody wants to read a forum on a Saturday." Omar read it on the Monday, asked one question about the exit plan, and signed. The two tabs had taken four minutes to open. The sheet had taken a fortnight, and it was the only one of the three that would still make sense in three years.

After the Decision

The decision is the short part. What follows it is a quarter of ordinary work. That goes better if it is treated as a project with a date rather than a tool with a login. Set up the category's costs as calendar entries on day one. For a self-hosted tool, enter the server patches, the backup test and the upgrade window. For a subscription, enter the renewal checklist and the yearly export. For an open-source one, enter the quarterly project-health check. Those entries are the hidden costs made visible. A desk that creates them in the first week will never have to discover them in the way the earlier articles in this series describe. The broader method for selecting a particular tool runs from requirements through trial to the written decision. It is the whole of the Choosing a Ticketing System series. The move itself, with its cutover and its retraining, has a series of its own.

Put the revisit date in the calendar as well, a year out, with the sheet attached. The purpose of the revisit is not to reopen the decision but to check the facts it rested on. Does Dev still have the hours? Has the budget's shape changed? Does the customer contract still apply? Is the desk still four people? If the facts hold, the decision holds, and the revisit takes twenty minutes. If a fact has changed, the sheet shows exactly which row it affects. The desk can then act on one row rather than starting from two tabs. Free or commercial was never the question. The question was what was true about the desk. And the desk is the only thing on either page that will still be there next year.

Frequently Asked Questions

What if the four questions leave only one category open?
Then the category decision is made, and the work moves to choosing a tool inside it with a fair trial. One box left is a common result for very small desks and is not a failure of the method. Still write the sheet, record the hours during the trial and test the export. The exit plan matters most when there was no alternative.
What if the questions leave three or four categories open?
Check the answers for optimism, especially the time row and the horizon row, which desks most often answer with hopes rather than calendars. If they genuinely stay open, trial one tool from the two categories whose five-year totals are lowest. Then let risk, support and control decide between them. Do not trial four tools at once; nobody has the fortnight for it.
Can we start with a free tool and move to a commercial one later?
Yes, and many desks do, provided the move is planned rather than forced. Take a tested export from the first month, keep a runbook, watch the project's health quarterly, and set a revisit date. The migrations that hurt are the ones triggered by a security advisory or a departed administrator, not the ones scheduled on a calendar.
How long should the decision take?
Allow an afternoon for the four questions and the table. Allow a fortnight for a side-by-side trial of the two remaining candidates, and an hour to write the sheet and the exit plan. Three to four weeks in all, for a desk of one to ten. Longer usually means the questions were not answered honestly first; shorter usually means a tab was pressed.
Who should sign the decision sheet?
The desk lead who filled it in, the person who will run the server if there is one, and whoever controls the budget. Each confirms the row that is theirs: the hours, the technical answers and the money shape. A sheet signed by one person is one person's opinion; a sheet signed by three is a decision the organisation made.
When should we revisit the decision?
Revisit on a date set when the decision is made, a year out, and whenever one of the four facts changes. Those changes are the administrator leaving, the budget shape changing, a contract adding a data requirement, or the desk changing size. The revisit checks the facts, not the feelings. If the facts hold, it takes twenty minutes; if one has moved, the sheet shows which row to act on.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.