Should you build your own helpdesk?

The short answer

Don't build this one. The ticket list is easy. Getting email in and out reliably is not, and that's most of the work. Use an open-source helpdesk like Zammad or FreeScout, or pay for one. The only build worth doing is a small internal request queue, which a coding agent can put together in a few days.

What you're deciding

Most helpdesks start as a shared mailbox. Three people read support@ and reply. Then two of them answer the same customer. One email sits for a week. Nobody can say how long replies take.

A helpdesk fixes that. Each request becomes a ticket with one owner and a status. Replies you send a lot get saved. Questions you answer a lot go into a help center.

The ticket list is the easy part. The hard part is email. It has to come in without getting lost, stay in the right thread, and go out without landing in spam. Open-source helpdesks have been solving that for years. Zammad, FreeScout, osTicket and Chatwoot all run on your own server today. So the real decision is which one to use, and whether a small custom piece on top is worth it.

What owning a helpdesk takes

A helpdesk is big on all three counts. Even a small team soon wants assignment rules, response-time targets, saved replies, internal notes and reporting. When it breaks, it breaks quietly: an email gets dropped, a customer waits, and nobody notices until they complain. And it depends on things you don't control, like Google and Microsoft mail accounts, your email reputation, and chat tools that change their rules. The one exception is a small internal queue, like IT or HR requests from one form. That's a few days with a coding agent.

Your version may be smaller or bigger than this, which is what the quiz at the bottom asks about.

Borrow: open-source options

Open source gives you the code, not the operations. Someone still installs it, updates it, backs it up and supports your team, or you pay a host to.

Which one to start with

If support is mostly email, start with FreeScout. It's light and runs on cheap PHP hosting. If you also need chat, messaging and a help center in one tool, Zammad. osTicket suits internal IT queues sorted by topic and department. Chatwoot suits teams whose support is mostly live chat and messaging apps. A test install takes an afternoon with Docker or a one-click host. Getting it ready for real use takes a few days: connecting the mailbox, setting up the email records that keep you out of spam, backups, sign-in, and moving your saved replies across. After that, budget a little time each month for updates.

Buy: paid services

We list pricing models, not prices, because prices change. Nobody pays to be listed here. Check each vendor's current plans before you compare.

Build it yourself

Build when the queue is internal, requests come from one or two places you control, and it never has to email the outside world. An IT or facilities queue fed by one web form and a Slack command. An HR request tracker for one team. Because you own the intake, you skip the email problems entirely. The tool needs tickets, owners, statuses, internal notes and a due date. A coding agent can do that in a few days. For the help center, link to the wiki you already have. If customers will email you, or you need chat widgets, buy or borrow instead and build small add-ons through the API.

What a demo won't show you

• Email threading. A reply has to attach to the right ticket. Email clients handle this differently, and when it goes wrong one conversation turns into five tickets.
• Getting delivered. Your replies need the right DNS records (SPF, DKIM and DMARC) and handling for bounces and out-of-office replies. Without that, your answers land in spam and you never find out.
• Connecting the mailbox. Google and Microsoft 365 want you to sign in with OAuth, not a password. That means tokens that expire, consent screens, and syncing that survives an outage without losing or duplicating mail.
• Response-time clocks. First-reply and resolution timers need business hours, holidays, time zones, and a pause while you wait on the customer. The escalation alert has to fire exactly once.
• Two people on one ticket. Agents need to see who else has it open, and assignment rules have to skip people who are out.
• Messy inbound mail. Quoted history, signatures, inline images, big attachments and HTML-only messages all have to render cleanly and be stored safely.

A build brief for an AI coding agent

Paste this into Claude Code or any coding agent. Swap in your own systems wherever it names ours or shows a placeholder, and keep it to this scope.

Job: build an internal request queue for our team so every request has one owner, a status and a due date.
Inputs: submissions from one web form (requester name, work email, category, description, optional attachment).
Outputs: a ticket list with filters by status, owner and category, plus a ticket page with the history and internal notes.
Must-haves: assign to a person, statuses (new, open, waiting, done), a due date set from category, saved reply snippets, and a daily digest of overdue tickets.
Notifications: tell the requester by Slack or by email from our existing mail system. Do not build an email server.
Out of scope: reading inbound email, customer-facing chat, a knowledge base, multi-team routing, and AI auto-replies.
Data and privacy: store data only in our approved database, sign in through our company SSO, never log request text or attachments to third-party services, and keep an export to CSV.
Access: requesters see only their own tickets. The team sees all tickets.
Test: take one real request from last week, submit it through the form, assign it, add a note, mark it done, and confirm the requester was notified and the digest lists it while overdue.
Fallback: if this is not working well after two weeks, export the CSV and import it into an open-source helpdesk such as Zammad or osTicket.

Common traps

• Turning a shared Gmail or Outlook inbox into a helpdesk with labels and rules. It works until volume doubles. Then there's no owner field, no response clock, no reporting, and years of threads to move out.
• Self-hosting without planning email. Most problems teams blame on the helpdesk are really the mailbox connection, the DNS records, or a server with a bad sending reputation. Test sending and receiving with real Google and Microsoft accounts before launch.
• Avoiding Zammad or FreeScout because of the AGPL license. Using them as they are for your own support doesn't force you to publish anything. The obligations kick in if you change the code and offer it to others over the internet. Check with a lawyer before you fork.
• Paying for channels you don't use. Plenty of teams pay for social, voice and messaging tiers when nearly all their requests are email and one web form. Count where last quarter's requests came from first.
• Ignoring the exit. Before you commit, check you can export tickets, attachments, saved replies and help articles in a usable format, and that the API lets you move history.

Last reviewed October 27, 2026. Licenses and hosting checked against each project's own site or repository.