# Turn a vague request into a ticket someone can act on.

Capture the missing context, preserve evidence and let the requester confirm a complete ticket before it enters the team’s queue.

Version 1.0 · 2026-07-29 · 7 min

## Short answer

A good ticket is a structured handoff, not a longer message. Reuse the user, screen, record and recent tool results already available. Ask only for information the system cannot infer safely. Produce an editable proposal containing the goal, observed behaviour, expected result, context, evidence, impact and reproduction steps when relevant. The requester confirms it before submission. This improves intake while preserving the existing issue tracker and the team’s ownership.

## Key points

- Use product context before asking the requester to repeat it.
- Ask focused follow-up questions only when a required field remains uncertain.
- Create an editable ticket proposal and keep the tracker as the source of truth.

## “It does not work” often contains a real problem and a poor handoff

The requester may know the impact but not the technical vocabulary. The support team sees the message without the route, role, record, recent action or expected result. A long free-form conversation then reconstructs facts the product could already supply.

The assistant’s job is not to invent certainty or close the issue. It should reduce translation work between the person experiencing the problem and the person who will act on it.

## A ticket proposal contract

Use a stable structure so both people and downstream tools know which information is present and which is still missing.

### 1. Capture the objective

State what the person was trying to achieve, in their language.

### 2. Attach validated context

Include product, module, route, role, tenant or site, relevant record and environment only when authorised and useful.

### 3. Separate observed and expected

Record what happened and what the user expected. Do not rewrite an assumption as an observed fact.

### 4. Gather evidence

Attach safe tool results, source references, error identifiers and steps already attempted. Redact secrets and unrelated personal data.

### 5. Ask the minimum clarification

Request one missing detail at a time when it changes routing or priority. Otherwise prepare the ticket.

### 6. Confirm and submit

Let the requester edit the proposed ticket. Create it through the existing tracker and return the canonical identifier.

## Examples

### Construction operations

A foreman reports that a document cannot be approved. The ticket includes the current site, workflow stage, visible status, missing attachment and business impact.

### Finance software

An accountant reports an import failure. The proposal includes file type, period, validation message, attempted steps and the expected posting result, but not the financial file itself.

### SaaS support

A user reports a permission problem. The ticket records the role and route while keeping restricted account data out of the handoff.

## Common failure modes

- Generating a polished summary that removes the user’s actual goal.
- Attaching every available field instead of the minimum useful context.
- Leaking secrets, personal data or restricted records into the tracker.
- Inventing reproduction steps or declaring a root cause without evidence.
- Creating the ticket without letting the requester verify the proposal.

## Checklist

1. Goal, observed behaviour and expected result are separate.
2. Validated product context is attached when useful.
3. Evidence is sourced and safely redacted.
4. Impact is described without invented urgency.
5. Missing information triggers a focused clarification.
6. The requester can edit and confirm the proposal.
7. The existing tracker returns the canonical ticket identifier.

## Limitations

- Better intake does not guarantee faster resolution when ownership or capacity is unclear.
- Some incidents require live investigation before a useful ticket can be written.
- Automated priority should remain advisory unless the organisation has explicit, tested rules.

## Sources

1. [What Makes a Good Bug Report?](https://www.st.cs.uni-saarland.de/publications/details/bettenburg-tr-2008/) — Bettenburg et al., 2008; type: research.
2. [Information needs in bug reports for web applications](https://doi.org/10.1016/j.jss.2024.112230) — Journal of Systems and Software, 2025; type: research.
3. [Syntax for GitHub Issue Forms](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms) — GitHub Docs, 2026; type: official-documentation.

## Practical questions

### Should the assistant diagnose the root cause?

Only when evidence supports it. Otherwise it should state hypotheses separately and preserve the observed facts.

### Can it create the ticket automatically?

It can after explicit confirmation or under a deliberately delegated low-risk policy. Duplicate protection is still required.

### What if the user refuses to provide more detail?

Prepare the best honest ticket possible, mark the missing information and route it to a human if the impact warrants it.

---

Canonical: https://scoperail.fokalabs.io/en/guides/from-vague-request-to-actionable-ticket
Author: Ramzi Laieb, FokaLabs