Feedback triage is the small operating step between receiving a message and deciding what it means. The goal is not to score customers, collect testimonials, or turn every suggestion into a feature. The goal is to preserve the useful observation, remove unnecessary personal detail, group related signals, and assign one honest next action.
This guide provides a minimum-data CSV schema, a four-way decision table, a duplicate-clustering pass, a weekly act / watch / close queue, and one clearly hypothetical worked example. It complements HoneKit’s digital product starter-kit guide, which covers the broader package and launch system.
Last reviewed: August 29, 2026. This is operational guidance, not legal, privacy, research, customer-success, or product-management advice. Adapt fields, retention periods, and escalation rules to your actual product and jurisdiction.
1. Separate the message from the decision
A support email, refund question, survey response, public comment, or bug report is an input—not a ready-made roadmap item. Preserve what was actually observed before adding an interpretation.
- Observation: the smallest factual statement you can support, such as “the buyer could not find the editable file named in the welcome document.”
- Context: only the product version, file, step, device, or public page needed to understand that observation.
- Interpretation: a tentative explanation, clearly labelled as a hypothesis rather than a customer quote.
- Decision: the next owner and action, such as reply, documentation edit, reproduction attempt, watch, or close.
GOV.UK’s service manual recommends recording what was seen or heard before writing what it might mean, then sorting observations into themes and deciding actions. A small product team can use the same separation without pretending that informal support messages are a formal research study.
2. Use a minimum-data feedback triage CSV
Start with fields that support a decision. Do not copy a full email thread, receipt, account export, payment record, or private dashboard into the triage sheet.
| Field | What to record | Boundary |
|---|---|---|
| signal_id | A local neutral ID such as FB-2026-014. | Do not use an email address, order number, or customer name as the key. |
| received_on | The date the signal arrived. | Use the time only when sequence matters to an incident. |
| source_type | Support, refund, survey, public comment, or internal observation. | Record the channel type, not broad account details. |
| product_area | Checkout, access, archive, START-HERE, template, documentation, or other stable area. | Avoid free-form labels that reveal private project names. |
| observation | A short factual paraphrase of the problem or request. | Remove names, contact data, secrets, and unrelated business details. |
| context | Relevant version, filename, step, browser/OS, or public URL. | Do not paste full local paths, logs, screenshots, or tokens by default. |
| triage_type | support, documentation, bug, roadmap, or unclear. | This is a working category, not a statement about the person. |
| theme | A reusable label such as access-receipt, zip-open, placeholder-risk, or first-use. | Keep the label about the task, not the buyer. |
| next_action | Reply, edit docs, reproduce, watch, close, or request minimum detail. | Do not imply a public delivery commitment. |
| owner | The role responsible for the next action. | Use a stable role rather than personal data in a broadly shared sheet. |
| review_on | The next review date or a factual trigger that reopens the decision. | Do not leave watch items permanently open without a checkpoint. |
| retention_review | The date to delete, aggregate, or re-evaluate the row. | Do not retain identifiable raw messages merely because the sheet exists. |
The ICO describes purpose limitation, data minimisation, accuracy, storage limitation, and security as core data-protection principles. This table applies those ideas as a conservative design boundary, not as a claim that a CSV alone satisfies any law.
3. Route each signal with a four-way decision table
| Route | Use it when | Immediate action | Do not assume |
|---|---|---|---|
| Reply / support | The product works as described, but the buyer needs access, file-opening, or scope help. | Use the narrowest relevant reply and request only missing context. | A repeated question is automatically user error. |
| Documentation fix | The public page, welcome file, filename, or instruction is missing, stale, inconsistent, or hard to locate. | Correct the source of confusion and add a release check. | One edited sentence resolves every related case. |
| Bug investigation | Observed behaviour conflicts with intended behaviour and can be reproduced or bounded. | Capture version, steps, expected/actual behaviour, and a safe test fixture. | A report proves the cause, severity, or affected population. |
| Roadmap evidence | The request is outside current scope but describes a recurring task or unmet use case worth watching. | Record the task and theme, then set a review trigger. | The request is promised, prioritized, or broadly demanded. |
GitHub’s default labels distinguish categories such as bug, documentation, duplicate, enhancement, and question. Those labels are useful examples of consistent classification, but HoneKit does not require GitHub and this workflow should work in a local spreadsheet or buyer-owned workspace.
4. Copy-ready triage procedure
- Protect the original: keep the source message only in the system where it arrived and according to the process that governs that system.
- Write one observation: paraphrase the smallest task-relevant fact; do not copy signatures, payment details, private URLs, or unrelated attachments.
- Capture minimum context: add the product area, version, file, public URL, or step needed to understand it.
- Choose a provisional route: support, documentation, bug, roadmap, or unclear.
- Search for a theme: use stable labels and inspect similar open rows before creating a new category.
- Assign one next action: reply, edit, reproduce, request minimum detail, watch, or close.
- Set a review point: choose a date or factual trigger instead of leaving the item permanently open.
- Review retention: aggregate the lesson and remove row-level detail when the individual signal is no longer needed.
GitHub issue forms illustrate how structured inputs, validation, version fields, and default labels can make reports easier to triage. GitHub currently marks issue forms as public preview, so treat that page as an intake-design example rather than a dependency or permanent interface promise.
5. Cluster duplicates without inflating demand
Duplicate handling should reduce noise while preserving meaningful differences. Five messages using similar words may describe one documentation gap, several device-specific bugs, or unrelated requests.
- Compare the task, not only keywords. “Cannot open” may refer to checkout access, archive extraction, file format, or application compatibility.
- Compare the product area and version. Do not merge a stale-package report with a current-file report unless the observed failure is the same.
- Choose one neutral theme label and link related signal IDs. Keep the rows separate until the common cause is reasonably bounded.
- Count signals only when the collection method and time window make that count meaningful. Do not turn informal inbox volume into a market statistic.
- Record exceptions. A theme named “ZIP opening” can still contain separate Windows path, macOS extraction, incomplete-download, and unsupported-format cases.
Theme clustering helps a small team inspect patterns; it does not establish prevalence, causality, or business impact. Avoid public statements such as “many customers need this” unless a separate, documented evidence process supports the claim.
6. Worked example: from one message to one action
This is a hypothetical example. It does not describe a real customer, sale, support case, test, or product outcome.
| Stage | Example record | Reason |
|---|---|---|
| Raw task signal | A buyer says the welcome file tells them to open “reply-library.md,” but the archive contains “01_SUPPORT_REPLIES.md.” | Preserves the mismatch without retaining identity or unrelated order detail. |
| Observation | START-HERE filename does not match the released archive filename. | States what can be checked. |
| Context | Product version 2026-08; START-HERE section “First ten minutes.” | Gives enough context to inspect the release. |
| Provisional route | documentation | The issue may be fixed in the buyer-visible source rather than answered repeatedly. |
| Theme | first-use / filename-mismatch | Allows comparison with other welcome-file signals. |
| Next action | Check the final ZIP, correct the filename in source, rebuild, and add an exact filename assertion to package QA. | Turns the observation into a bounded corrective step. |
| Close condition | Updated package and welcome file agree; a clean-folder test opens the named file. | Defines evidence without promising that every environment will behave identically. |
If the archive already matches and the message lacks the filename or package version, route it to unclear and request only those details. Do not ask for a full desktop screenshot, home-directory listing, password, or checkout dashboard.
7. Run a weekly act / watch / close review
A short review prevents the sheet from becoming a second inbox. Use three outcomes and write the evidence for each.
| Outcome | Choose it when | Record before leaving review |
|---|---|---|
| Act | A bounded support, documentation, or reproducible bug action has an owner and a checkable finish. | Owner, smallest change, verification method, and whether public wording or package files change. |
| Watch | The task is plausible but evidence is incomplete, scope is outside the current product, or the safe action is not yet clear. | Theme, missing fact, review date, and trigger that would change the decision. |
| Close | The issue is resolved, merged as a duplicate, outside published scope, too vague after a minimum-detail request, or no longer relevant. | Reason, any reusable documentation lesson, and retention/deletion action. |
Do not use watch as a hidden promise. Do not use close to erase a still-valid safety or access problem. If a signal concerns a security vulnerability, regulated harm, payment dispute, or account compromise, follow the appropriate specialist process rather than keeping it in a general feedback queue.
8. Turn repeated confusion into a documentation repair
When a theme repeatedly routes to support, inspect the buyer-visible path before writing more replies.
- Compare the public product description, delivered filenames, START-HERE file, and support wording.
- Fix the earliest point where a reasonable reader receives incomplete or conflicting instructions.
- Add an exact release assertion for the fact that drifted: filename, version, URL, included item, support route, or limitation.
- Keep checkout claims, editorial guidance, and advertising visually and semantically separate.
- Do not publish a customer quote, screenshot, support volume, or before/after outcome as proof without a separate permission and evidence review.
For access, ZIP, refund, and scope replies, use the support and refund macros guide. A macro handles the immediate conversation; a documentation repair reduces the chance that the same ambiguity remains in the product.
9. Privacy and safety boundary
- Keep the triage row pseudonymous by default; use a local signal ID rather than customer identity.
- Do not copy card details, transaction identifiers, passwords, API keys, private customer exports, legal/tax records, or broad account screenshots.
- Crop or paraphrase error context and remove local usernames, paths, email addresses, tokens, and unrelated records.
- Limit access to the triage file and set a retention review that matches the actual purpose.
- Separate product feedback from testimonials, marketing permission, research consent, and customer-support records.
- Use a specialist incident path for security, account compromise, payment, legal, or regulated-risk reports.
HoneKit’s Privacy page describes this site’s analytics, advertising, checkout, hosting-log, and support-email boundaries. The Contact page lists minimum useful support details and what not to send. Your own product needs wording that matches its real systems and responsibilities.
10. Source notes and claim boundaries
These sources support the workflow’s observation, structured-intake, classification, and minimum-data principles. They do not certify HoneKit, prove product outcomes, or replace privacy, legal, security, or research advice.
- GOV.UK Service Manual — Analyse a research session: supports separating observations from interpretation, sorting observations into themes, determining findings, and deciding actions. Retrieved August 29, 2026.
- GitHub Docs — Syntax for issue forms: provides current examples of structured inputs, validations, version fields, and default labels; the page marks issue forms as public preview. Retrieved August 29, 2026.
- GitHub Docs — Managing labels: documents consistent categories including bug, documentation, duplicate, enhancement, and question. Retrieved August 29, 2026.
- UK Information Commissioner’s Office — A guide to the data protection principles: supports purpose limitation, data minimisation, accuracy, storage limitation, and security as general design boundaries. The page states that parts of the guidance are under review following legislative changes. Retrieved August 29, 2026.
Where HoneKit fits
HoneKit Starter Bundle includes a feedback-triage CSV, roadmap matrix, support drafts, onboarding files, and buyer-handoff materials. This free workflow can also be used independently in a local spreadsheet or another buyer-owned workspace.
HoneKit is a downloadable template bundle, not a hosted feedback database, help desk, research service, managed roadmap, live consulting, or regulated professional service. Advertising, if displayed, is separate from the editorial workflow and does not determine triage outcomes.
Before copying product-specific wording, review the Terms for current scope and checkout boundaries.