Web Dashboard

Scitor is built on top of GitHub Issues — that’s the source of truth, and nothing changes about that. Every ticket, every reply, every label still lives in your repository. Your team can keep working from the GitHub UI and everything continues to function.

app.scitor.io is an optional companion dashboard for when you want a support-team-shaped view of the same data: a single inbox-style screen with SLA timers, CRM context, AI drafting, a WYSIWYG editor, and team insights.

You don’t have to use it. You can. Many teams switch between it and the GitHub UI depending on what they’re doing.

What it gives you that GitHub doesn’t

GitHub Issues is excellent at code-adjacent collaboration. It’s not built to be a support inbox. The dashboard fills in the gaps:

Anything you do in the dashboard becomes a real GitHub comment / label / state change. The bot still picks up slash commands the same way (/send, /assign, /priority urgent, …) — they’re just inserted by the editor instead of typed manually.

The editor

The reply box is a WYSIWYG editor built on top of BlockNote (ProseMirror under the hood). You write the way you would in Notion: type / to open a slash menu, drag blocks around, format with the floating toolbar.

Outputs as clean markdown, which is exactly what GitHub expects when the comment is posted.

A Rich / .md toggle on the action row swaps the editor for a raw-markdown textarea when you want exact control over what GitHub sees.

Slash menu

Type / anywhere in the editor. Items appear grouped:

• AI — one-click “draft a reply using the ticket + KB”
• Templates — every saved reply in .github/scitor/replies/ shows up with its frontmatter description and tags as the subtitle
• Scitor commands — /send, /sendall, /assign @me, /priority urgent, /csat, /block-sender, /followup 3d, etc. — inserts the command text into the comment
• Formatting — headings, bullet lists, numbered lists, quotes, code blocks, dividers, links — same set BlockNote provides by default

The menu narrows as you keep typing, so /assi shows the assign variants only.

AI features

AI in the dashboard is optional and only enabled on paid plans. See AI Analysis for what runs on inbound triage. The dashboard adds a draft-side use case:

• AI draft — a gradient button below the editor and an item in the slash menu. Generates a complete reply from the ticket title + body, your current draft, and the top knowledge-base articles relevant to the question. Inserts the draft into the editor as proper blocks.
• Quick adjustments — open the AI dropdown (caret next to the button) for one-shot operations: make it more concise, make it more formal, make it friendlier, fix grammar, make it longer, make it shorter, summarize the ticket (good for internal notes).
• Knowledge-base grounded — the prompt always includes the top KB excerpts via AutoRAG. The response tells you how many articles it drew from (based on 3 KB articles next to the button after generation).
• Template variables — when the AI doesn’t know a value (the customer’s name, an order ID, etc.) it uses {{customer_name}}, {{order_id}}, etc. — the same syntax saved replies use. You fill these in before sending.

We never train on your data. See the AI Transparency page for the full policy.

Keyboard shortcuts

Press ? anywhere in the dashboard to see the full list. The basics:

The shortcuts ignore typing inside the editor and other text inputs, so they don’t fight you.

Insights

The Insights page replaces what other helpdesks call Reports. It shows:

• Tickets opened, SLA pass rate, average first response, average CSAT — top-line numbers
• Daily volume — stacked bar chart split by channel (email vs form)
• Channel mix — donut + weekday vs weekend split
• First response time — average / median / p90 (a long p90 with a healthy median means you have a tail of stuck tickets)
• Customer satisfaction — 1-5 distribution
• Top tags & categories — the labels driving your ticket volume (priority/sla/lang/sentiment/spam are filtered out so they don’t dominate)
• SLA by priority — pass rate, average first response, and breach counts per priority level. Configure under sla: in scitor.yaml to enable.
• Top reporters — GitHub accounts that opened tickets. The scitor-customerops[bot] row aggregates all email-ingested tickets; named accounts are agents who opened tickets manually or portal submissions.

Multi-user access

There’s no separate user list to manage. Access is bound to GitHub permissions on your support repo:

• Anyone with triage, write, maintain, or admin access to a repo Scitor is installed on can sign in to the dashboard.
• Off-boarding is implicit: remove someone from the GitHub repo and they lose dashboard access within ~60 seconds.
• The dashboard never asks for more GitHub permissions than the user already has on the repo.

If your team is on a GitHub Team / org, this means “give the new teammate triage on the support repo” is the entire onboarding step.

Themes

Light, dark, and system are all supported. The toggle is in the top-right of the dashboard header next to your avatar. The choice is persisted in localStorage per browser.

Plan availability

• Free — read-only access; reply via GitHub.
• Pro — full dashboard, AI drafting (50/day per installation), SLA, CSAT, CRM, Insights.
• Enterprise — everything in Pro, plus higher AI quotas (500/day), priority support.

See Pricing for current plan details.