Helpdesk software: when to move off a shared inbox

A shared inbox is not a bad way to run support. It is fast to set up, everyone already knows how to use it, and for a small volume of email it is genuinely better than a ticket system, because nothing about the conversation is shaped by a tool.

It has one failure point, and it is a specific one: a shared inbox has no concept of ownership or state. Everything that goes wrong follows from that, and everything a helpdesk sells you is a solution to it.

Five triggers

Move when one of these becomes true, not before:

1. More than about three people answer. Below that, a quick word across the desk substitutes for assignment. Above it, two people reply to the same message in the same hour.
2. You have promised a response time. Once a number is in a contract or on your website, you need a timer that is not a person remembering.
3. You need to know what people are asking, not just answer it. Volume by topic is what tells you which help article to write, and an inbox cannot count.
4. Someone has to cover a holiday. Continuity requires state — what is open, what is waiting on the customer, what was promised.
5. You need an audit trail. Regulated work, consumer complaints, or a dispute where "what did we tell them and when" has to be answerable.

The symptoms, in the order they appear

• Two replies to the same customer, ten minutes apart, saying different things.
• "Did anyone answer this?" as a recurring message in your team chat.
• A customer forwards a thread you cannot find because it was answered from someone's personal address.
• Nobody can say how many requests came in last month, or what they were about.
• A request arrives by chat, gets a partial answer, and never rejoins the email thread.

What a helpdesk gives you

• Assignment and status. One owner, one state, visible to everyone.
• Timers. First response and resolution measured rather than remembered.
• Saved replies. The twenty answers you write every week, written once.
• A knowledge base. The only support investment that reduces volume instead of handling it — and, if it is public, one that earns search traffic.
• Reporting. Volume, topic, response time, backlog, per person and per week.
• History that survives people. The person who answered in March can leave in April.

What it costs you

• Per-agent pricing, usually with the useful automation a plan above the entry tier.
• A colder tone, if you let saved replies run the conversation instead of starting it.
• Migration of history — often the part vendors are quietest about.
• Conversations become tickets, which is exactly right for a support queue and slightly wrong for a long relationship with a large client.

The questions that decide the product

1. Does it keep your address? Customers should carry on writing to the address they already have, and threading must survive forwarding and quoting.
2. What happens to existing history? Ask specifically whether past email can be imported, and in what shape.
3. Which languages, on which side? The agent interface and the customer-facing pages are two separate questions.
4. Email only, or chat and voice too? Buying channels you are not staffed for is the most common overspend in this category.
5. Where does the knowledge base live? On your domain or the vendor's. If public help content is meant to earn traffic, this is not a detail.
6. How do you leave? Export of tickets, attachments and customer records, in a structured format.

Language matters more here than in most categories

Support is the one category where the software touches your customers directly. A Polish-speaking team can work in an English interface without much cost, but every customer-facing string — the portal, the automatic acknowledgement, the satisfaction survey, the help centre — has to be in the customer's language, and it has to sound like a person wrote it.

Our catalogue records Zendesk with a Polish interface; Freshdesk and Intercom are listed without one. None of the three is recorded as offering Polish-language support from the vendor, which is worth knowing before you rely on it during an incident.

A sensible sequence

1. Tidy the inbox first: one address, no personal replies, a shared signature. Some teams discover this was the whole problem.
2. Write the ten answers you send most often. You will need them whatever you buy, and they tell you how much of your volume is repetitive.
3. Pilot with email only, for a month, with your real traffic.
4. Add chat once the email flow is stable — not on day one, when it becomes a second unmanaged queue.
5. Publish the knowledge base before you measure deflection, and measure it against the same month last year if you can.

Most teams do not need a bigger helpdesk. They need the eight answers they repeat every week to exist as text somewhere a customer can find.

Start with the helpdesk and support category, and read the pricing pages with our guide to free plans and free trials open next to them — per-agent pricing in this category has more steps in it than most.