RIPPRE

08 — Support engineering

Pocket-Relay

In development

Every support conversation becomes the fix.

Pocket-Relay connects your support inbox to your engineering work. Questions, bug reports, and feature requests arrive from a widget on your website, email, Slack, Microsoft Teams, or a browser extension, and each one becomes a sorted request with the evidence attached. Your team turns it into a GitHub issue, a written specification, or a draft pull request, and the customer's conversation stays linked to that work until the fix ships and they confirm it works.

It is built for software teams where support, product, and engineering all touch the same customer problems. Pocket-Relay is in development: the whole workflow runs end to end in testing, while live AI processing and the GitHub connection are not switched on yet, and the AI coding agent that writes draft changes is still being built.

  • Never merges code on its own
  • Personal details removed before GitHub sees anything
  • Every action recorded, human or AI
Request a demo Read the docs

Features

Every channel, one queue

  • Customers reach you through a support widget on your site, with chat, bug-report, and feature-request forms and image attachments.
  • Mail to your support address becomes a request, replies join the right one, and Gmail or Outlook mailboxes can be connected directly.
  • Colleagues can raise requests from Slack or Microsoft Teams, and replies in the thread stay attached.
  • Your staff can file from any web page with a Chrome extension that sends the page's address only when they ask it to.
  • Your team can log requests by hand in the dashboard, and comments on the GitHub issues and pull requests Pocket-Relay creates come back as internal notes.
  • Every channel produces the same kind of request, each with its own reference key.

Triage that shows its work

  • Each request is sorted into one of 15 types — from support question and bug to billing issue and security issue — with categories, priority, severity, and the customer's sentiment.
  • A type chosen by a person or set by a form is never overwritten by the AI.
  • Related requests from the same product are linked automatically, so patterns surface without anyone searching.
  • Every request gets a recommended next step, such as answering with instructions, preparing a code change, sending it for product review, or escalating to security.
  • An engineering brief is written from the request's structured details, with personal information removed.
  • Suggested replies give your team a head start, and a person always edits and sends them.

From request to GitHub

  • Create a GitHub issue in one click, with the summary, problem statement, reproduction steps, priority, and related requests filled in.
  • Open a specification pull request that files a structured spec in your repository's docs folder for review.
  • Feature requests wait for a product manager's approval before any implementation work, and nobody can approve a request they filed.
  • Before the coding agent runs, you review and edit its exact instructions — it receives exactly that text.
  • Draft pull requests arrive on their own branch with a full description — customer problem, changes, risks, rollback plan, and required reviewers — plus structured notes and labels.
  • Risk comes from fixed rules about which files a change touches, and the right reviewers are requested automatically.
  • Build and test results, review status, and release status appear in one pull request queue.

Automation that stays in its lane

  • Choose per product: manual only, human approval required, automatic specification pull requests, or automatic draft pull requests.
  • Automation acts only when every condition holds — by default, a reproduced bug with high classification confidence, a small change, and no critical severity.
  • Requests from public channels never start unattended work; a person takes the first step.
  • Built-in rules keep automatic changes away from GitHub workflow files, database migrations, lockfiles, and container build files in every repository.
  • Agent runs happen in a disposable, sealed workspace with no network access and hard limits on time and usage.
  • No setting can merge, deploy, or run a database migration, and every automation decision is recorded with its reasons — including when it declined to act.

Conversation and code, kept in sync

  • Customer follow-ups on a request with open work are sorted — new evidence, a changed requirement, a possible regression, and more — and posted to the pull request with personal details removed.
  • Before you create new work, Pocket-Relay points out open pull requests on the same or related requests.
  • When a fix merges or ships — by merge, GitHub release, or deployment, whichever you choose — the request moves forward on its own.
  • A customer notification is drafted as soon as the fix is live, and a person reviews and sends it.
  • The customer's confirmation that it works marks the request verified.

