In design · open-source Rust core and hosted agent, both planned

Support that answers.
When it can't, it routes the issue to the right people, where they already work.

SupportGenius is a planned AI support agent. It would answer from your docs, tickets and files, by text or voice, and turn anything it cannot answer into a ticket for support, a lead for sales, or a GitHub issue with reproduction steps for engineering. You would embed a widget, drop the iOS or Android SDK into your app, connect a phone number, call the API, or let your own agents use it as a tool.

Join the waitlist See the idea
<script src="https://supportgeni.us/w.js" data-key="sg_live_…"></script> planned

The intended one-line embed. It does not work yet: there is no w.js and there are no keys.

  • Widget
  • REST API
  • iOS · Android SDK
  • Phone line
  • MCP server for agents
illustration · sample data

An animated illustration of three sample conversations. On a web widget, a customer asks how to change a billing address and is answered from the billing docs. In an iOS app, a customer reports that the export button returns a 500 on large CSVs; with no fix in the docs, the agent files a GitHub issue with reproduction steps and severity high, and the same escalation is shown landing in Jira, Linear, Zendesk and with an on-call person. On a phone call, a customer asks about volume pricing for 50 seats, and the agent passes a lead to Salesforce.

Illustration with sample data. Nothing here is connected to a product, because there is no product yet.

HOW IT WOULD WORK planned

Three steps. One script tag.

  1. 01

    Connect your sources

    Docs URL, help center, uploaded files, past tickets, indexed and kept in sync.

  2. 02

    Pick a surface

    One script tag would add the widget, with text and voice. Native iOS and Android SDKs for your apps. A phone number, yours or a new one, that the agent answers. The API, from your own UI. Or an MCP tool, so your own agents can answer and escalate too.

  3. 03

    Choose where escalations go

    Engineering bugs to GitHub, Jira or Linear. Support tickets to Zendesk. Leads to Salesforce. A person on the mobile app or through the API. Or the built-in open-source ticketing.

FEATURES

Answers it can back up. Escalations engineers can act on.

What SupportGenius is being designed to do. None of it is built; every card is a plan.

planned

Answers with citations

Every reply would link the doc, ticket or file it came from.

planned

Voice conversations

Customers would talk instead of type, and the agent would reply with speech.

planned

Phone line

Connect your existing number or get a new one. The same agent would answer calls, escalate and hand over to a person, with the call transcribed into the ticket.

planned

GitHub issues with repro steps

Title, steps, expected versus actual, environment and a severity label.

planned

Duplicate detection

The same bug should never be filed twice: a match would link to the existing issue instead.

planned

Confidence threshold

It would answer only when it is sure, and otherwise ask a question or hand off.

planned

Human in the loop

A person could take over any chat from the mobile app or through the API, with the full transcript attached.

planned

Multilingual

Answers in the language the customer uses, in text or voice.

planned

Analytics

What customers ask, what gets answered, what gets escalated.

planned

Consent-based diagnostics

With one tap of approval, the SDK would attach the client-side stack trace, console errors, device and app version, and on mobile a short, capped screen recording, deleted after the retention period.

planned

SLA policies

Optional response and resolution targets per severity or plan. Timers would start on filing; a target at risk nudges the tool, and a breach pages a person.

planned

Lifecycle updates

Plain-language status updates to the customer as the ticket moves, until it is resolved and confirmed.

planned

Rust core

The ticketing and routing core is planned in Rust, as one static binary you could self-host.

planned

Agent-ready

An MCP server and tool schema, so Claude, GPT or your own agents could search sources, answer and file issues.

HOW AN ESCALATION WOULD HAPPEN planned

One model writes the ticket. A second one checks it. The customer hears back at every step.

The design rule: nothing reaches your tools on a single model's say-so. A drafting model would turn the conversation into a structured ticket; an independent judge model would validate it and decide whether, where and with what priority it is filed. From then on, the customer would be kept informed until the issue is closed. The panels show sample output, not a real run.

  1. 01CUSTOMER

    The conversation

    Text or voice. The agent would try to answer from your sources first, and ask a clarifying question when it needs one.

    "The export button
 returns a 500 on
 large CSVs."

retrieval: 0 fixes
confidence: 0.31
→ escalate
  2. 02DRAFTING LLM

    Turns the chat into a ticket

    It would extract a title, reproduction steps, expected versus actual behaviour, environment and a proposed severity from the transcript.

    title: Export returns
  500 on CSV > 50 MB
steps: [3 extracted]
env: Chrome 129, EU
attachments (approved):
  stacktrace.txt
  screen.mp4 0:42
severity: high
  (proposed)
  3. 03JUDGE LLM

    Validates before anything is filed

    An independent model would score the draft: is it a real defect, is it reproducible, is it a duplicate, is the severity justified, is any customer data leaking?

    is_defect:    0.94 ✓
