B2B user research is difficult because the buyer, decision-maker, administrator, end user, approver, and implementation partner are often different people. A request such as “we need bulk export” may mean that a manager needs a review artifact, an operator is bypassing a slow workflow, and a security reviewer is worried about data leaving the system. Copying the request directly into a backlog mixes the problem, proposed solution, and sales commitment.
An actionable round of B2B research should produce three artifacts:
- A role and workflow map: who initiates, performs, approves, configures, supports, and pays for the work.
- Interview records: recent tasks with observations, participant notes, and researcher interpretations kept distinct.
- A requirement evidence matrix: evidence across roles that supports a standard feature, configuration, integration, bounded customization, service change, or a decision not to build.
This guide includes two registration-free CSV templates and an end-to-end workflow. They help organize evidence; they do not replace privacy, security, or legal review.
1. Download the templates
- Download the B2B interview guide and session record
- Download the B2B requirement evidence matrix
- Read the English field guide
The example rows are explicitly labeled synthetic. They are not OfferKu customer findings. Copy the blank template rows for your research and never present the examples as real evidence.
2. Begin with the decision
“Understand customer needs” is too broad. State the decision the team needs to make:
Decide whether contract approval should become a standard workflow for the target market or whether current configuration can handle the relevant customer segment.
Turn assumptions into research questions:
| Unverified statement | Research question | Evidence needed |
|---|---|---|
| Every customer needs bulk export | Which role exports what during which task, and what happens next? | Recent example, frequency, destination, failure impact |
| Admin setup is too complicated | Which step fails, and is the cause concepts, permissions, or system feedback? | Observed attempt, error, support history |
| Enterprise customers require customization | Does variation come from regulation, organization, or a legacy system? | Cross-customer comparison, fixed constraints, workarounds |
The GOV.UK Service Manual recommends agreeing research questions, user groups, and methods around decisions the team needs to make, then feeding findings into planning and prioritization. See planning user research.
One-page research brief
Before recruitment, align sales, implementation, customer success, design, and engineering on:
- Decision: which release, workflow, or allocation could change.
- Known facts: product data, support records, contracts, or prior research.
- Assumptions: who currently believes each claim and what could disprove it.
- Target roles: people needed for evidence, not only the easiest contacts.
- Scope: what this round includes and excludes.
- Outputs: role map, workflow, evidence matrix, and next tests.
- Ownership: who recruits, moderates, records, analyzes, and decides.
Deprioritize a research question if no plausible answer would affect a decision.
3. Map roles around the workflow
Use a real workflow rather than job titles alone. A discount-approval process may involve:
| Role in the workflow | Desired outcome | Evidence the role may hold |
|---|---|---|
| Buyer or budget owner | Cost, contract, and supplier risk | Procurement rules, budget cycle, alternatives |
| Business decision-maker | Business result and adoption | Success criteria, priorities, organizational constraints |
| Administrator | Configuration, permissions, maintenance | Setup history, access requests, support cases |
| Frontline user | Complete the task with fewer errors | Actual actions, workarounds, recent failures |
| Approver | Control risk and exceptions | Approval rules, rejection reasons, audit requirements |
| Implementer or integrator | Deliver migration and connectivity | Field mappings, dependencies, rollout failures |
| Security, legal, or finance | Enforce data and commercial boundaries | Review controls and blocking conditions |
Job title is not a stable segment. An “operations manager” may configure the product at one company and file support tickets at another. Record role_type as the participant's role in the workflow. Keep only company_segment attributes that are relevant to the decision and permitted to be collected.
4. Turn research questions into neutral prompts
Research questions belong to the team; interview prompts are what participants hear. Ask about recent, real behavior:
- Think about the last time you completed this task. What triggered it?
- Who took part, and what did each person do?
- Walk me through what you actually did, in order.
- Where did you wait, repeat work, copy data, or ask for help?
- When the task fails, what happens next and who is affected?
- What workaround do you use today? What makes it acceptable or costly?
- What was the most recent exception, and how was it resolved?
- Which information, permissions, and system connections are prerequisites?
Follow with “when,” “who,” “how,” and “can you show me the last example?” rather than asking for abstract preference.
Replace leading questions
| Avoid | Ask instead |
|---|---|
| Would you use bulk export if we built it? | When did you last need data outside this system? |
| Is this approval screen difficult? | Starting with the incoming request, show me how you process it. |
| How much would you pay for automation? | What time, people, and external costs does this work require today? |
| This feature is important, right? | What happens if this step cannot be completed this month? |
In-depth interviews can reveal users' work, circumstances, and problems. GOV.UK recommends organizing topics around research questions, using open and neutral prompts, pursuing real examples, and rehearsing the guide before the first session. See its in-depth interview guidance.
5. Obtain informed consent and minimize data
The CSV is not a contact database. Use session_id to connect approved records. Do not put names, phone numbers, email addresses, customer secrets, or unauthorized transcripts in the interview file.
Before a session, participants should understand:
- who is conducting the research and why;
- what data will be collected, how it will be used, and who will receive it;
- whether observers, audio, video, or screen recording are involved;
- that participation is voluntary and can stop or be withdrawn;
- how long data will be retained and whom to contact;
- which material might be quoted in anonymized form.
Track participation consent and recording consent separately. Agreement to an interview does not automatically mean agreement to a recording. GOV.UK's informed-consent guidance and participant-privacy guidance recommend collecting only what is necessary, limiting access, keeping consent records with the covered data, and deleting data according to the approved policy or a valid withdrawal request.
Follow the laws, contracts, and policies that apply to your organization and participants. Ask a qualified privacy or legal owner to review sensitive, employee, child, or cross-border research.
6. Separate observation, participant evidence, and interpretation
A useful record lets a colleague distinguish:
- Observed fact: the participant copied an order ID across three systems.
- Anonymized quote or note: the participant said this happens every Friday.
- Researcher interpretation: inconsistent identifiers may be causing rework.
- Open question: do other roles use the same process?
- Next action: inspect logs, observe another segment, or test a prototype.
Do not present an interpretation as an observed fact or splice comments to strengthen a conclusion. Use evidence_quote_or_note for an anonymized excerpt or summary. Store approved raw material in the organization's research system and connect it through session_id.
Immediately after each session, the moderator and note-taker should separately record the most important observation, contradiction, and unknown. Reconcile those notes against the evidence without forcing every finding into a feature.
7. Consolidate evidence in the matrix
Each matrix row describes a problem, not a predetermined feature:
- problem_statement: role, context, blocked outcome, and consequence.
- role_types: roles reporting or affected by the problem.
- source_session_ids: traceable evidence rather than “customers say.”
- frequency and impact: separate occurrence from consequence.
- existing_workaround: current substitute and its cost.
- evidence_strength: distinguish one report, repeated behavior, direct observation, product data, and multiple independent sources.
- risk: security, compliance, revenue, delivery, or usability exposure.
- next_test: evidence still needed before a decision.
Interview counts are not market share
If three of five participants mention a problem, the result shows a pattern in that research round; it does not establish that 60% of customers have it. Interviews explain mechanisms and variation. Estimate prevalence and commercial impact with appropriate sampling, product data, support cases, and business evidence.
Contradictions matter. If four administrators ask for more configuration but one avoids configuration by simplifying the workflow, the exception may reveal a less expensive product direction.
8. Choose a solution route from the evidence
| Route | Supporting signal | Validate next |
|---|---|---|
| Standard feature | Stable, similar problem across target customers | Default experience, migration, compatibility |
| Configuration | Same outcome but different roles, rules, or thresholds | Setup burden, permissions, testable combinations |
| Integration or API | Variation originates in existing systems or data flow | Responsibility, failures, maintenance |
| Bounded customization | Strategic customer has a hard constraint configuration cannot meet | Return, reuse, versioning, exit plan |
| Service or process change | Problem comes from rollout, training, or ownership | Whether product behavior must change |
| Do not build yet | Evidence is weak, off-strategy, or too costly over its lifecycle | Revisit trigger and missing evidence |
Record contrary evidence, impact on existing customers, an owner, and review_date. Sales urgency can inform a decision, but it does not replace user evidence or lifecycle cost.
For authorization requirements, first distinguish subject, tenant, resource, action, and data scope. Use this template alongside the B2B SaaS permission model guide.
9. Synthetic example: discount approvals
This example demonstrates evidence flow; it is not a real customer study.
After receiving a “bulk approval” request, a team studies requesters, regional managers, and finance:
- Requesters actually struggle with unclear rejection reasons and repeat entry.
- Regional managers need faster sequential review only during month-end backlogs; high-discount requests still require individual scrutiny.
- Finance requires separation between requester and final approver, plus an audit trail when rules change.
- The current workaround is a shared spreadsheet followed by repeated actions in the product.
The matrix now contains three problems rather than one feature request:
- rejection feedback is not structured;
- low-risk, similar requests take too long to process;
- high-risk decisions require separation of duties and traceable rules.
The next test need not be one-click approval. The team can test structured rejection reasons, low-risk filtering, and sequential review, then separately validate the permission, confirmation, and audit boundaries of any bulk action.
10. Definition of done
- Every finding traces to an anonymized session ID or another named evidence source.
- Buyers, administrators, end users, and delivery roles are not treated as one persona.
- Observation, participant note, interpretation, and assumption remain distinguishable.
- Contradictions and uncovered groups are recorded.
- Interview counts are not presented as market prevalence.
- Priority problems have an owner, next_test, and review_date.
- The decision considers standardization, configuration, integration, service, customization, and not building.
- Personal data, recording, access, and retention follow valid consent and organizational policy.
- The result is shared back with the sales, implementation, success, and product teams involved.
For the wider role and delivery process, read the B2B product manager guide. To turn the research into a portfolio artifact, continue with the B2B SaaS design project. Browse the B2B product management topic for related guides.