Built for teams

  • Run several products under one roof, each with its own repositories, request keys, widget, and rules.
  • Six roles — support agent, product manager, engineer, engineering manager, domain reviewer, and administrator — each limited to the products a person works on.
  • Support agents can never start code generation, and only administrators can change where Pocket-Relay writes or what it may automate.
  • Rate limits and an optional daily limit per product protect your queue from floods.
  • A readable audit trail on every request shows who or what did each thing, and when.
  • Metrics for deflection rate, time to first draft pull request, agent pull request merge rate, and how often people corrected the AI — showing “no data” rather than a misleading zero.

Why you can trust it

Customer messages are never trusted blindly. The coding agent's instructions are built from structured, redacted details — never raw conversations — and when a person starts a change, they review and edit those instructions first. Pocket-Relay can write only to its own branches on GitHub, opens every pull request as a draft, and has no way to merge. Risk comes from fixed rules about which files a change touches, so an AI can never mark a change as safer than the rules say.

Your customers are told the truth, too. The widget says up front that your team uses AI to analyze requests, labels every reply as from a support team member, an AI assistant, or an automated message, and announces when a person takes over. The AI never writes to a customer on its own, personal details are removed before anything reaches GitHub, and every action — human or AI — is recorded.

Version updates

Pocket-Relay has not been released, so it has no version numbers yet. These are dated milestones from its development, each tested end to end with stand-ins in place of the live AI and GitHub connections.

  1. Rename

    Pre-release

    A new name: Pocket-Relay

    • The dashboard, the browser extension, and everything Pocket-Relay writes to GitHub now carry the Pocket-Relay name.
    • Issues and pull requests it creates are labeled pocket-relay, so your team can find them at a glance.

  2. Hardening milestone

    Security hardening and AI transparency

    • The support widget now tells customers up front that your team uses AI to analyze requests.
    • Every reply in the widget is labeled as from a support team member, an AI assistant, or an automated message, and the conversation announces when a person takes over.
    • Built-in rules now keep automatic changes away from GitHub workflow files, database migrations, lockfiles, and container build files in every repository.
    • Security hardening across the platform.

  3. Milestones 6–7

    Automation, roles, and more channels

    • Automation policies per product — manual only, human approval required, automatic specification pull requests, or automatic draft pull requests — with every decision and refusal recorded with its reasons.
    • Path risk rules per repository set the risk level, the required reviewers, and whether Pocket-Relay may open the pull request itself or must leave that to an engineer.
    • Six team roles, each limited to the products a person works on, and a readable audit trail on every request.
    • A pull request queue with filters, and a metrics page for deflection rate, time to first draft pull request, agent pull request merge rate, and corrected classifications.
    • New ways in: Microsoft Teams, a Chrome extension for your staff, Gmail and Outlook mailboxes, and comments from GitHub.
    • Agent runs moved into a disposable, sealed workspace, and a bug reproduction card lets engineers record whether a failing test reproduces the bug.

  4. Milestone 5

    Conversation and code stay linked

    • Customer follow-ups on a request with open work are sorted by kind and posted to its pull requests with personal details removed.
    • When a fix merges or ships, the request moves forward on its own, based on the release signal you choose.
    • A customer notification is drafted when the fix is live, and a person sends it.
    • A customer's confirmation that it works marks the request verified.
    • Before you create new work, Pocket-Relay points out open pull requests on the same or related requests.

  5. Milestones 1–4

    The first working pipeline

    • A dashboard with a request queue, request details, and product and repository setup.
    • An embeddable support widget with chat, bug-report, and feature-request modes and image attachments, plus email and Slack intake.
    • Automatic sorting of each request by type, category, priority, severity, and sentiment, with related requests linked and a recommended next step.
    • Personal details removed from everything bound for GitHub.
    • GitHub issues, specification pull requests, and draft pull requests from the request page, with an editable preview of the coding agent's instructions and reviewers requested by fixed file rules.
    • Product managers approve feature requests before any implementation work starts.

Documentation

How to set up Pocket-Relay, use it day to day, and fix what goes wrong.

Open the Pocket-Relay docs

Build with Rippre

Ideas become businesses through execution.

hello (at) rippre (dot) com