“The import finished, but the totals changed.” You can reply, repair the account and close the conversation. None of that tells the product side whether the state is reproducible, central to the promised job or safe to generalise. Support and research need two connected records—not one overloaded inbox.
The service record serves; the research record learns
Service record
Identity, authorised account context, reply, owner, status and resolution. Access belongs with the people handling the case.
Research record
A short de-identified excerpt when necessary, the attempted job, workflow state, consequence, supporting artefact and decision. Access and retention need their own limits.
Do not make someone wait while you finish taxonomy. Resolve the immediate problem, then create the smallest useful research record. A closed support case does not prove the product problem disappeared; an open case does not prove a roadmap need.
UK Government Digital Service guidance includes support tickets as one research input alongside analytics, usability work and follow-up research. That is a contextual method, not evidence that every ticket is representative of a private SaaS market.
Translate contact into a workflow state
| Research field | Keep | Do not copy across by default |
|---|---|---|
| Attempted job | What the person needed to complete | A broad feature tag |
| State | Input, processing, waiting, completion, handoff, billing or recovery | The whole conversation history |
| Consequence | Blocked work, incorrect output, delay, billing risk or recoverable confusion | Emotional tone as a severity score |
| Artefact | Error code, event trace, import report or reproducible state necessary to inspect the claim | Unneeded names, addresses, full files or message bodies |
| Fit | Target workflow, supported variation or explicit edge case | An assumption that every requester represents the same buyer |
| Decision | Investigate, clarify, repair, decline or gather more evidence | “Build requested feature” as an automatic outcome |
Count after classification, not instead of it
Ticket count alone does not establish consequence, cause, workflow centrality or exposure. A single possible billing or data-integrity failure may deserve immediate investigation. Repeated low-consequence questions may point to a copy problem. Several requests from one unsupported workflow may confirm a boundary rather than a roadmap.
Use four questions before frequency: What can go wrong? Does the state interrupt the core job? Is this an intended workflow? Could every eligible account reach the same state? Once tags are stable, volume can add context; it should not erase the underlying record.
Illustrative register — fictional contacts, not PBT tickets
No names, customers, frequencies or outcomes below are observed. The examples exist only to show different decisions.
| Fictional contact | State and artefact | Consequence | Smallest decision |
|---|---|---|---|
| “Did the reminder send?” | Post-action state; provider event exists but is not visible in the product | The operator cannot verify current status | Specify visible recipient, timestamp and failure state before adding another email |
| “The import finished, but totals changed.” | Completion; compare source file, import report and stored result | Possible incorrect output | Investigate integrity and recovery before documentation work |
| “Why is the report empty?” | Empty result; no eligible rows exist | Recoverable confusion | Explain the empty condition and next check in the interface |
| “My assistant cannot see the client list.” | Permission handoff; role state is inspectable | A required operator may be blocked | Confirm whether that role belongs in the target workflow before changing access |
Phrase → state → artefact → fix
- Preserve the shortest necessary phrase, or summarise it when a verbatim is unnecessary.
- Locate the exact state: processing, failed, complete with warnings, complete but invisible, or another documented state.
- Open the artefact that can confirm or contradict your reading.
- Name the consequence without turning frustration into a score.
- Choose the smallest evidence-matched change: copy, status visibility, recovery, reliability, support boundary or product work.
- Verify the same job and state after the change.
A help article fits when the product state is accurate and durable instruction is missing. It cannot repair an incorrect result, missing state or unsafe recovery path.
Research less data, on purpose
EU GDPR Article 5 includes purpose limitation, data minimisation and storage limitation. ICO guidance explains similar UK GDPR principles. Applicability depends on jurisdiction, role, purpose and the data involved; this is not legal advice or a universal retention policy.
- Define the research purpose before copying anything from support.
- Remove direct identifiers and details unnecessary to that purpose. Pseudonymised data may still be personal data.
- Restrict access to the service and research views separately.
- Set and review a local retention period; do not borrow a generic number.
- Do not republish a support quote merely because the name was removed. Purpose, authority and re-identification risk still matter.
Skip sentiment scores, automatic roadmap ranking and deflection targets until the product states and human classifications are stable. A canned “try again” reply is dangerous when another attempt could duplicate work. Automation may route a known state later; it must not turn an uncertain interpretation into fact.
Reduce the contact to a decision record
| Record | What belongs in it |
|---|---|
| State | The exact point where the job stopped or became unclear. |
| Necessary evidence | One artefact that can test the interpretation. |
| Consequence | What was blocked, incorrect, delayed or at risk. |
| Privacy boundary | What can be removed, who needs access and when the record expires. |
| Smallest decision | Investigate, clarify, repair, decline or research further. |
Decision: take one recent high-consequence contact, create a separate minimised research record and choose the smallest verifiable fix. If the missing state is an outbound message, use the event-to-recipient notification policy next.
Research handling references
- GDS user research in beta, published 2016-11-18, observed 2026-07-28; and GDS user support guidance, published 2016-11-24, observed 2026-07-28. Public-service guidance, not SaaS prioritisation benchmarks.
- GDS research-data privacy, published 2018-11-05, observed 2026-07-28. Contextual guidance, not a ready-made PBT policy.
- EU GDPR, Article 5, and ICO guidance on data minimisation and storage limitation, observed 2026-07-28. Jurisdiction and context matter; ICO pages are mutable.