Workflow Feedback Search Log Template
Copy a feedback search plan, source coverage log, and worked onboarding example. Record search terms, distinct evidence, missing sources, and next actions.
By Feedbackly · Updated
Product walkthrough
Watch the Feedbackly walkthrough before bringing a public request board into your feedback process.
Watch the product walkthroughSee how requests become a reviewable queue
Practical context for Workflow Feedback Search Log Template
Use this workflow feedback search log to find evidence about a specific customer task without losing track of where you searched. Copy the plan, coverage record, and fictional example into an internal document. The result should explain which sources were checked, which records matched, and what remains unknown.
This is a retrieval record. A request tracker holds individual problems; an analysis template compares themes; a meeting agenda records decisions. Keep those artifacts linked rather than copying their entire contents into this log. The log does not connect to your support tool, search private conversations, or create a taxonomy in Feedbackly.
Copy the search plan
Write the question before choosing keywords. 'Find feedback about onboarding' is broad. 'What prevents new administrators from importing a first usable dataset?' gives you a role, a task, and a boundary. Record a date window that matches the decision, and note whether older unresolved reports should be included separately.
List the language a customer might use rather than relying on your internal workflow name. For onboarding import, try setup, upload, CSV, connection, mapping, first report, and error wording found in a known report. Search terms separately when the source does not support combined queries. Do not paste Boolean syntax into a simple search field and assume it works.
Choose one or two known relevant records as a retrieval check. A search that misses them needs investigation: the wording, date filter, access permissions, or searchable fields may differ from your assumptions. Finding the checks demonstrates that those records are retrievable; it does not prove that every relevant report was found.
WORKFLOW FEEDBACK SEARCH PLAN Question / decision: [what must this search inform?] Audience and task: [role + attempted outcome] Included dates / version: [window; older unresolved evidence rule] Included / excluded situations: [boundaries] Sources to check: [board, support, survey, research notes] Terms to try separately: [workflow label, actions, objects, errors] Known relevant record checks: [references; expected terms] Search owner / review date: [person; date]
- +Include successful attempts with friction as well as blocked attempts.
- +Define exclusions, such as repeat imports by established customers.
- +Keep confidential source links in an appropriately restricted document.
Copy one coverage record per source
Record each source's actual search scope. Some systems search message text; others search only titles. An inaccessible interview folder is missing coverage, not a source with zero matching feedback. Keep raw result counts separate from reviewed matches, since broad terms such as 'setup' can retrieve unrelated work.
Give each included observation a stable evidence ID and retain its source reference. If one customer describes two obstacles, create two observations linked to the same source. If an email and support ticket repeat the same incident, link both to one observation. Count distinct accounts separately from messages and observations; do not add source totals together as customer demand.
Before sharing a summary, check a few included and excluded results against the original wording. Record why a borderline result belongs or does not belong. If the search misses a known report, preserve that gap and revise the terms or scope before presenting the collection as ready for analysis.
SOURCE COVERAGE AND EVIDENCE Source / owner: [system or collection; access owner] Checked on / available scope: [date; board, channel, folder, fields] Terms and filters actually used: [one line per search] Raw results / reviewed / relevant: [counts, if available] Known record checks: [found, missed, or unavailable + reason] Evidence: [ID | source reference | task | observation | account reference] Repeated incident references: [IDs linked together; counting rule] Excluded records and reasons: [examples] Missing sources or fields: [gap; owner; next step] Analysis handoff: [included IDs; uncertainty; next review]
- +Repeat this block for each source; include sources you could not inspect.
- +Log terms that failed as well as terms that returned useful records.
- +Show coverage limits beside any conclusion based on the search.
Worked example: finding first-import friction
This fictional example concerns a reporting product, not a measured Feedbackly customer result. The search owner looks for first-import friction among new administrators. A board search for 'onboarding' misses a known request titled 'CSV dates rejected'. Searching 'CSV' and 'date' separately retrieves it. The missed first query reveals a vocabulary gap, not an absence of onboarding feedback.
Across the reviewed board and support evidence, six relevant records describe four incidents from three accounts. Two records repeat one incident and another two repeat a different incident. One account has two separate incidents. Keep those units visible: six records, four incidents, three accounts. An interview folder remains unavailable, so the owner cannot claim coverage of all customer evidence.
The next action is to review the date-format problems and permission dependency separately. The log does not show how common either problem is among all new customers, and it does not establish which feature should ship. Move the included evidence IDs into analysis, retain the coverage gap, and ask the folder owner for access through the normal internal process.
FICTIONAL COMPLETED SEARCH Question: What blocks a new administrator's first usable import? Window: Last 30 complete days; repeat imports excluded. Terms: onboarding; setup; import; CSV; date; permission (separate searches). Coverage: Public request text and permitted support records checked. Known check: 'CSV dates rejected' missed by onboarding; found by CSV/date. Included: E01-E06; six records -> four incidents -> three accounts. Counting: E01/E02 repeat incident A; E03/E04 repeat incident B. Gap: Interview folder unavailable; research owner to resolve access. Next: Analyze date-format and permission problems separately; retain gap.
- +Search completion means the agreed sources were checked or marked unavailable.
- +A useful handoff contains evidence and a question, not only a keyword count.
Keep exploring this topic
These next reads help you move from the concept on this page to a framework, tool, template, or deeper comparison you can apply right away.
Questions teams usually ask
Can I use this log to search all feedback automatically?
No. It documents searches in systems you can access. Record each system's supported fields and filters, search it separately, and mark unavailable sources explicitly. Copying the template does not create any connection or import.
What does a search with no results mean?
It means that query returned no matches within the checked scope. Try customer wording and known-record checks, inspect date and status filters, and confirm the searchable fields. It does not prove that customers have no problem with the workflow.
Where can I search requests in Feedbackly?
In a board's dashboard, use Search requests to match text in request titles and descriptions. It uses a case-insensitive substring query, with a separate status filter. Try aliases one at a time. This does not search comments, other boards, support tickets, or research notes.
Keep public request evidence easy to revisit
Try a Feedbackly board for public requests, discussion, votes, and statuses. Use the board dashboard to find request text and keep this cross-source log in your internal workspace.