Turn Customer Feedback Into a Structured Note

A structured customer-feedback note preserves what one person reported, the context they supplied, and the questions you still need to ask. It should not turn one message into a claim about the whole customer base. Start by recording the report accurately before deciding what the product team should build.

The message in this guide is fictional and was written for the exercise. It is not Recap customer feedback, a discovered Recap defect, or evidence about real users. The worksheet is a manual reading method rather than a product accuracy demonstration.

Keep a short source excerpt intact

Here is the fictional message:

After our meeting I exported the notes, but the destination note looked blank. I tried again and got confused about which copy to keep. Could you add automatic retry?

Several useful details are present. The report concerns an export after a meeting. The person describes a blank-looking destination note and a second attempt. They request automatic retry. The message does not name the destination, device, application version, source record, or steps used.

Retain the original wording in an appropriate private record so that another reviewer can check your interpretation. If the note will be shared outside the support team, review whether it contains personal details, customer material, or confidential project information. Use a redacted example where a direct quotation is unnecessary.

The GOV.UK research-analysis guidance separates observations from interpretation. Apply that distinction here: a report of a blank-looking note is evidence of what the person said. It is not yet a reproduced technical failure.

Split the message into useful fields

An observation record can be short while retaining important uncertainty.

Field	Fictional example
Reported situation	Exported meeting notes
Reported result	Destination note looked blank
Subsequent behavior	Tried again; uncertain which copy to keep
Requested solution	Add automatic retry
Destination and environment	Not supplied
Reproduction status	Not tested
Scope	One fictional message
Next question	Which destination and steps produced which visible result?

This layout keeps the customer's proposed solution visible without promoting it into an implementation requirement. Automatic retry might address part of a real problem, or it might create more copies. The fictional message does not establish which explanation is correct.

Do not rewrite the note as “exports fail for meeting users.” That sentence adds a verified failure, a segment, and a frequency claim. None of those is established. A more accurate heading is “Reported blank destination note after an export attempt.”

Separate the underlying difficulty from the feature request

The requested feature is one proposed remedy. The reported difficulty includes uncertainty about the destination result and which copy to retain. A useful follow-up needs to understand that difficulty before committing to a retry mechanism.

Write the possible interpretation as a hypothesis: “The person may lack a clear indication of whether the first export completed.” Keep the hypothesis beside the questions that could confirm or reject it. It must not appear in the source-fact field.

Ask for a concrete sequence. What did the person select? What appeared in the original document and destination? What happened between the first and second attempts? Which copy looked blank? A sequence is more useful for investigation than asking whether the feature is “broken.”

Avoid questions that assume your explanation. “Did the network failure cause the empty note?” presupposes a network failure. “What did you see after selecting export?” leaves room for an answer that changes your hypothesis.

Mark the population limit explicitly

A single report can reveal an issue worth investigating. It cannot establish the proportion of people affected. Record the available count and how the record was selected before anyone uses it in prioritization.

For a real support note, distinguish a unique person, a ticket, a message, and an occurrence. Three replies in one ticket are not automatically three affected customers. A second attempt mentioned in one message may be a separate occurrence, but it is not another user.

The GOV.UK guide to planning user research asks teams to agree research questions and how findings will be shared. For this worksheet, the practical consequence is to write the question before collecting more examples. You might investigate export-result clarity rather than collect every request containing the word retry.

If later evidence suggests a wider pattern, keep the evidence set separate from the original report. Identify how records were gathered and what they represent. The first message should remain readable as one person's account, even after it becomes part of a broader investigation.

Turn omissions into answerable follow-ups

The fictional message leaves several gaps. Ask which destination was used, what the person expected to appear there, and whether they can describe the result without sharing confidential meeting content. Request only the material needed to investigate.

A screenshot may help identify a visible state, but it may also expose names or private notes. Explain what part matters and ask for redaction where appropriate. Do not collect an entire account export just because a smaller example is inconvenient.

Record each answer with its own source identity. If a later message identifies the destination, add a dated update. Do not make the first message appear more complete than it was. This helps a reviewer understand why an earlier investigation took a different direction.

Also record what remains untested after the conversation. A detailed explanation can improve the note without reproducing the issue. “Environment clarified; reproduction pending” is more accurate than “confirmed” when no test has occurred.

Prepare a handoff without choosing the fix

A useful product handoff includes the reported difficulty, the relevant source, and the question the team should investigate. It may include the customer's preferred solution, labeled as a request. It does not need to include a promised release, a technical cause, or an assigned engineering owner.

For the fictional case, the handoff could ask whether users can tell which export result is complete. A separate technical check could examine the destination content. Keep those investigations separate until the evidence connects them.

If someone proposes a fix, record who proposed it and the assumptions it requires. A hypothesis about status feedback can lead to a different test from a hypothesis about content transfer. Combining them prematurely makes a later failure harder to interpret.

Keep the note connected to the source

Before sharing, compare the heading and final paragraph with the original message. Remove any stronger claim that appeared during editing. Check that the requested feature remains distinct from the observed difficulty and that the scope still says one report.

Recap turns a source into a structured readable document. Calendar, Workspace, and Learning remain parallel next steps; this worksheet does not claim that every generated document contains these exact fields. Use the source-to-document entry point for material you want to organize.

For a broader evaluation, use the decision brief template. The source-grounded document checklist helps you check locators and unresolved fields before export. A later reader should be able to tell what the person said, what you think it might mean, and what evidence the next investigation still needs.