Requests are arriving in three places. Some by mail to an address two people watch, some through a form on the site that drops rows into a spreadsheet, and some by message to whoever the person happened to know. Nobody can say how many are open. There is no budget for a help desk this quarter, and the search that follows is for something free.
Free in this category means at least three different things, and they fail in different ways. One is a capped tier of a paid product. One is open source software somebody has to run. One is a free component of a larger suite that exists to introduce the rest of it. Choosing badly is not expensive in money, which is exactly why it costs so much time. What follows sets out where each kind of free ends.
Three kinds of free
A free tier of a commercial product is complete software with a limit drawn around it. The limit is usually the number of people, occasionally the number of channels, and the upgrade path is deliberate and smooth. The software will not be abandoned and will not need patching by anyone on the team. What it will do is stop fitting, on a schedule set by hiring rather than by anything technical.
Open source, self-hosted software has no seat limit and no feature held back. The cost moves to hosting, upgrades, backups, mail deliverability and whoever ends up owning all four. That cost is real and is paid in hours by a person who probably has another job.
A free component of a suite is the narrowest of the three. It works, and it is designed so that the interesting parts sit one tier up. That is a legitimate way to sell software and a poor basis for a plan that assumes the free part will keep being enough.
None of the three is a trap. They are three different bets: that the team stays small, that somebody will maintain a server, or that the suite is where the team wants to end up anyway.
Where the seat cap sits
On the free tiers of commercial products, the cap is almost always people, and the numbers are specific enough to plan against.
Zoho Desk's free edition is described on its pricing page as offering three user licences, with the page summarising the edition as easy email ticketing out of the box. Its own pricing notes put the same point plainly: the free edition gives 3 users with limited capabilities. Help Scout lists a free plan for up to 5 users before its first paid tier at $25 per user per month.
Three or five users sounds like a lot when two people are drowning. It stops sounding like a lot the moment the definition of a user is examined, because a user is usually anyone who needs to see or touch a request, not only the people doing the bulk of the work. A manager who wants the queue visible is a seat. A colleague in another team who handles one category of request is a seat. Teams reach a three seat cap faster than they expect, and the jump out of it is not to a slightly bigger free plan.
Count the people who need to see, not the people who reply
The practical planning number is the count of people who would need an account within a year, including occasional handlers and anyone who needs visibility without replying. Where that count is already above five, the free tiers of commercial help desks are a trial rather than a solution, and the comparison worth doing is between paid tiers.
What gets held back, and which of it matters
Feature limits on free tiers cluster in predictable places. On Zoho Desk's free edition, the pricing page lists a set of capabilities as belonging to paid tiers, including service level agreements, automation workflows, custom domains, a knowledge base, telephony and multi-department organisation.
Some of those absences are survivable for a long time and some are not.
Service level agreements and automation are the two that decide whether a queue stays honest. Without them, nothing in the software knows that a request has been sitting for four days, so the only thing keeping requests moving is a person remembering to look. That works until the volume passes what one person can hold in their head, and it fails silently rather than loudly.
A custom domain matters less than it looks in most internal cases and quite a lot for anything customer facing, because the address a reply comes from is read as a statement about who is answering.
Multiple departments matter if the requests genuinely split into streams with different handlers. Where they do, running them all in a single undifferentiated queue is the thing people describe afterwards as the software not working.
A knowledge base and telephony are usually further down the list. They are additions to a working process rather than parts of one.
Self-hosted free, priced in hours
The self-hosted route removes both the seat cap and the feature limit, which is a genuinely different offer. The obligations that replace them are concrete and worth reading before committing.
osTicket publishes its download as free open source software and states server requirements: Apache or IIS as the web server, MySQL 5.5 or later, and PHP in the 8.1 to 8.2 range for its 1.18 series. Those are ordinary requirements, and they are also a standing commitment, because PHP versions reach end of life and the application has to be moved when they do. The same project also offers a hosted commercial option with a 30 day free trial and no card required, which is a reasonable signal of where the effort goes if nobody wants to run a server.
FreeScout describes itself as a free open source help desk and shared inbox built with PHP on the Laravel framework, and notes that it can be deployed even on shared hosting. Its own model puts the core application at no cost and sells optional modules on top, so a self-hosted plan should be costed with the modules the team will actually want rather than with the core alone.
| Route | Seat limit | What is paid instead |
|---|---|---|
| Zoho Desk free edition | 3 user licences | Features held for paid tiers, including SLAs and automation |
| Help Scout free plan | Up to 5 users | Upgrade at $25 per user per month when the cap is reached |
| osTicket, self-hosted | None | Hosting, PHP and MySQL upgrades, backups, mail deliverability |
| FreeScout, self-hosted | None | The same operational work, plus paid modules for extras |
The honest comparison is not price against price. It is a seat cap against a maintenance obligation. A team with somebody who genuinely enjoys running a server has a real free option. A team without one does not, whatever the licence says.
The exit, checked before the entrance
The cost of free software is rarely in the adoption. It is in the leaving, and free tiers are where teams are least likely to look at that in advance, because nothing has been spent and it feels as though nothing is at stake.
Three checks are worth doing before the first request goes in. Whether the history can be exported in a form that another tool could read, rather than only viewed on screen. Whether the exported history includes who handled each request and when, since assignment history is the part that gets dropped and the part that matters in a handover. And what happens to the data if the account lapses or the free tier is discontinued, which is a question with a written answer in most terms and no answer at all in habit.
The same check has a self-hosted version. The data is in a database on a server somebody controls, which is the strongest possible position, provided that a backup exists and that somebody has restored one at least once. An untested backup is a belief, not a safeguard.
There is a smaller and more immediate exit to plan for as well. Requests currently arriving by mail to an address two people watch will keep arriving there for months after the new system starts, because senders use the address they used last time. Deciding in advance whether that address forwards into the new queue or gets an automatic reply pointing at the form is the difference between one intake and two running in parallel, and two running in parallel is how the original problem comes back.
When the request is a form, not a ticket
There is a mismatch worth naming before any of this gets installed. Help desk software assumes the request arrives as prose from a person, usually by mail, and that the useful unit is a conversation. A large share of service requests do not arrive that way. They arrive as a form: a named field for the site, the asset, the date needed, the approver.
Where the intake is structured, a ticketing system holds it awkwardly. The fields end up pasted into a description, or attached as a link to a spreadsheet row that the ticket does not contain. The status then exists twice, once on the ticket and once on the row, and the two disagree within a fortnight. Anyone who has tried to answer how many requests of a given type came in last month from a ticket queue built this way knows how that ends.
The alternative is to keep the request in the shape it arrived in. A form tool with response management holds the structured submission and gives it an owner and a status, and the reply goes out against the submission itself rather than from a separate mailbox. The request stays queryable because its fields are still fields. Tools of this kind also tend to be priced on the number of people using them rather than on request volume, which removes the other thing that makes free tiers awkward: a busy month that suddenly costs money. Comparing what that looks like for different intake types is easiest from worked examples, and the use cases page is arranged that way.
This is not an argument against ticketing software. It is an argument for matching the tool to the shape of the intake, which is a question nobody asks while comparing free plans.
What to change first
Count the people who would need an account within a year, including those who only need visibility, because that number decides whether any free tier is a solution or a trial. Then look at how requests actually arrive, in prose or in fields, and pick the shape that matches rather than the licence that is cheapest. Where the requests come in through a form and the queue is currently a spreadsheet, the quickest comparison is the demo of a form tool such as Halict against the free tier being considered.
Q1. Is free service request management software good enough for a small team?
It is, for as long as the team fits inside the cap and the queue is small enough to be kept honest by a person looking at it. Zoho Desk's free edition allows three user licences and Help Scout's free plan allows up to five users, which is workable for a couple of handlers. The limits that hurt first are usually the absence of automation and service level rules rather than the seat count.
Q2. What is the catch with a free help desk?
On commercial free tiers the catch is stated openly: a user cap and a set of features reserved for paid plans, typically including service level agreements, automation and a custom domain. On self-hosted open source there is no catch in the licence, and the cost moves to hosting, version upgrades, backups and mail deliverability. Neither is hidden, and both are easy to underestimate.
Q3. Is self-hosted open source actually free?
The software is, and the running of it is not. osTicket states requirements including Apache or IIS, MySQL 5.5 or later and PHP 8.1 to 8.2 for its current series, all of which need maintaining as versions age. FreeScout's core is free with optional paid modules, so a realistic cost includes whichever modules the team ends up wanting.
Q4. Can a spreadsheet work instead of service request software?
A spreadsheet holds the records and cannot hold the process, which is why it fails at the same two points every time: two people edit it at once, and nothing in it knows a request has gone unanswered for a week. It is a reasonable place to start and a poor place to stay once more than one person is handling requests. The first thing to replace is not the storage but the assignment.
Q5. Should service requests come in by email or by form?
A form produces structured fields, which makes requests comparable, reportable and easier to route correctly the first time. Email produces prose, which is friendlier to the sender and much harder to work with in volume. Where a form is the intake, keeping the submission and the reply in the same place avoids the split status that comes from pasting form fields into a ticket.