ServiceBeard

Sync your mailbox with your issue tracker

Productivity

Developer Tools

GitHub

Visit WebsiteSee on Product HuntGithub ⧉

Getting stuff out of the inbox and into where work actually gets tracked is a problem I feel weekly. When ServiceBeard syncs a mailbox to the issue tracker, how does it decide what's a real issue versus a one-off reply or a thank-you, and can I keep a two-way link so a comment on the issue lands back in the email thread? The round-trip is the part that makes or breaks these

Running a service desk out of Linear instead of paying per-seat for a helpdesk is exactly the tradeoff a small community/support team wants, especially self-hosted over IMAP. The loop I'd need to close before adopting: is the sync bidirectional — if I reply on the Linear issue, does that go back out to the customer over SMTP as an email, or is it inbound-only and I'm still answering from the mailbox? One-way would mean context lives in two places again, which is the exact problem I'd be adopting this to kill.

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.

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?

@Joram good to hear it's on the roadmap. if it helps at all, the case I'd prioritize testing first is a thread where a customer replies twice in a row before anyone on your team answers - that's the one that tends to break naive read/unread and two-way sync logic the hardest, way more than plain out-of-order delivery.

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!

Nice angle on using existing IMAP/SMTP plus the automation teams already have in GitHub, GitLab, or Linear instead of adding another per-seat support layer. One workflow question I would look for quickly as a user: how do you handle email threading and duplicate issue prevention when one conversation turns into multiple tickets or several teammates reply from the same mailbox?

Plugged it into a test repo and watched a support email land as a Linear issue without me touching anything, that part just works. The IMAP setup was surprisingly painless too.

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?

The framing of "we were managing a shared mailbox with colored labels" is a more honest starting point than most tools admit to haha

Finally something that doesn't force me to drag my team onto yet another per-seat subscription. Synced our shared inbox to Linear in a few minutes, and the IMAP setup was straightforward enough that I didn't need to bother our admin.

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

Finally a helpdesk tool that doesn't force per-seat pricing. Hooked it up to my Linear board over IMAP and had tickets flowing in within minutes, no need to migrate my whole team's setup.

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.