A droid that stands between support and engineering: when a customer bug is escalated, it reproduces the issue on its own machine, captures the exact steps and logs, and files an engineer-ready issue — or, when it can’t, replies asking for the one missing detail. Engineers stop losing afternoons to “cannot reproduce,” and customers get answers faster.
Does
Reproduces bugs, files them ready
Where
SaaS product, ~15-person eng + support
Reaches people on
Slack, Zendesk
Works inside
Zendesk, GitHub, Linear
Runs
On every escalated bug report
01The situation
Half of “the app is broken” never makes it to a bug an engineer can work.
Support escalated bugs with half the information an engineer needed, because gathering the rest — the exact steps, the environment, the logs — takes time and back-and-forth nobody had. So tickets arrived as “the app is broken,” engineers couldn’t reproduce them, and the issue bounced between teams while the customer waited.
A genuine afternoon could vanish into setting up an environment just to confirm a bug was real. What engineering needed was for every escalation to arrive already reproduced, with the steps and logs attached — and for the under-specified ones to get one good question asked, not a guess.
02How it works
How the droid took it on.
Rather than escalate half-formed tickets, the team put a droid between support and engineering. When a bug is escalated it reproduces the issue on its own machine, files it ready, and asks the customer for the one missing detail when it can’t.
TASK#377Customer bug reproductionstanding
trigger
Any bug escalated from support
also
A daily triage digest to #eng
scope
Every escalated customer bug report
runs as
A contained droid action per bug, on its own sandboxed machine
memory
Past reproductions, common environments, and known issues
Set up once, in plain language: “when support escalates a bug, reproduce it on your own machine, file it with the steps and logs, and only come to a person for a missing detail or something serious.” The droid turned that into a standing job, the bridge between support and engineering that kills “cannot reproduce.”
FIG. 1The durable task, exactly as it exists in the runtime.
Every escalated bug trips the same loop:
01Bug escalatedFrom support (Zendesk)
02Droid wakesOn its own machine
03Reads ticket + code + memorySteps, environment, history
04Reproduces itMatching sandbox env
05Files it readySteps, logs, hypothesis
06Reproduced?Yes → file with evidence · Missing info → ask the customer · Security → page eng now
07Posts to #engTriage digest
…then the next run picks it up, two hours later.
FIG. 2The loop each run walks.
03Ongoing handling
How it ran, ticket after ticket.
Here’s a day of bug triage as it actually unfolded, across Zendesk, GitHub and its own machine. Only the one security-grade finding ever needed a person.
9:30amticket · export fails
Reproduced an export timeout on a matching environment and filed ENG-3120 with logs and a hypothesis.
11:15aminfo needed · vague ticket
Couldn't reproduce blind, so asked the customer the one unblocking question instead of escalating a guess.
1:40pmdedupe · upload crash
Matched a new ticket to an existing issue and linked it instead of filing a duplicate.
2:30pmreproduce · mobile crash
Reproduced a crash and pinned it to OS versions below 15, filed with the version boundary and log.
3:50pmsecurity · billing pageescalated
Reproducing a bug, found a request returning another tenant's data, and paged the eng lead at once.
5:00pmtriage digest
The day reconciled: 4 reproduced & filed, 1 linked, 1 awaiting info, 1 security escalated.
Escalations from support land on the left. Watch the droid pick up each one and work it across Zendesk, GitHub and its own machine, paging a human only for the finding that warrants it.
Faster answerscustomers told it's confirmed, same day
Severe caughtsecurity-grade bugs paged immediately
An illustrative workflow built from real product mechanics. The connected apps, the schedules and the run handling are how a droid actually works; the companies, the people and the figures are composites rather than a customer's numbers.
Try this workflow
Run this workflow yourself.
Copy the brief below and paste it into Unify. It’ll walk you through the prerequisites, connect what it needs, and stand the workflow up with you.
Workflow brief
I manage engineering at a ~15-person SaaS product, and support escalates bugs with half the information we need. Gathering the rest, meaning exact steps, environment and logs, takes back-and-forth nobody has, so tickets arrive as "the app is broken," engineers can't reproduce them, and the issue bounces between teams while the customer waits. A whole afternoon can vanish just setting up an environment to confirm a bug is real.
Stand between support and engineering. Apps/channels: Zendesk (escalated support tickets), GitHub (the codebase), Linear (the engineering backlog), Slack #eng (the triage digest and paging). Use your own sandboxed machine to actually reproduce bugs.
Run on every bug escalated from support. For each one:
1. Read the ticket, covering the customer's environment, plan and the exact steps they described, then pull the relevant code.
2. Spin up a matching environment on your own machine and follow the steps to reproduce it.
3. If it reproduces, capture the steps, logs, and failing path, and file an engineer-ready issue in Linear with a hypothesis; update the ticket to "reproduced, tracked."
Use judgment on what reaches a person: file the reproduced bugs ready to work, and when a ticket is too vague to reproduce, don't escalate a guess. Reply to the customer asking the single most useful question. If reproducing reveals something severe, like a security or data-exposure issue, page the eng lead immediately and keep details out of any customer-facing place. Post a daily triage digest. Remember past reproductions, common environments, and known issues.
