“I couldn’t pause my subscription.”
A customer leaves this comment when cancelling a meal-delivery subscription. The team could treat it as a request to build a pause feature. But perhaps that feature already exists. The customer might have struggled to find it, encountered an error, or missed the deadline for skipping a delivery.
Each explanation requires a different response. The comment gives the team somewhere to start.
In Part 1 of the Product Builder’s AI Arsenal, we explored Think and research. This second guide focuses on Capture and understand customers: working with conversations, support messages, and feedback to understand people’s experiences.
For product builders, founders, and customer-facing professionals, the practical opportunity is to make those conversations easier to revisit and compare. Active listening, critical thinking, and judgment determine whether the resulting analysis is useful.
1. Start with a question the feedback can help answer
Imagine a meal-subscription business investigating why customers cancel after their first month. Feedback is scattered across interview notes, support emails, and cancellation comments.
The following examples are fictional. They form a small teaching dataset, not findings from a real business.
SourceCustomer’s wordsContextC01“I liked the meals, but I couldn’t pause my subscription while travelling.”Cancellation commentC02“The delivery arrived while I was at work. I couldn’t change the time.”Support emailC03“By the third week, I felt I was choosing between the same meals.”Interview noteC04“I skipped a week through the app. That worked fine.”Interview with a continuing customerC05“After the introductory offer ended, it cost more than I could keep spending.”Cancellation comment
The question is: What happened before customers cancelled, and what still needs checking?
That keeps the investigation open. Asking AI to “prove customers need more flexibility” would build a preferred explanation into the task.
These five comments also cannot establish the main cause of cancellations. They describe different experiences from a small, selected group. The continuing customer provides a useful comparison, but does not represent everyone who stayed.
2. Capture the experience before interpreting it
Give each conversation a source ID. Keep the original wording alongside the date, channel, and relevant context. Distinguish verbatim quotes from notes written afterwards.
If recording an interview, agree this with the participant first. Use an approved workspace and remove unnecessary personal details before submitting material to an AI tool.
Transcripts need checking where meaning affects the decision. “I could pause” and “I couldn’t pause” lead to opposite conclusions. Where customers switch languages, retain the original wording beside the translation and check ambiguous phrases with a fluent speaker.
A useful first prompt is:
Using only the feedback below, create a table with source ID, exact customer wording, what happened, and missing information. Separate direct quotes from paraphrases. Mark anything unstated as unknown. Do not recommend solutions yet.
Review the output against the originals. AI may make a comment sound clearer while removing an important condition, such as “while travelling.”
Then return to the customer’s experience. For C01, ask:
“Walk me through what happened when you tried to pause.”
Follow with questions about what they saw, what they tried, and what happened next. Avoid suggesting an answer through wording such as, “Was the pause button difficult to find?”
This approach follows the GOV.UK Service Manual’s guidance to use open, neutral questions and explore actual experiences. Read its interview guide.
Active listening means allowing the customer’s account to change your explanation. Capturing the words is only the beginning.
3. Compare feedback without flattening the differences
The next task is to identify related concerns while preserving their distinctions.
C01 and C02 both describe difficulty adjusting the service to personal schedules. But pausing an entire subscription and changing a delivery time involve different tasks. Grouping both under “flexibility” is useful only if the specific problems remain visible.
Try this prompt:
Group related concerns in this feedback. For each group, list the supporting source IDs and explain the connection. Preserve differences within each group. Include contradictory evidence and unresolved questions. Do not infer how common a concern is beyond this sample.
The pause issue could produce this working interpretation:
EvidencePossible interpretationWhat remains unknownC01 could not pause while travelling.The customer encountered an obstacle when attempting to pause.What they tried, their device, timing, and any error.C04 successfully skipped a week.At least one customer completed a related task.Whether skipping and pausing follow the same process or rules.
C04 challenges the idea that nobody can adjust a subscription. It does not disprove C01’s experience.
Keep C05’s affordability concern separate. A clearer pause journey may leave the ongoing price problem untouched.
Critical thinking includes looking for feedback that makes the first explanation less convincing. Ask AI to identify that evidence explicitly, then check whether it has interpreted it fairly.
4. Turn an interpretation into a small investigation
The fictional feedback does not yet justify rebuilding subscription controls. It supports investigating the pause experience.
A practical decision brief could read:
Decision: Observe customers attempting to pause or skip an upcoming delivery.
Evidence: C01 reports difficulty; C04 completed a related task successfully.
What to learn: Whether the obstacle concerns finding the control, understanding the rules, or completing the action.
Action: Invite affected customers to demonstrate what they tried, using a safe test account where appropriate.
Trade-off: Observation takes staff and customer time, and a small sample may miss intermittent problems.
Decision rule: Choose a change that addresses an observed obstacle. Keep investigating if the evidence remains inconsistent.
AI can help prepare the observation guide:
Draft neutral questions for investigating C01’s experience. For each question, explain what uncertainty it addresses. Include what evidence would challenge our current explanation. Do not assume the pause feature is missing or broken.
Suppose observation later shows that customers repeatedly overlook the control. That would support testing its placement or wording. An error after selecting it would point towards a technical investigation. A cut-off rule customers do not understand would raise a different decision about communication or policy.
These are possible outcomes, not results from our fictional dataset.
After any change, check whether customers can complete the task. A reduction in cancellations would need separate assessment; price, meal variety, and delivery problems could still influence that outcome.
5. Keep the reasoning visible
A research record should let another person trace the decision back to the conversation.
Keep five things together: the source, the customer’s words, the interpretation, the unanswered question, and the next action.
NIST’s Generative AI Profile recommends fact-checking generated information and verifying sources. Applied here, that means checking extracted quotes and interpretations against the customer records. Read the NIST guidance.
AI can assist with organising and comparing the material. Your team still needs to check the evidence, speak with customers, and decide what warrants action. A well-written summary cannot recover context that was never captured.
For a handful of comments, a simple table and careful reading may be enough. As the material grows, assisted analysis becomes worth exploring, provided the time saved exceeds the checking work it creates.
Start with one recent customer conversation. Record what the person said, write your interpretation separately, and identify the question you need answered before proposing a change.
Further reading and references
Previous editions of the Product Builder’s AI Arsenal
Sources referenced in this guide
GOV.UK Service Manual: Using in-depth interviews — Practical guidance on open, neutral questions, exploring real experiences, and following up when meaning is unclear.
NIST: Generative Artificial Intelligence Profile — Guidance on generative AI risks, including checking generated information and verifying sources.