The shared inbox worked for a long time. Then two people answered the same enquiry within an hour of each other and said slightly different things. Then one sat for four days because both assumed the other had it. Nobody did anything wrong, and there is no process change that fixes it, because the inbox has no way to record who picked something up.
That is the point at which teams start looking for inquiry management software, and the search immediately runs into a category problem. The results are a mix of full help desk platforms built for support teams of twenty, lightweight shared inbox tools, CRM modules, and form builders that have added a response list. They are priced differently, they assume different volumes, and they are not competing for the same job.
What the shared inbox is missing
Three specific things, and it helps to separate them because different tools solve different subsets.
There is no owner. An email in a shared mailbox belongs to everybody, which operationally means nobody. Read and unread is not ownership: one person reading a message marks it read for the whole team, which actively hides work rather than assigning it.
There is no state. An enquiry that is waiting on a quote looks identical to one that is finished and one that nobody has opened. The only way to tell is to read the thread, so the only way to check the queue is to read everything in it.
There is no record after the fact. Six months later, when somebody asks what was agreed with a particular customer, the answer lives in whichever mailbox still holds the thread. If that person has left, it does not live anywhere.
Folders and labels are the usual first attempt at fixing this, and they fix the second problem partially and the other two not at all. That is worth knowing before paying for software, because a tool that only adds tidier folders will not change the outcome.
The five jobs the software has to do
Strip the feature lists back and the same five capabilities decide whether a tool solves the problem.
One record per enquiry. Every message, reply and internal note about one request sits in one place, and that place has an identifier somebody can refer to. Without this, everything else is decoration.
An owner on each record. Explicitly set, visible to the team, changeable. The double reply and the four day silence both come from the absence of this single field.
A status that means something to your team. New, replying, waiting on the customer, done. The exact list matters less than the fact that it is visible without opening the record, because that is what turns a pile into a queue.
The reply sent from the same screen. If answering means switching to an email client, the record will be incomplete, because the reply lives in the mail client and only sometimes gets copied back. This is the requirement people underweight and regret.
A history that survives staff changes. Status changes, owner changes, notes and sends, kept in order and readable by anybody with access.
Everything past those five is genuinely optional for a small team. Knowledge bases, chat widgets, satisfaction surveys and AI triage are all real features that solve real problems at larger volumes, and none of them address why the enquiry sat for four days.
Help desk or form tool: the fork in the road
The choice usually comes down to where the enquiries arrive from.
If they arrive by email, to an address customers already have, a help desk is the natural shape. It takes the mailbox, turns each thread into a ticket, and works in the vocabulary of support teams.
If they arrive through a form on your site, the calculation changes. A help desk will accept form submissions, usually by having the form email the ticket address, but the structure of the submission is lost in the process: the answers arrive as a block of text in a message body rather than as fields. Anything you wanted to filter or sort by has to be parsed back out.
A form tool with response management starts from the other end. The submission is already structured, every answer is already a field, and the tool adds the owner, the status and the reply on top. Tools of this shape are described across these use cases, and support requests and quote requests are among them.
The practical test is what proportion of your enquiries come through a form. If most of them do, the form side is where the record should live, and routing them through email to a ticketing system throws away structure you already had. If most arrive as free email from addresses you do not control, a help desk is doing something the form tool cannot.
What the market charges
Published prices for the tools that come up most often, checked against each vendor's own pricing page. All figures are per agent or per user, per month, on annual billing.
| Tool | Entry plan | Next plan up |
|---|---|---|
| Zendesk | Support Team, $19 | Suite Team, $55 |
| Freshdesk | Growth, $19 | Pro, $55 |
| Help Scout | Standard, $25 | Plus, $45 |
Two details behind the table matter more than the headline numbers.
Help Scout publishes a free plan covering 5 users, 1 inbox and 1 Docs site, which is a genuine option for a team that only needs one queue. Additional inboxes beyond the plan allowance are listed at $10 per month on annual billing.
AI capabilities are mostly priced separately. Zendesk lists a Copilot add on at $50 per agent per month. Freshdesk lists Freddy AI Copilot at $29 per agent per month. Help Scout prices AI Answers at $0.75 per resolution. If the AI features are the reason a tool made the shortlist, the real monthly figure is the plan plus the add on.
Form tools with response management are priced on a different axis. Rather than charging per agent with tiers that gate the queue features, some are priced only by how many people are in the workspace, with no cap on forms or on responses. That produces a flatter curve as volume grows and a steeper one as headcount grows, which is the opposite trade off to a per agent help desk. Comparing the two fairly means putting your own headcount and your own monthly enquiry volume into both, which is what the pricing page of any candidate is for.
Getting the statuses right the first time
Whichever tool wins, the statuses are the part you configure yourself, and they are easy to get wrong in a way that takes months to notice.
The common mistake is too many. A list of twelve statuses feels thorough at setup and produces a queue where half the items sit in states nobody remembers the rule for. Four to six is usually the working range, and the test for whether a status earns its place is whether a different action follows from it. If two statuses lead to exactly the same next step, they are one status.
The second mistake is having no state for waiting on the customer. Without it, an enquiry where the ball is in their court looks identical to one you have not touched, so it keeps surfacing as outstanding work and eventually gets marked done to clear the noise. That is how enquiries disappear.
The third is closing too early. A status called done should mean the customer has what they asked for, not that a reply was sent. Teams that conflate the two end up with a queue that looks healthy and a set of customers waiting on follow up nobody is tracking.
Write the list on paper before configuring anything, with the next action next to each state. Any state without a clear next action is one to cut.
What to check before moving
Four things are worth confirming before the migration rather than after.
How the existing history comes across. Most tools import from CSV. What differs is whether the import maps to structured fields or dumps everything into one note. Ask specifically whether answers land as fields, because that determines whether the imported records are searchable in the same way as the new ones.
Whether replies reach the inbox. A tool that sends on your behalf from a shared domain will land in spam more often than one that sends from your own domain with the authentication records in place. If the vendor offers sending from a custom domain, find out which plan it starts on. This is the difference between an enquiry system that works and one that quietly does not.
Who can see what. A view only role matters more than it sounds, because it is what lets a manager or a colleague from another team look at the queue without being able to change a status by accident. Check the number of permission levels and what each one can do.
Where the data sits and what happens when you leave. Which country the data is held in, whether uploaded files are protected behind a sign in rather than an unguessable link, and whether a full export is available on the plan you are buying. The export question is the one people skip and regret, because it determines whether the next migration is possible at all. The features list is where these answers usually are, and the ones that are not there are worth asking about directly.
The features that look essential and are not
Three things dominate the comparison pages and rarely decide anything for a team under about ten people.
A knowledge base is a content project, not a software feature. Every tool in the table has one. None of them will write it, and an empty knowledge base deflects nothing. If the content does not exist yet, this should not influence the choice.
Automated routing rules assume enough volume for the rules to be worth writing. Below a certain daily count, one person assigning owners by eye is faster, more accurate and considerably easier to change.
Satisfaction surveys generate a metric that only becomes useful when there is enough of it to see a trend. For a team answering a handful of enquiries a day, the sample is too small to act on and the request adds a step to every interaction.
What does deserve weight in the decision: whether the reply is sent from the same screen as the record, whether you can tell at a glance what is outstanding, and whether the export gets your data back out. Those three predict whether the tool is still in use in a year.
What to change first
Pick the smallest tool that gives every enquiry an owner and a status, and make sure replies go out from inside it rather than from a mail client. If most of your enquiries arrive through a form, start on the form side rather than converting them into email first. Open a demo response list in Halict and run a week of real enquiries through it before signing anything annual.
Q1. Is a shared inbox enough for a small team?
It works while one person handles everything. It stops working the moment two people can answer, because a shared mailbox has no field for who picked something up. Read and unread is shared across the team, so one person opening a message hides it from everybody else rather than claiming it.
Q2. What is the difference between inquiry management software and a help desk?
Help desks are built around email threads becoming tickets, with features aimed at support teams: knowledge bases, routing rules, satisfaction surveys. Inquiry management is the narrower job of giving each request an owner, a status, and a reply from one place. A help desk does that job and a good deal more, which is reflected in the price.
Q3. Can form submissions be handled in a help desk?
Yes, usually by having the form send an email to the ticket address. The trade off is that the structured answers arrive as text in a message body, so anything you wanted to filter or sort by has to be parsed back out. If most enquiries come through forms, keeping them as structured responses is generally less work.
Q4. How much should a small team expect to pay?
Entry plans among the widely used help desks sit around $19 to $25 per agent per month on annual billing, with the next tier roughly doubling that. AI features are typically priced as separate add ons on top. A free tier exists in some products, usually limited to one queue.
Q5. Does AI triage help at low volume?
It needs a body of past enquiries to work from and enough daily volume for the time saved to exceed the time spent supervising it. For a team handling a handful of enquiries a day, a human reading each one is faster and more accurate, and the add on cost is real money from the first month.
Q6. What matters most when comparing tools?
Whether replies are sent from the same screen as the record, whether the queue is readable without opening each item, and whether a complete export is available on the plan being purchased. Those three determine whether the tool holds up over time and whether leaving it later is possible.