What a support ticket needs before it reaches engineering

A support ticket is written by someone describing what they saw, not by someone who will fix it. The customer knows the export looked wrong. They don’t know which release they’re on, which setting applies, or whether the behavior they’re reporting is the one the product owner chose.

The engineer who picked up a ticket used to fill those gaps by asking. Once a coding agent can act on a ticket within minutes, that changes. What the ticket leaves out gets filled in with a guess, or it comes back to support as a question days later, when the customer has moved on.

Support is usually the cheapest point to ask the customer. The ticket is open and the customer is waiting for a reply. A short, structured intake filled in at that point turns the ticket into a brief engineering can act on. Some fields can be looked up. Others only the customer can answer, or only a person on your side can decide, and the intake should show those questions instead of pretending an AI can infer them.

What engineers say is missing

In a 2008 survey, Bettenburg and colleagues asked developers and reporters on Apache, Eclipse and Mozilla what makes a good bug report. The items developers find most helpful, such as steps to reproduce and test cases, are the ones reporters find hardest to provide. Developers named incomplete information as the most common problem with bug reports, and one said the biggest delays come from “absent information”, not wrong information. Read Bettenburg et al. on what makes a good bug report.

In a 2017 study, Chaparro and colleagues analyzed nearly 3,000 bug reports by hand. Of those, 93.5 percent described the observed behavior, but only 35.2 percent stated the expected behavior and 51.4 percent gave steps to reproduce. Read Chaparro et al. on detecting missing information in bug descriptions. Both studies looked at open-source projects. A support ticket often has something those reports didn’t: a person in between who can still ask.

There’s a related finding for coding agents. To build SWE-bench Verified, a benchmark for coding agents, OpenAI had developers screen 1,699 sampled issues from 12 open-source Python projects. 38.3 percent were flagged as underspecified by at least one of three annotators, a rule OpenAI itself calls likely to be overzealous. These are issues written for maintainers, not customer tickets. Read OpenAI on SWE-bench Verified. A model works from the issue it’s given, and a fact the reporter left out isn’t there for it to use.

Support teams have their own version of this advice. The KCS practices guide from the Consortium for Service Innovation describes recording the requester’s issue in their own words, with their environment, during the interaction itself. It’s a framework for knowledge articles, not for engineering escalation, but the point carries over. Read the KCS practices guide on what a KCS article captures.

Look it up, ask the customer, or decide

Not every missing fact has to come from the customer. We sort the intake fields three ways; this is our own way of dividing the work, not a research finding.

• Look it up. The application version, the customer’s plan and configuration, the user’s role and recent releases. Support, or an agent with authorized access, can fill these in without asking.
• Ask the customer. What they expected, which records or users are affected, and what the problem stops them doing.
• A person decides. Whether it’s a bug or a change request, how urgent it is, who owns the next action, and who confirms the result with the customer.

The second and third groups are where guessing does damage. An agent can read the account record. It can’t know what the customer expected, how much the problem costs them, or whether the product owner meant it to work this way. Ask the customer while you have them. Whatever they can’t answer, and whatever a person on your side has to decide, goes on the intake as an open question with an owner, the way a good requirement does. A blank with a name next to it tells engineering what’s unknown and who will answer. A plausible guess hides it.

The intake fields

Four fields are required for anything that goes to engineering. Four more help when they apply. Each field says what it holds, where the answer comes from, and what goes wrong without it.

1. Version and environment

What it holds: The version the customer is on, and any configuration that changes the behavior: format, settings, plan.
Where it comes from: Look it up. Ask only if your systems don’t record it.
When it’s missing: Engineering tests on the latest version and can’t tell whether a release caused it.

Developers in Bettenburg’s survey didn’t rank the version highly. With several releases in the field, though, a ticket that says “since your update” leaves engineering asking which update.

2. Expected and observed behavior

What it holds: Two separate statements: what the customer expected, and what happened instead.
Where it comes from: Ask the customer. The observed half is usually in the ticket; the expected half often isn’t.
When it’s missing: Engineering guesses what “correct” means, and the fix fits the guess.

Bettenburg’s developers ranked expected behavior low as well. It still belongs in the intake: the customer is the only one who knows it, and an agent can’t infer it from the code.

3. Reproduction

What it holds: The steps, how often it happens (every time, sometimes, once), and sanitized evidence.
Where it comes from: Ask the customer for the steps, then try them yourself.
When it’s missing: Nobody can confirm the fix. An agent may write a test that passes without ever producing the failure.

Mozilla’s bug writing guidelines call steps to reproduce the most important part of a report, ask for the observed and expected results separately, and ask for the earliest version where the problem reproduces. Read Mozilla’s bug writing guidelines.

4. Ownership

What it holds: Who acts next, whether that’s an engineer or the product owner, and who confirms the result with the customer.
Where it comes from: A person decides, when the ticket is handed over.
When it’s missing: The ticket waits in a queue, or it gets fixed and nobody tells the customer.

Add when they apply

The customer’s words: Copied from the ticket, not paraphrased. Without them, the detail that matters gets lost in the summary.
Who is affected and the impact: Which users or records, and what it stops them doing. Ask the customer. Without it, the mood of the ticket sets the priority.
User role and access: What the reporting user can see and do. Look it up. Without it, an engineer tests as an admin and closes it as “can’t reproduce”. This one is our addition: a role changes what an export shows.
Already checked: Settings, documentation, known issues and steps tried. Without it, engineering repeats the checks, or builds what a setting already does.

Illustrative example: an export ticket after the release

