A complaint about reporting software might describe a missing export, confusing setup, or a weekly reconciliation task nobody owns. Save all three under “reporting is painful,” and you lose the details needed to choose what to investigate.
A pain-point evidence sheet gives each observation a source and a place to record the role, situation, workaround, urgency, and unanswered questions. For an AI or SaaS founder, it provides a starting point for a research conversation or a useful piece of content. Public complaints alone cannot establish market size or willingness to pay.
Use the customer pain point research template below to turn a few saved discussions into one specific follow-up task.
Download the blank evidence sheet (CSV) to use in your spreadsheet, or copy the fields below. Keep your collection scope in a separate tab.
Define the decision before collecting complaints
Write one question above the sheet: “Which part of weekly client reporting should we investigate with small agency operators?” Use it to decide which observations belong.
Choose a role and situation narrow enough to compare. “People who use spreadsheets” includes many unrelated jobs. “Agency operators preparing weekly client reports” gives the collection a shared task.
Record feature requests separately from the problems behind them. Someone asking for an AI reporting assistant might need help explaining numbers, reconciling them, or collecting them. GOV.UK’s user research guidance recommends examining what people are trying to accomplish, how they currently do it, and where they struggle. It also distinguishes user problems from proposed solutions. Learning about users and their needs
At the top of the sheet, record your collection scope: communities or forums, search phrases, date range, and collection date. This lets a teammate see where you looked and which people you might have missed.
Read the conversation before recording a complaint
Search for the task alongside language that suggests effort or a workaround. For agency reporting, try “weekly report,” “manually copy,” “reconcile,” and “spreadsheet.” Adjust these starting phrases as you learn how people describe the work.
Reddit supports searches within a community and manual filters such as subreddit: and title:. For example, subreddit:agency title:reporting illustrates how to narrow a post search. The query is a starting point, not evidence that relevant accounts exist. Reddit’s available search features
Open each discussion before adding a row. Read enough of the post and replies to distinguish a firsthand account from advice, a hypothetical complaint, or a pitch for the author’s product. Later replies may explain that the issue was resolved, affects an older version, or arose in a different workflow.
Prefer accounts of a specific task or incident. Put broad complaints in a “needs context” queue without filling their gaps yourself. Mark inaccessible pages as unverified and leave them out of decisions until you can inspect them.
Copy the evidence-sheet template
Use these fields as spreadsheet columns, or duplicate the block for each observation. The worksheet is an editorial tool you can adapt.
Observation ID:
Source URL or comment permalink:
Posted date / checked date:
Source type and context:
Role and relevant setting, as stated:
Task and triggering situation:
Reported problem, concise paraphrase:
Requested feature or solution, if any:
Current workaround:
Reported consequence or urgency:
Unknowns and unanswered questions:
Your interpretation, labeled as a hypothesis:
Related or duplicate observation IDs:
Review status:
Next question or action:Keep one observation per row and one source per observation. If a post describes two problems, create two rows with the same source and link their IDs. Give another person’s account its own row, even when it describes a similar problem.
Use “not stated” for missing details. Posting in a founder community does not establish someone’s job, company size, location, or purchasing authority. Public commenters are not automatically your customers.
Write a faithful paraphrase in the problem field. When exact wording matters, preserve a short verified excerpt and label it as a quotation. Put your explanation in the interpretation field. GOV.UK’s guidance on analyzing research sessions uses a similar distinction between observations, findings, and actions. Analyze a research session
Record urgency through the consequence described: a deadline, delayed delivery, repeated rework, or an explicit need to replace a tool. Strong language alone does not tell you the stakes. Preserve reported time or cost with its scope and attribution; it remains the author’s claim.
Use observation IDs in internal summaries instead of repeating usernames. Retain only the personal detail needed to understand the task.
Worked example: weekly agency reporting
This fictional example shows how to fill the sheet. It is not a customer account, quotation, or product result.
Imagine an agency operations manager describes combining advertising exports every Friday. Client names differ across files, so the manager uses a spreadsheet lookup and checks unmatched rows manually before sending the report.
| Field | Hypothetical entry |
|---|---|
| Observation ID | H-01 |
| Source and dates | Fictional example; no URL or dates |
| Role and setting | Operations manager at a small agency |
| Task and trigger | Assemble the weekly client report |
| Reported problem | Client names differ across exports |
| Requested solution | Not stated |
| Workaround | Spreadsheet lookup plus manual checks |
| Consequence | Checks must finish before Friday delivery |
| Unknowns | Time spent, error frequency, budget |
| Interpretation | Matching records may be the bottleneck |
| Review status | Investigate next |
| Next question | How were unmatched rows handled last week? |
Record matching is a question worth exploring here. The account leaves open whether inconsistent naming comes from an avoidable setup issue and whether the current workaround is acceptable. It gives no evidence of demand for an AI report writer.
Suppose a second fictional author says an existing connector solved the same problem. Record that account as H-02, including the connector, setup details, and any stated limits. It challenges the idea that the problem requires a new tool and suggests a question: what differs between the two setups?
A third fictional post, H-03, asks for nicer report colors. Put it in a separate group. It concerns reporting, but describes a different problem from matching client records.
Compare similar tasks and keep counterexamples visible
Group observations by role, task, and failure point. “Matching client records before delivery” gives you a specific problem to examine. “Productivity pain” obscures it. Keep the original rows available so a teammate can question the grouping.
Count observations, apparent authors, and independent threads separately. Five comments from one person may explain a problem thoroughly, but they do not represent five users. Link reposts and copied stories rather than counting them as independent support.
These counts describe your collection, not the share of a market with the problem. Your search terms and chosen communities affect what you find, while public accounts leave identities and circumstances partly unverified.
Assign each row a review status:
| Status | When to use it |
|---|---|
| Investigate next | The role and task fit, the account is specific, and an unanswered question could change your decision. |
| Needs context | The complaint is relevant, but the situation or consequence is unclear. |
| Set aside | The account is a duplicate, outside scope, or cannot be inspected. |
These statuses organize work; they are not a validated scoring model. A detailed account may justify an interview. Vague complaints may call for a better search. Include counterexamples, especially accounts from people satisfied with their workaround.
Turn a group of observations into a decision note
After comparing a group, fill in this short note:
Question we investigated:
Observation IDs supporting the pattern:
Contradictory observations:
What remains unknown:
Next action:
Owner and review date:
Evidence that would change our decision:For the fictional reporting example, a completed note could read:
Question: Does matching client records cause recurring reporting work?
Supporting observation: H-01 describes manual checks before Friday delivery.
Counterexample: H-02 reports that a connector solved the problem.
Unknowns: Setup differences, time spent, errors, and satisfaction with the workaround.
Next action: Ask a willing agency operator to walk through a recent reconciliation task.
Owner and review date: The founder; review the note after the walkthrough.
Evidence that would change the decision: Existing configuration handles the mismatches acceptably, or record matching is not the main source of work.During that walkthrough, ask where matching fails, what gets checked, and whether the workaround is acceptable. Budget and purchasing authority require separate questions.
If the uncertainty turns out to be an information gap, use it to plan an explanation or worksheet. Keep the observation IDs attached to the internal content brief so you can trace the question back to its sources. FindVex’s SaaS content brief template shows how to turn that question into a writing assignment.
Start with five saved discussions
Process five existing bookmarks using the template. Five is a manageable practice batch, not a validation threshold.
Before writing your decision note, check that each usable row has an inspected source and check date. Mark missing details, separate interpretations from reported experiences, and link duplicates. Keep any counterexample beside the pattern it challenges.
Finish with one follow-up question, the observation IDs that prompted it, and an owner for the next task.
