Collect questions in the words staff use
Ask staff to record the question they needed answered, where it arose and what they did next. Use approved interviews, support records or observation without copying unnecessary personal information into the inventory. A fictional operations team might repeatedly ask where to find the equipment-return form. Preserve that wording rather than rewriting every question into the terminology used by the document owner. Different language is part of the search problem. Keep a reference to the work context so the question remains understandable outside the original conversation.
Separate finding information from making a decision
Some questions ask where a form is stored; others ask whether an exception should be approved. Record that distinction. A knowledge assistant may help locate the relevant procedure without having authority to decide the exception. Do not define a successful answer as whatever makes the user stop asking. Specify whether the useful result is a document location, a supported explanation or a handover to a responsible person. This prevents the project scope from quietly expanding from information access into decisions nobody authorised.
Identify the source people currently rely on
For each question, record where staff obtain the answer today: a manual, a business system, a colleague or an undocumented practice. Ask the relevant owner whether that source is appropriate for the proposed use. A question answered only from memory may need documentation work before it belongs in the pilot. Do not assume the answer exists somewhere merely because the organisation has many files. Mark missing or conflicting information as a preparation task, with an owner, rather than expecting search to repair the gap.
Group questions without hiding differences
Combine obvious wording variants while retaining meaningful differences in team, service or situation. Two people asking about a return may mean returning equipment or returning a customer order. Keep those meanings separate. Record approximate frequency only when its basis is clear, and label staff estimates as estimates. Avoid inventing counts to make the opportunity look larger. The inventory should show which recurring needs share an answer and which require different context, not reduce every similar word to one broad category.
Choose a bounded pilot set
Select questions with clear business relevance, available sources and reviewable expected outcomes. Include some ambiguous and unsupported questions to test the limits of the proposed service. Keep a separate group for future possibilities so the first pilot remains manageable. Ask staff and source owners to review the selection before testing. Do not choose only questions whose answers the builder already knows by heart. The set should represent the intended use closely enough that its results inform a real decision about the next phase.
Keep the inventory connected to use
After a pilot, record which questions were answered usefully, which needed clarification and which exposed missing information. Retain the original question alongside any revised wording. Review whether staff still use other channels and why; an unanswered need may not appear in system logs if people gave up before trying. Add new questions through a documented process rather than silently changing the test set. A useful inventory remains a record of staff needs and source readiness, not a list of prompts engineered solely to produce impressive demonstrations.