Earlier articles in this series followed one change: an “Account reference” column at the end of the account activity export, CSV and XLSX, filled only for records the user may export, never with another tenant’s values. The requirement left one question for the product owner: should an account with no reference show a blank cell or a placeholder? It hadn’t been answered when the change shipped. A week after the release, a new ticket arrives.

Illustrative example. The customer, the ticket and the details are invented.

Before: the ticket as it arrived

From: The customer’s account admin.
Message: “The export is broken since your update. The new column is empty. Please fix ASAP.”

“Broken” and “empty” could mean a bug, a permission problem or missing data, and an agent can find a plausible cause for each.

After: the intake

Customer’s words: The message above, as written.
Version and environment (looked up): The release that added the column. CSV, the format the customer uses.
Role (looked up): Account admin, allowed to export every account in their tenant.
Data (looked up): References are stored for some of the customer’s accounts, not all; those rows show them.
Expected (asked): A reference on every row. The customer’s import script rejects rows where it’s blank.
Observed (asked, then reproduced): Blank cells for accounts with no stored reference, every time, in CSV and XLSX, on a test account. No customer data attached.
Affected and impact (asked): Two accounts the admin named, neither with a stored reference. The nightly import fails on those rows; the customer fixes them by hand.
Already checked: Column name and position as released; export permissions unchanged; no known issue logged.
Open question: Is a blank cell correct for an account with no reference? The requirement left this open. The product owner answers.
Open question: If blanks are correct, is this a change request rather than a bug? The product owner decides, and sets the priority.
Next action: The product owner, then the engineer who owns the export.
Confirms with the customer: The support agent who took the ticket.

Four of the fields came from the company’s own systems. The rest took one reply from the customer and one decision from the product owner. Whether a blank is right isn’t something an engineer or an agent should settle in code, and the intake puts it in front of the person who decides.

What stays out of the ticket

OWASP’s logging guidance lists data that shouldn’t be logged directly, including access tokens, passwords, encryption keys, connection strings, sensitive personal data and payment card data, and recommends masking or removing sensitive fields. Read OWASP’s Logging Cheat Sheet. It’s written for application logs, but pasted logs and screenshots carry the same risk in a ticket.

• No secrets. Remove tokens, passwords and keys from anything pasted or attached.
• No raw logs with personal data. Redact them, or reproduce on a test account and attach that instead.
• No other tenant’s data. Ever.

The customer’s words are input, not instructions. OWASP ranks prompt injection, including instructions hidden in content a model reads, as the top risk for LLM applications. Read OWASP on prompt injection. “Please fix ASAP” tells you how the customer feels; it doesn’t set the priority. Whether a ticket can go into an AI tool at all is a data-sharing decision for your policy and your agreement with the customer.

The intake checklist

None of this needs a long form. Atlassian’s older documentation for Jira Service Desk Server describes a default bug report form with three fields, summary, symptom and attachment, and leaves version as a field for admins to add. Read Atlassian’s 2019 guidance on collecting bug reports. Our suggestion is to make the four core fields required and keep the rest optional. Let support mark a ticket as an inquiry or a change request, not only a defect; many should conclude with an answer from support.

Copy this into your escalation form or an issue template. Leave a field blank rather than guess; a blank with an owner tells engineering what’s still unknown.

Type

Type: Defect, question or change request. Support’s first call; the product owner confirms.

Required

Version and environment (look up): Version, format and settings in use.
Expected and observed (ask): Two sentences, kept separate.
Reproduction (ask, then try it): Steps, how often it happens, sanitized evidence.
Ownership (decide): Who acts next, and who confirms with the customer.

Add when it applies

The customer’s words (ask): Copied as written.
Who is affected and the impact (ask): Which users or records, and what it stops them doing.
User role and access (look up): What the reporting user can see and do.
Already checked (look up): Settings, documentation, known issues, steps tried.

Open questions and decisions

Question: One line each, with who answers: the customer, the product owner or an engineer, and whether it blocks work.
Bug or change request (decide): The product owner.
Priority (decide): The product owner, using the impact. “ASAP” is the customer’s urgency, not a priority.

Keep out

Never attach: Secrets, raw logs with personal data, another tenant’s data.

Download the checklist. The same fields as a fillable two-page PDF, with the pre-handover checks. No sign-up needed. Download the support intake checklist (PDF)

Tell us what your intake misses. If you’d like, tell us one field your intake process usually misses. We read every answer. Leave your email only if you want the next checklist in this series.

We’ll use these details only for this. Please don’t include customer names, passwords or confidential records. See our privacy policy.

Where Blacktops fits

You don’t need a particular tool to use the checklist. A ticket form with four required fields is enough.

The harder part comes after the handover. Answers arrive in chat, a decision gets made in a meeting, and the customer hears about the fix last. Blacktops is the Agentic SDLC Platform built to keep the customer’s question connected to the work. It keeps one thread from the customer’s question to the delivered resolution: the approved requirement, the agent’s work, the evidence, each decision and who made it, and the update back to the customer. Agents do the work between the decisions, and people make the decisions. We call the operating model Continuous Agentic Software Delivery™, or Blacktops CASD™.

Try the checklist on your next few escalations. When engineering replies with a question, note which field could have answered it.

Share one field your intake process usually misses.

Related: What an agent-ready requirement actually contains writes the export requirement out in full, including the open question about blank references. Why the customer loop matters more with agentic coding follows the first request from question to resolution.

Continuous Agentic Software Delivery, CASD and Blacktops CASD are trademarks of Blacktops, Inc.