01 / Support conversation
“Can you send me an email when the export is ready?”
Inspect sample context
The customer starts an export and leaves the page to continue other work. They want to know when to return.
Turn feedback into delivery briefs
Give the feedback
a clear next step.
Customer comments arrive as requests, frustrations, and suggested fixes. Bring the evidence together, explain the underlying problem, and prepare a brief your team can review.
Start with what customers said
Different requests.
A shared question to explore.
These illustrative records describe uncertainty while an export runs. Keep the original wording and context available as you examine the pattern.
02 / Customer interview
“I keep checking the page because I can’t tell if it’s finished.”
Inspect sample context
The customer describes repeatedly returning to check the export state. The excerpt does not establish how often this happens across all customers.
03 / Support ticket
“Could the download appear when the file is done?”
Inspect sample context
The customer asks for a visible completion cue. It is a suggested solution, not confirmation that an automatic download is the right approach.
A possible shared need
Know when an export is ready without repeatedly checking.
Illustrative synthesis. Three accounts support a question to investigate; they do not establish prevalence or prescribe the solution.
Build the case before the specification
Describe the need.
Leave room for a better solution.
An email, a status cue, and a download prompt are different ideas. A brief brings the problem and supporting evidence together so the team can compare approaches.
Explore findings and evidenceKeep the sources attached.
Citations let reviewers return to the original feedback and check whether the proposed change addresses the customer’s task.
Add the project context.
When a project strategy is available, the draft considers alignment and tensions. The team checks that reasoning against current priorities.
Keep uncertainty visible.
Record what you still need to learn about reach, frequency, constraints, and the proposed approach. A request alone is not an implementation decision.
A readable output for the team
From a collection of comments
to a proposal worth reviewing.
Illustrative draft brief · For team review
Make export completion clear.
- Problem
- Customers describe leaving an export running, checking its state repeatedly, or wanting a completion cue [1–3]. They need a clearer way to know when the file is ready.
- Proposed change
- Explore a visible completion state with an accessible route to the file [2, 3]. Compare it with an optional notification for customers who leave the page [1].
- Reasoning
- The proposal addresses awareness of completion while preserving a choice of approach. The feedback supports the need; the team still needs to validate the interaction.
- Open questions
- How long do exports take? How often do people leave the page? Which completion cue works for them? What should happen if an export fails?
Agree what “ready for delivery” means.
Product, design, and engineering review the scope together. Confirm the states to cover, technical constraints, and how the proposed experience will be evaluated.
In this example, the team would need to consider running, completed, and failed exports before agreeing acceptance criteria. Those criteria come from review, not from the customer quotes alone.
Bring the context into the work
Keep the why
with the next action.
Use the brief to review the case. When you want a tracker handoff, send a theme to a supported issue tracker with its evidence in the body.
Drafting a brief and filing a theme are separate actions. You initiate the handoff; your team decides the scope and owns implementation.
See briefs, handoffs, and availabilityReview the recommendation.
Check the citations, challenge the proposed change, and resolve the questions that affect scope.
Agree the work.
Decide what to implement, what to investigate further, and how to evaluate the result.
Hand over the context.
Use the supported tracker workflow when ready. Keep the underlying evidence available to the people doing the work.
The product behind the workflow
Bring the evidence
all the way through.
Give your next brief
a stronger starting point.
Start with the customer evidence behind a problem your team needs to address.