# OfferKu B2B User Research and Requirement Evidence Templates

Version: 2026-08-13

This no-registration template separates two kinds of records:

- offerku-b2b-interview-guide.csv captures questions, observed behaviour, quotes, and factual notes from an individual session.
- offerku-b2b-requirement-evidence-matrix.csv captures problems synthesised across sessions, evidence strength, solution routes, and decisions.

Every row marked example or synthetic is fictional and does not represent a real person, company, or research finding. The empty rows are ready to complete. This template is not privacy, data protection, ethics, or legal advice. Ask your organisation's data protection, information security, or legal specialists to review your actual practice.

## Role map

Do not interview only the buyer or the person who requested a feature. A B2B workflow is usually shaped by goals, rules, daily operations, and system constraints.

    Business sponsor / buyer
              │ goals and budget
              ▼
    Process owner / approver ── rules ── security and compliance
              │
              ▼
    Requester / end user → frontline operator → system administrator
              ▲                                  │
              └──── implementation / support ────┘

Select roles relevant to the research question rather than mechanically sampling every group:

| Role group | What to learn |
| --- | --- |
| Requesters and end users | Goals, triggers, actual steps, waiting, and rework |
| Frontline operators | Repeated work, exceptions, compensating actions, and handoffs |
| Process owners and approvers | Decision rules, accountability, service levels, and escalation |
| System administrators | Permissions, configuration, integrations, data, and maintenance |
| Security, compliance, and finance | Risk, audit evidence, retention, and control requirements |
| Buyers and business sponsors | Outcomes, budget, adoption constraints, and success measures |
| Implementation and support | Repeatable variation, one-off variation, and long-term support cost |

## Workflow from planning to decision

### 1. Turn assumptions into research questions

Write what the team must learn to make the next decision. Replace “customers need automatic approval” with “how do people request and approve access today, and which steps create delay or risk?” Keep each round focused on the highest-priority questions and name the roles and workflow stages needed to answer them.

### 2. Recruitment, informed consent, and data minimisation

Recruit current or likely users of the workflow. Before the session, provide an information sheet in language the participant can understand. It should explain at least:

- who is conducting the research, its purpose, and what will happen;
- what data will be collected, how it will be used, who will receive it, and how long it will be kept;
- whether anyone will observe and whether audio, screen, or video recording is planned;
- that participation is voluntary and consent can be stopped or withdrawn;
- the data controller, other processors, and routes for questions or complaints.

Keep evidence of informed consent for every participant according to your organisation's process. Obtain specific agreement for recording. If a participant does not agree to recording, state that in recording_status and do not record by default.

Minimise personal data:

- Use opaque research_id and session_id values in the CSV files.
- Do not enter names, email addresses, phone numbers, precise addresses, account identifiers, customer secrets, or identifying company details.
- Store contact details, consent evidence, and research notes separately with restricted access.
- De-identify quotes before adding them to the CSV. Prefer a factual note when a verbatim quote is unnecessary.
- Delete data according to the communicated retention period and keep records organised so material can be found and deleted after consent is withdrawn.

### 3. Ask open, neutral, evidence-seeking questions

Start with the most recent real event instead of asking participants to predict the future:

- Prefer: “Please walk me through the last time you completed this task.”
- Prefer: “What happened next?” “What information did you look at?” “Where did you wait?”
- Avoid: “Would you use automatic approval if we built it?”
- Avoid: “Isn't this step inefficient?”

Use neutral_prompt for the opening question. Put relevant follow-up facts in evidence_quote_or_note. Ask participants to show current tools, artefacts, and steps when possible and when covered by consent.

### 4. Separate observation, quotation, and interpretation

Keep interview evidence traceable:

| Field | Recording rule |
| --- | --- |
| observed_behavior | Observable facts such as what was opened, copied, or waited for; do not infer motives |
| evidence_quote_or_note | A de-identified quote or factual note; label which kind it is |
| current_workaround | The route the participant actually uses today |
| frequency and impact | The participant's stated or independently verified range; use unknown when uncertain |
| follow_up | The next observation, verification, or disconfirming check |

