Launched this week
Turn your customer-facing mailbox into an issue board. ServiceBeard syncs your emails directly to your issue tracker, letting you run a full service desk from your existing workspace. You can leverage the automation pipelines you’ve already set up without investing in expensive, per-seat helpdesk software. It's open-source, connects via standard IMAP/SMTP, and currently supports GitHub, GitLab, and Linear.
ServiceBeard
👋 Hi Product Hunt,
I'm Joram, the solo developer who built ServiceBeard.
My team was managing a shared mailbox by using coloured labels and read/unread statuses just to track who had replied to an email. Not ideal. Of course, this problem has been solved by proprietary service desk tools, but those often come with steep pricing models and heavy onboarding. That's why I built ServiceBeard.
It caters to teams who either can't or don't want to invest in yet another tool, or who prefer not to run commercial, proprietary software. It's fully functional with no limits or feature caps in the self-hosted version, and there is a managed cloud version that anyone can try for free.
I'm looking for honest, early feedback: is this something you'd use? What could be improved, and what features should be added? I'd love to hear your thoughts!
@hongaar Hi Joram, the mailbox-to-tracker gap is where half my support context goes to die. When a customer replies "actually it's still broken" four emails deep, does that thread onto the existing issue or spawn a new one? Curious how you decide what counts as a duplicate versus a genuinely new report, because that call is usually where these tools live or die.
ServiceBeard
@artem_fedorovich Replies to previous emails will always trigger a comment instead of a new issue, several strategies are implemented to make sure that if one method fails (e.g. In-Reply-To header missing), the next one (e.g. subject+sender lookup) tries to match existing threads. Thanks for checking out ServiceBeard!
Congrats on the launch, @ServiceBeard The shared mailbox struggle is incredibly real, and building a bridge straight into developer tools like Linear and GitLab completely cuts out the context-switching friction.
What stands out here is the ability to inherit existing automation pipelines. When a ticket is updated inside the issue tracker, does the two-way sync support mapping custom workflow statuses (like "In QA" or "Scheduled for Deploy") back to automated customer email notifications, or does it strictly trigger updates on the initial creation and the final closing of the issue?
Love the zero-bloat approach to service desk operations!
ServiceBeard
@varunvivek Label or status changes do not trigger updates back to the customer currently, only public comments do. I know other products support this, but I didn't want to make it too 'chatty'. Is this a feature you'd like to see in a product like ServiceBeard?
@hongaar Definitely would love to see a feasible re‑imagination here—status‑based notifications as opt‑in rules could be a game‑changer while keeping the zero‑bloat ethos intact.
the "we manage a shared mailbox with color labels because zendesk feels overkill" problem is exactly where 90% of small teams live and none of the enterprise tools acknowledge exists.
real q: does the mailbox-to-issue mapping keep both threaded? asking because most sync tools drop the email thread after the first ticket creation and then agents context-switch between two tabs to reconstruct the conversation history.
ServiceBeard
@thenameisarian ServiceBeard will try its best to keep conversations threaded in both mailbox and issue tracker, and I'm using layered strategies to detect the conversation a message should be part of: by In-Reply-To, then References, then subject+sender. Great question!
How does it handle email threads where multiple customers are CC'd, do those get split out into separate tickets automatically or linked together somehow?
ServiceBeard
@tunahan7j2k Interesting edge case. ServiceBeard will create a single conversation and a single issue from this incoming email, it doesn't use CC'd addresses to create additional tickets or links at the moment. How would you expect or want this to work?
solo dev building a self-hosted option instead of the usual SaaS-only route is the right call for this. what happens when a customer replies weeks after the linked issue got closed - does it reopen the old issue or spawn an orphaned one?
ServiceBeard
@sabber_ahamed both are supported - this is configurable per Project Rule (so e.g. bug reports can have different behaviour than feature suggestions). Great question!
the threading answers cover inbound well. what about the reverse direction - if a dev replies to the issue inside GitHub/GitLab/Linear instead of going back to the mailbox, does that comment actually go out as a real email to the customer maintaining the thread, or does it just sit in the tracker until someone manually copies it back into an email? that gap is usually where teams quietly go back to just replying from the inbox directly.
ServiceBeard
@galdayan comments on the issue tracker are sent back to the customer through email (delivery through your own SMTP server), unless marked as internal. Thanks for checking out ServiceBeard!
@hongaar good, that's the direction that actually matters for it to feel like one thread instead of two systems awkwardly synced. that answers it, thanks
syncing mailbox to issue tracker isn't new (Zendesk, Front, even Gmail+Zapier have done this for years), so the pitch really comes down to how clean the two-way sync stays once a thread gets messy - CC'd people, forwarded emails, someone replying from a different address. that's usually where these integrations start creating duplicate or orphaned tickets
ServiceBeard
@omri_ben_shoham1 Tested some of these scenario's, but not in an as structured way as I'd like. I'm going to to put more (automated) testing towards this. Thanks for raising this!