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.
| Question | A yes points to | A no points to |
|---|---|---|
| Does someone already run a server here, with hours protected for it each week? | Self-hosted, either kind | Cloud 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 possible | Self-hosted commercial or cloud |
| Does the organisation approve recurring monthly spend without a yearly procurement round? | Subscription models are easy | Licensed once, or open source |
| Is there a capital or equipment budget that could carry a one-off sum this year? | Licensed once is possible | Subscription or open source |
| Do the tickets hold data that must stay on your premises or in your country? | Self-hosted, either kind | Any category |
| When the mail connection fails on a Friday afternoon, must a contracted person be obliged to help? | Commercial, either kind | Open source is possible |
| Do you need to change how the tool works, not just configure it? | Open source | Any category |
| Does the organisation run several formal IT processes with named owners today? | An ITSM suite is possible | A 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 safe | Short terms; cheapest to leave |
| Has a full export from the candidate been run, opened and checked? | The candidate may be chosen | Not 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?
What if the questions leave three or four categories open?
Can we start with a free tool and move to a commercial one later?
How long should the decision take?
Who should sign the decision sheet?
When should we revisit the decision?
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.
