A simple customer research repository for a small team

A useful research repository should let a teammate answer three questions: what did we learn, what supports it, and does it apply to the decision in front of us? Start there before choosing specialized software or a large tagging system.

A spreadsheet and a few approved folders may be enough. The important part is the relationship between records and the rules for who can see them. An archive that everyone can search but nobody can interpret is not yet a usable research repository.

Separate the source, the finding, and the decision

Use three linked record types. Source records point to the session or other evidence. Finding records state what the team believes the evidence supports. Decision records explain what someone chose to do with it.

This separation follows the distinction between observations, findings, and actions in GOV.UK’s analysis guidance. The schema here is an original small-team adaptation. Read the analysis guidance.

Record	Minimum useful fields	What it prevents
Source	Reference, date, method, research question, relevant context, restricted evidence link, use/retention record	An untraceable quote becoming a permanent fact
Finding	Statement, scope, supporting source references, counterevidence, unresolved questions, review owner/date	A context-specific observation becoming a universal claim
Decision	Decision, date, owner, linked findings, rationale, next check	Research accumulating without a record of its use

These are logical records; they can be three tabs, linked documents, or tables in an approved tool. Do not introduce a complicated system merely to reproduce the field names.

Keep participant details out of the general index

Use a session reference in the shared research index. Keep the identity mapping and raw materials in an appropriately restricted location, with the access needed to administer the study and respond to data requests.

A participant code does not automatically make the material anonymous. A distinctive role, incident, or company description can identify someone. Review the content itself before expanding access.

GOV.UK’s data-management guide recommends collecting only necessary data, restricting access, linking consent records to the relevant materials, and setting a retention process. It is UK government guidance; your organization must establish the applicable privacy and retention requirements for its own research. Read the data and privacy guide.

Record permitted use in a form the team can act on. “Consent: yes” is too vague if one participant agreed to internal analysis while another also agreed to a specific external quotation. Keep the detailed permission record restricted and give readers the relevant use limits.

Fill in one complete chain before importing everything

Here is a fictional example showing how the three records connect:

Source S12: Interview conducted in September with an operator responsible for stock reconciliation. Evidence is a paraphrased account of comparing two exports when their update order was unclear. Raw notes are restricted. The source record links to its actual use and retention terms.

Finding F04: In the studied multi-system workflow, uncertainty about the latest update contributed to manual comparison. Supported by S12 and S15. S18 describes a separate approval requirement, which remains a counterexample to a single explanation. The finding does not estimate prevalence.

Decision D03: Test a clearer update-history view with relevant operators before committing to a broad dashboard redesign. Product owner owns the test; research owner will revisit F04 when results are available.

A reader can now follow the reasoning in either direction. They can ask why the test exists, or find which decisions may need reconsideration if F04 changes.

Add only tags that answer a real retrieval question

Start with a few consistent fields such as workflow, user responsibility, product area, and evidence method. Explain each in a small data dictionary. “Onboarding” may otherwise mean account creation to one person and a six-month implementation to another.

Do not tag every adjective in a transcript. Try three concrete queries first: “What do we know about stock reconciliation?”, “Which findings support this proposed change?”, and “What evidence contradicts this claim?” If the repository cannot answer them, improve the relationships or descriptions before adding more tags.

GOV.UK’s planning guide recommends storing findings where teams can use them and connecting research to decision-making routines. Read the planning guidance. A repository should serve those routines rather than create a separate reporting obligation nobody uses.

Give maintenance an owner

After each round, add the source references, update the findings, and link any resulting decision. On a regular review, check broken links, expired access, retention obligations, and findings that may no longer match the product or market context.

When a source is corrected or removed, inspect the findings and decisions that depended on it. Follow the actual deletion and retention process; do not keep a forbidden quote in a summary just because the original recording has been deleted.

Automated search and summaries can help people find records, but an answer should still point to its sources and respect their access and use restrictions. A small, maintained set of linked evidence is more useful than a large pile whose permissions and meaning have been lost.