reproducible: 0.88 ✓
dup of #311:  0.12 ✗
severity_ok:  ✓ high
pii_scrubbed: ✓
verdict: FILE
  4. 04ROUTER

    Sends it where it belongs

    Bugs to GitHub, Jira or Linear. Support cases to Zendesk. Leads to Salesforce. A person on the mobile app when the judge says so.

    destination: github
repo: acme/app
labels: [bug,
  severity:high]
→ acme/app#482 created
← link posted in chat
  5. 05LIFECYCLE

    Keeps the customer updated

    The ticket would stay linked to the conversation. Status changes in your tools would trigger plain-language updates to the customer, in chat or by email, until it is closed.

    acme/app#482
triaged
 → "An engineer is
    on it"
in review
 → "A fix is being
    tested"
released
 → "Fixed in v2.14.
    Try the export?"
closed
 ← customer confirms
  • Judge approves → filed to the destination
  • Judge unsure → asks the customer one more question
  • Duplicate → links to the existing issue, nothing new filed

SLA policies

OPTIONALplanned

Response and resolution targets per severity or per plan. The agent would set the timer when it files, nudge the destination when a target is at risk, page the on-call person on breach, and tell the customer what to expect.

  • Per severity
  • Per plan / account
  • Business hours aware
  • Synced to Jira / Zendesk SLA fields
Example policy. It would be editable per workspace.
SEVERITYFIRST RESPONSERESOLUTIONON BREACH
critical15 min4 hpage on-call, notify customer
high1 h1 business daypage on-call
normal4 h3 business daysnudge destination, Slack
low1 business daynext releaseweekly digest

HUMAN IN THE LOOP planned

A person could step in at any point, from their phone.

The agent would handle the conversation. Your team would watch, approve, take over and hand back, from a mobile app or through the API, and every handover would keep the full context.

  1. C
    CUSTOMER

    Reports a problem

    By chat, by voice, or inside your mobile app. The agent would answer from your sources where it can.

    • Widget
    • iOS / Android SDK
    • API
  2. AI
    AI AGENT

    Handles it, or drafts an escalation

    Retrieval and an answer with citations, or a structured ticket scored by the judge model.

    • Automatic
  3. !
    TRIGGER

    Something asks for a person

    The judge is unsure, the customer asks for a person, the account is flagged, an SLA is about to breach, or your policy requires approval before anything is filed. The on-call person would be notified.

    • Push notification
    • Slack
    • Webhook
  4. H
    HUMAN

    Watches, approves or takes over

    From the phone: read the transcript, edit the draft issue, approve, reject, link a duplicate, or join the chat live, while the agent keeps suggesting replies.

    • Mobile app
    • API
  5. H
    HUMAN

    Hands back

    The conversation returns to the agent, which would own the follow-ups and the lifecycle updates to the customer.

    • Mobile app
    • API
  6. AI
    AI AGENT

    Learns from the correction

    The person's answer or edit would be stored as a reviewed source, so the next customer with the same question gets it without a handoff.

    • Automatic
MOBILE APP · ON-CALL VIEWillustration
Maria K. · on call14:02
NEEDS A HUMANSLA 0:42 left · judge 0.52
Export returns 500 on large CSV
Customer on Enterprise plan. Draft issue ready. Possible duplicate of #311.
Take overApproveLink #311
LIVE CHAT · AI SUGGESTS
Hi, this is Maria from support. I've seen the 500 on your export. Could you tell me roughly how many rows the file has?
SendEditHand back to AI
The same actions are planned for the API and webhooks

INTEGRATIONS

Escalations land where each team already works.

None of these connectors exists yet. They are the destinations and surfaces the product is being designed around.

PRICING planned

A free tier, paid tiers by volume, and a core you can run yourself.

Nothing is for sale and no price is set. These are the tiers being planned, without numbers, so none can be quoted before launch.

  • Free

    planned
    Not set

    For trying it on a small site.

    • A capped number of conversations
    • One source, one destination
    • Text only

  • Pro

    planned
    Not set

    For teams shipping a product.

    • More conversations
    • Unlimited sources and destinations
    • GitHub issue writing, analytics
    • Voice minutes included, then billed per minute

  • Scale

    planned
    Not set

    For high-volume support.

    • High conversation volume
    • SSO, audit log, SLA policies
    • More voice minutes included

  • Self-hosted

    planned
    Open source

    Run the Rust core yourself.

    • MIT licence, intended
    • Ticketing, routing and incidents
    • A single static binary
    • Bring your own model key

Voice, including phone calls, is planned to be billed per minute beyond an included allowance. No figure is set for that either.

Join the waitlist

Hear once, when it answers.

Nothing is built yet. Leave your address and you will get one email, when there is something to use.

Email [email protected] and you will be added by hand.

Live demo · planned