Support tickets are written by people who do not know how your system works, about something that annoyed them, in whatever words came to mind. Turning one into a reproduced bug, a root cause, an honest reply and an engineering ticket is skilled work, and an AI assistant is good at most of it. The parts it should not do alone are the parts with consequences: what goes into the prompt, and what goes out to the customer.
The ticket
This one came from a bug found by accident while walking through the series' checkout feature in a browser: a signed-in customer who opens the checkout page directly gets empty, red Name and Email fields. The customer's wording below was written for the exercise; the bug is real:
Support ticket #3117, forwarded from the support inbox (customer details
removed before pasting):
'Every time I go to checkout it says "Please tell us who the order is for"
and the email box is red, even though I'm logged in. I have to type my name
and email again every single time. If I go through the cart button it's
fine?? Using Chrome on my laptop. Kind of annoying, I order every Friday.'
What never goes into the prompt
Note "customer details removed before pasting". A real ticket arrives with a name, an email address, maybe an order number and a delivery address. None of that helps diagnose this bug, and all of it is personal data you are now sending to another system. Strip it first. If the investigation really needs a specific account, use a test account that reproduces the problem, or refer to the customer by an internal id that means nothing outside your company. The same goes for card details, passwords and anything a customer pasted that they should not have.
The rest of the prompt asked for five things: triage, reproduction, root cause with file and line,
a reply to the customer, and an engineering ticket. It ran in a fresh session against the
main branch, since the customer is using what is deployed, not what is in review.
Triage and root cause
The triage was sharp. Bug, not user error; low to medium severity; affects signed-in customers who land on checkout from a bookmark, a refresh or a new tab; and a detail worth noticing, that it lands on repeat customers, "the ones most likely to bookmark checkout. 'I order every Friday' fits that exactly." It also explained why the page looks half-broken: after a moment the page does recognise the customer and fills their address and phone, but not their name and email.
The root cause, at high confidence, pointed to the form being initialised once:
const [form, setForm] = useState({
customerName: user?.fullName ?? '',
email: user?.email ?? '',
phone: '',
On a full page load the signed-in user is still being fetched when this runs, so both fields start empty and nothing fills them later. The cart button works because it navigates without reloading, by which time the user is known. It pointed out that the Angular version of the same app does this correctly, filling empty fields whenever the user arrives, which made the fix obvious. Every file and line it cited checked out.
It could not reproduce, and said so
The plan was to reproduce the bug with a throwaway Playwright script. Writing the script to
/tmp needed a permission the session did not have, so it stopped:
I couldn't run this in a browser, so it hasn't been reproduced live yet.
Writing a script to /tmp was denied, and running the script inline was
blocked by the shell guard. I didn't try to work around either.
Then it gave exact reproduction steps derived from the code, and an expectation that it would fail every time rather than now and then. This is the behaviour to want. A session that quietly claimed "reproduced" from reading the code would have been worse than useless. Here the bug had in fact been reproduced already, by the walkthrough script that first hit it, so the steps were confirmed against that.
The reply needs your judgement
The drafted reply was good: an apology without grovelling, a plain admission that it is a problem on our side, a workaround ("go to checkout through the cart"), and no promise of a date. It also made a factual claim to reassure the customer:
Your order still goes to your account and the receipt still goes to your
account email.
Before a sentence like that goes to a customer, check it. A reassurance that turns out to be false is worse than none. Here it was true: the order's contact email is the account's whenever the customer is signed in, and both the payment receipt and the confirmation email use it. Had it been false, the reply would have promised something the system does not do, in writing, to a paying customer.
The other judgement calls are about tone and policy, and those are yours: whether to offer a discount, whether to tell this customer when it is fixed, whether this customer is one your team knows by name. The assistant drafts; a person sends.
The engineering ticket
The last output was a one-paragraph bug ticket: the cause with file and line, who is affected, why existing tests missed it ("the current suite only ever reaches checkout through the drawer"), the fix modelled on the Angular app, a warning not to fix it by making the page wait for sign-in (which would slow it down for guests), and a specific Playwright test to add. That is a ticket an engineer can pick up cold, which is the standard to hold any ticket to.
At the time of writing, the bug is not fixed. It is a separate change from the feature this series follows, and it waits its turn like any other ticket. That is fine, as long as someone owns it and the support reply did not promise otherwise. Closing the loop with the customer when the fix ships is a small thing that support teams remember and customers notice.
Before you accept
- Did you strip names, emails, addresses and anything sensitive before pasting the ticket?
- Was the investigation run against what the customer is actually using?
- Was the bug reproduced, or only explained? Does the report say which?
- Did you verify every factual claim in the reply before it goes to the customer?
- Are the tone, compensation and follow-up decisions made by a person?
- Could an engineer fix the bug from the ticket alone, including a test that would have caught it?