Put interpretation and synthesis in problem_statement, evidence_strength, and solution_route in the evidence matrix. Do not rewrite an interpretation as something the participant said.

### 5. Combine evidence without turning it into a vote count

After a research round:

1. Normalise role_type and workflow_stage labels.
2. Group records that describe the same underlying problem and retain traceable source_session_ids.
3. Count unique sessions in evidence_count, not the number of copied quotes.
4. Check whether the pattern repeats across relevant roles, segments, and observed behaviour.
5. Assess frequency, impact, and risk separately. A loud opinion is not necessarily frequent; a senior title is not stronger evidence.
6. Look deliberately for contrary evidence, successful paths, and roles that are not affected.

Define evidence_strength for your team. A practical starting point is:

- weak: one session, hearsay, stated future intent, or an unobserved assumption;
- directional: the same pattern appears in independent sessions, but role or segment coverage is still limited;
- strong: the pattern repeats in the target scope and is corroborated by behaviour, artefacts, logs, or other evidence.

These labels support judgement; they are not a fixed sample-size formula. Adjust the research depth to the risk, variation, and cost of the decision.

### 6. Choose standard, configuration, custom, or do not build

Use this sequence so a requested solution does not jump straight into development:

1. Is the problem real, repeated, and important enough?
2. Which roles and workflow stages are affected, and are the boundaries clear?
3. Can the existing product, process, or configuration solve it?
4. What behavioural or outcome change would prove the solution works?
5. Are implementation, security, privacy, migration, and long-term support costs acceptable?

| solution_route | Use when |
| --- | --- |
| standard_feature | Multiple target customers share a stable problem, it fits the product core, and consistent behaviour has clear value |
| configuration | The underlying workflow is shared, while fields, rules, roles, thresholds, or presentation vary by customer |
| custom_extension | The need is validated but narrow, with explicit commercial value, interface boundaries, ownership, and a support model |
| do_not_build_yet | Evidence is weak or conflicting, a workaround is sufficient, the request is off-strategy, or risk and maintenance exceed value |

For every decision, complete owner, next_test, decision_status, and review_date. “Do not build” can be a reversible decision based on current evidence rather than a permanent rejection.

## CSV field guide

Interview guide:

| Field group | Fields |
| --- | --- |
| Traceability | research_id, session_id, owner |
| Sample and context | role_type, company_segment, workflow_stage |
| Research design | research_question, neutral_prompt |
| Raw evidence | observed_behavior, evidence_quote_or_note, current_workaround |
| Severity | frequency, impact |
| Governance | consent_status, recording_status |
| Next step | follow_up |

Evidence matrix:

| Field group | Fields |
| --- | --- |
| Requirement | requirement_id, problem_statement, workflow_stage |
| Coverage and sources | role_types, evidence_count, source_session_ids |
| Severity | frequency, impact, risk |
| Current state | existing_workaround, evidence_strength |
| Decision | solution_route, decision_status, owner |
| Learning loop | next_test, review_date |

Use semicolons inside multi-value fields. Prefer YYYY-MM-DD dates. Keep IDs stable and do not renumber them after sorting.

## CSV safety and quality checks

- Both files follow RFC 4180: the first row is a header, every record has the same field count, and fields are double-quoted.
- Never allow a CSV cell to begin with an equals sign, plus sign, minus sign, or at sign. Rewrite it as a safe text label to prevent spreadsheet formula injection.
- When importing into spreadsheet software, explicitly set ID, status, and date columns to text or date types so values are not silently rewritten.
- Before publishing or sharing, check for personal data, customer secrets, consent scope, duplicate session_id values, missing sources, and decisions without an owner.

## Official GOV.UK references

- [Plan user research for your service](https://www.gov.uk/service-manual/user-research/plan-user-research-for-your-service)
- [Using in-depth interviews](https://www.gov.uk/service-manual/user-research/using-in-depth-interviews)
- [Getting informed consent for user research](https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research)
- [Managing user research data and participant privacy](https://www.gov.uk/service-manual/user-research/managing-user-research-data-participant-privacy)