For open source maintainers
You're already running a help desk. Give it a queue of its own.
"How do I configure X?" and "this doesn't work on my machine" arrive by email, in Discord, as GitHub Issues, in DMs — mixed in with the actual bug reports and PRs you're trying to review. Scitor gives that traffic a dedicated repository, so it stops crowding your project's real Issue tracker.
The fragmentation is the problem, not the volume
Maintainer burnout writing consistently points at the same root cause: support requests don't arrive in one place. They land wherever a user happened to find you — a GitHub Issue, a random email, a Discord ping — and each channel has to be checked separately, with no shared history. The fix maintainers describe isn't "answer faster," it's "put this somewhere specific, separate from the bug tracker."
Scitor's setup already assumes that split: a dedicated support repository, distinct from your project's code repository. Support email gets forwarded to a Scitor address, and every message becomes a GitHub Issue (or a Discussion, if you'd rather let community members jump in on Q&A-style questions) in that repo — not mixed into the Issues where your actual bug reports and feature requests live.
What actually changes
Support mail gets a queue of its own
A user emails your project's support address instead of DMing you or filing an Issue on the main repo. Keep that inbox and forward messages over, or point it straight at Scitor — either way, the message becomes a ticket in the dedicated support repo, with the sender and any attachments attached automatically.
Low-effort noise gets filtered before you see it
Repeat senders or spam get blocked with a single /block-sender command on any ticket — future messages from that address are silently dropped, so you're not re-triaging the same noise every week.
Questions can go to Discussions, so the community can help
Set integration: discussions in .github/scitor.yaml and inbound messages become Discussions instead of Issues — a format where other contributors and users can answer without you being the only one who ever replies.
AI triage runs before you open anything (Pro plan, opt-in)
With AI triage enabled on the Pro plan, every inbound message gets a one-line summary, a sentiment read, and a category label (bug report, feature request, billing, etc.) automatically, so you can filter for what actually needs your attention instead of reading every message in order. See Agentic Workflows for what else can run on top of that triage — weekly reports, draft replies, escalation summaries.
What this doesn't solve
This only centralizes the channels that can reach a GitHub App: email and an embeddable web form. It doesn't pull messages out of Discord, X/Twitter, or a project Slack — if that's where most of your support load actually lands, you'd still need to redirect people to your support email or form manually, or accept that those channels stay outside Scitor entirely. And it doesn't reduce the volume of questions; it gives them one address and one queue instead of five.
Is this actually for your project?
Not every maintainer needs this. Here is an honest breakdown.
This is for you if:
- You maintain a repo on GitHub already
- Support requests are scattered across Issues, email, DMs, or Discord
- You're doing this unpaid or on the side, and want less to check daily
- You'd rather not add a second account or tool just for support
- Support requests are drowning out your actual Issue tracker
Not for you if:
- You need phone or live chat
- You handle support across social media
- You have 50+ agents
- Your team does not use GitHub
- Most of your support load is in Discord or a chat community, not email
Weighing self-hosting a helpdesk instead? Read the honest trade-off on open-source, self-hosted alternatives — the short version is you'd trade this fragmentation problem for a server to run.
Questions maintainers ask
- Does this replace GitHub Issues for bug tracking?
- No. Scitor is meant to run in a separate, dedicated repository from your project's code — support email becomes Issues (or Discussions) there, kept apart from the bug/feature Issues in your actual project repo. Your existing Issue tracker doesn't change at all.
- What do I need to get started?
- A GitHub repository with Issues enabled. We recommend a dedicated support repository so your product code stays separate. Install the Scitor GitHub App, and you'll receive a unique email address to forward your support emails to.
- How is spam handled?
- You can block specific senders with the /block-sender command on any Issue. Future emails from that sender are silently dropped. Your email provider's built-in spam filtering also applies before messages reach Scitor.
- Can I use Discussions instead of Issues?
- Yes. Add a .github/scitor.yaml file to your repository with integration: discussions. Incoming messages will create Discussions instead of Issues, which is better for Q&A-style threads where community members can also help answer.
- Is the Free plan actually usable for a real project, or is it a trial?
- It's not a trial — the Free plan is $0/month with no time limit: unlimited inbound email, GitHub Issues & Discussions, slash commands, the web form widget, spam detection, and attachment handling, with a cap of 100 outbound replies per month. For a project fielding a moderate volume of support questions, that's often enough on its own.
Give your support requests a home of their own
The Free plan is $0/month, no credit card required. Takes under 5 minutes to connect.