Contents of the article

B2B customer research: turn sales conversations into content

Oura Works

12 minute read

Flow example: prospect questions are grouped into content needs and priorities.

B2B customer research helps teams understand the questions, pain points, and information buyers use when evaluating offers. Start from available inquiry and conversation notes, check the context, then turn the findings into website content and sales materials that can be reviewed.

A neat looking persona won't necessarily help the job if the content is just conjecture. Labels like “busy decision maker” don't explain what that person needs to read before accepting a proposal. The team needs examples of needs, reasons for delay, and evidence requested in the purchasing process.

This guide presents Oura's work recommendations for research used in website projects and service content. The company examples and conversations are simulations. The number of participants, methods, and data access are determined based on research needs; there is no universal sample size that guarantees all decisions are correct.

Summary for marketing and sales teams

Determine what content decisions to help with before collecting data.
Separate service users, technical reviewers, procurement and budget owners if their roles are different.
Note observed words or behavior before making an interpretation.
Highlight findings, conjectures, and unknowns.
Use findings to explain suitability, scope, process, and evidence on service pages.
Check the impact of changes along with the quality of inquiries, not just the number of clicks.

1. What business questions do you want answered?

Research begins with questions that influence the work. For example, why inquiries often ask for an explanation of the same scope, why buyers ask for additional documents before the proposal, or which parts of the offer are not understood. Clear questions help teams select relevant sources of information.

Write down the decisions you want to make after your research. If the decision is to split the service page, look for information about different needs. If the decision is to improve the form, look for bottlenecks in the request process. Avoid collecting all customer information just because it is available.

Oura suggests one quick note before the activity begins: purpose, type of buyer, available sources, information sought, and use of findings. These notes make it easier for the examiner to see whether the conclusions are truly derived from the data collected.

2. What resources are available?

Check the inquiries allowed for review, sales notes, support questions, reasons the proposal was delayed, as well as materials the buyer sent to explain his needs. These sources can show the language used by customers and information that is not yet available on the website.

However, each source has limits. The form shows what has been successfully submitted through the existing fields. Sales records may be more complete about active opportunities than buyers who have stopped contacting. Support questions usually come from customers who are already using the service.

Source	Useful information	Limits to note
Inquiry	Initial needs and how buyers describe them	Does not represent people who do not contact
Sales records	Questions, objections, requested documents	Completeness depends on the method of recording
Support	Difficulty in use and lack of explanation	Context after purchase
Proposal pending	Dependencies, reviews, scope mismatches	Reasons may not be fully recorded
Interview	Decision stories and job context	Samples and participants' memories have limits

Don't lump all sources together into a claim about “all customers.” Include the origin, period, and context of the note. Use the available information to formulate follow-up questions, then examine any areas that are still unclear.

3. How do roles differentiate in purchasing?

One company may involve several people with different information needs. Users rate whether the service helps with daily tasks. Technical reviewers look at dependencies as well as implementation risks. Procurement requires procurement information. The budget owner assesses investment priorities and rationale.

These roles do not always follow the same positions in all companies. Ask who is involved, what they review, and when they enter the process. Avoid assuming all purchases require identical committee composition.

Role in simulation	Questions that may be brought up	Helpful content
Operational users	What has changed in my job?	Flow, task examples, team contributions
Technical reviewer	What systems and access are needed?	Integrations, dependencies, job boundaries
Procurement	What to compare?	Scope, deliverables, procurement needs
Budget owner	Why is this work prioritized?	Problems, objectives, scope choices, evaluation methods

Use role maps to organize information, not invent individual motivations. If there is no data on any of the roles, mark it as a question that needs research.

Coverage and onboarding help the procurement team prepare the RFP brief. — Examples of B2B purchasing needs in logistics. This is an illustration, not a client procurement document.

4. How to structure a useful interview?

Select participants who relate to the research question. Prepare a topic, then ask for stories about experiences or decisions that actually happened. Questions like “tell me about the last time your team looked for a vendor” are more useful than asking people to agree on the benefits of a service the interviewer just described.

GOV.UK Service Manual on in-depth interviews discussing topic preparation, open questions, and follow-up to explore experiences. Adapt the method to the context of your business work; do not copy government service scenarios as sales procedures.

Examples of Oura working questions:

What triggers the need to seek services?
What information is sought in the initial stages?
Who participates in reviewing the options?
Which part is difficult to compare?
What documents or evidence is requested?
What causes decisions to be delayed?
What information do you wish was available earlier?

Ask for explanations when participants do not understand terms. Do not correct answers to match the offer. Note unanswered questions and differentiate stories of experience from opinions about future possibilities.

5. How to record observations and interpretations?

Observations are things found in notes or sessions. Interpretation explains its possible meaning. Actions are jobs chosen based on that understanding. Separate the three so the team can review conclusions without losing sources.

For example, participants asked for an integration diagram before a technical review. The observation is the demand for diagrams at certain stages. The interpretation may be that the dependency explanation is not sufficient. The action can add an integration summary that the technical team reviews. These three things are different and need to be noted separately.

GOV.UK session analysis guide suggests recording what is seen or heard before grouping and determining action. For Oura work, also keep the findings connected to sources that the examiner is allowed to access.

Simulation notes	Type	Usage
Participants asked for diagrams before the IT review	Observation	Evidence of information need
The integration explanation on the page may not be enough	Interpretation	Hypothesis to check
Prepare a dependency summary and review it with IT	Action	Planned content work
All companies definitely need diagrams	Claims are too broad	Do not use without justification

Customer inquiries, offers and targets are recorded before the brief is drawn up. — Examples of linking research sources to decisions. Observation needs to be separated from interpretation.

6. How do you determine which findings are suitable for use?

Group notes based on research questions. Look for patterns, differences, and exceptions. Don't turn one interesting story into a rule for the entire market. Note supporting sources and state if findings come from a limited group.

Oura suggests simple labels: supported by records, requires additional inspection, or preliminary suspicion. The label is not a scientific score. Its function is to help teams see the level of certainty when determining content work and avoid writing as if everything is known.

Contradictory findings are also useful. One buyer may want to request a proposal straight away, while another buyer may need guidance first. That difference could be the reason for providing two paths, rather than selecting one story and eliminating the other.

7. How to turn research into service pages?

Connect findings to buyer decisions. Suitability questions can shed light on who the service is available to. Coverage confusion can improve work outcomes as well as their limits. Requests for evidence may guide the selection of case studies or documentation that may be published.

Don't add all your interview notes to the page. Readers need structured explanations, not research transcripts. Choose the main answer, determine where it belongs, then link to supporting details as necessary.

Findings in simulation	Content work	Next check
Buyers find it difficult to differentiate between audit and implementation	Separate the scope of both services	Can the reader explain the differences?
The technical team requests a list of dependencies	Add access and integration needs	Accuracy review by technical owner
Buyers do not yet know the materials that must be prepared	Link checklist brief	Does the checklist help the next inquiry?
The available evidence is irrelevant	Choose cases with similar contexts	Check clearance, period and suitability

Service page content discusses how to structure benefits, scope, process, evidence, and CTAs once the information needs are known.

Cost, time, and suitability questions form the basis of the content of the service page. — Examples of applying research findings to service offerings; labels on images are not real respondent quotes.

8. How to use research for navigation and forms?

If buyers consistently confuse the two services, check the label as well as the explanation area. If they don't find the requirements, check the relationships between pages. Research can improve the flow of information without having to change the entire website design.

For forms, see what information is really needed for the team to follow through. Don't move all interview questions to mandatory fields. Detailed questions may be more appropriate to discuss during a consultation, once initial needs are known.

Check changes with relevant tasks. Ask people to find a service according to the scenario, explain its limitations, and then figure out next steps. See if they still need help. Record the results of the inspection as new findings, rather than immediately stating that conversions must have increased.

9. How to maintain information and quotations?

Use permitted data for work purposes. Limit copies, remove unnecessary identification, and determine who can view notes. Don't paste customer conversations or internal documents into AI services without checking permissions, intended use, and applicable policies.

Public quotes require separate scrutiny. Anonymizing names may not necessarily eliminate identities if job title, industry, and project details make people easily identifiable. If permissions or context are unclear, use a summary of internal findings or a labeled simulation example.

These recommendations are management of research work, not a replacement for organizational policy. For sensitive data or uses that are not yet understood, involve the data owner and regulatory authorities before proceeding.

The source, scope, and limits of the explanation are checked before publication. — Example of review of material originating from research. The agreement on the panel is illustrative.

10. How to assess results after content changes?

Check first whether the changes address the discovered needs. Sales can record recurring questions, completeness of inquiries, as well as information that helps buyers continue. Combine these findings with website data that is available.

An increased number of inquiries does not automatically mean increased quality. Conversely, clearer forms can reduce inappropriate requests while helping with follow-up on relevant requests. Establish definitions with the team before assessing results.

Use it GA4 lead measurement guide to separate website actions from sales assessments. Note the period, campaign changes, and data limits so that conclusions do not attribute all results to the new copy alone.

Inquiry is forwarded to CRM and sales while events are logged to analytics. — Example of measurement after content change. Fictitious names and fields; event has not proven the quality of the prospect.

11. Example of research flow for integration services

the marketing team wants to improve the CRM integration page because inquiries often do not explain the system used. They review permitted records, interview relevant buyers, and request explanations from the delivery team.Simulation:

Initial findings show two needs: business buyers want to know processes and deliverables, while technical reviewers need dependencies and access. The team separated the business explanation and technical requirements sections on the same page, then added a brief checklist.

The initial form asks for the system to be used optionally so that inquiries can still be submitted when the buyer does not yet know. The team evaluates whether the next piece of information is easier to complete. This example explains the work process; does not state Oura engagement results or percentage increase.

Decision example: distinguishing between information problems and service mismatches

Imagine sales receives a question about integrating with an unsupported system. Adding explanations to the website can reduce confusion, but does not change the capabilities of the service. Findings need to be separated so that the team doesn't solve the entire problem with copywriting.

Example findings	Examination	Possible decision
Buyers don't know what integrations are available	Information is approved but hard to find	Clarify the scope of the page
Buyer requires a system that is not yet supported	Confirm service owner	Explain the boundaries and pathways of special needs
Buyer misunderstands processing time	Check project dependencies	Explain the estimation stages and requirements

Don't use illustrative quotes as testimonials. Summarize the findings, sources, and level of certainty. Review changes with sales after the page is published: are there fewer repeat questions, are needs clearer, or do new misunderstandings arise. These observations help the next content cycle without claiming all changes originate from the website.

Checklist before findings are used

Research questions as well as decisions are assisted in writing.
The source, period and context of each note are provided.
Participants according to the needs studied.
The interview questions did not ask participants to agree to the offer.
Observation is separated from interpretation and action.
Limited findings are not written as universal rules.
Differences in needs between buyers are still noted.
Sensitive information as well as quote permissions are checked.
Each important finding has a clear content assignment.
A team of experts reviews the technical explanation.
The next inspection as well as the owner is determined.

Conclusion: make research a decision material

B2B customer research is useful when the findings change an obvious task: page content, evidence, navigation, forms, or sales materials. Start with a real question, keep the context in mind, then review whether the new explanation helps the buyer understand the offer.

Discuss website needs and buyer information with Oura. You can bring a list of sales questions as well as offer materials that can be reviewed. The scope of research and implementation is agreed based on needs and available access.

FAQs

What do you do if you don't have clients yet?

Starting from relevant prospective buyers, team experiences that are marked as guesses, as well as questions that arise in initial conversations. Don't write off these assumptions as customer findings. Plan inspections as data becomes available.

How many interviews are required?

The number of questions follows, the diversity of needs, as well as the depth of information required. There is no one number that applies to all projects. Note limitations and move forward if important decisions are still not sufficiently supported.

Is the form data sufficient?

Forms can help identify initial needs, but don't always explain the reasons for a buyer's decision or roadblocks. Use additional sources if the information sought is not yet available. Don't add a long field just to replace the interview.

How to avoid leading questions?

Ask for stories about experiences, use open-ended questions, and don't include the benefits of the service you want to prove in the questions. Ask for reasons and examples when the answer is still general.

Can AI summarize notes?

Can be considered after permissions, access, and usage policies are checked. Use the appropriate notes for processing, then compare the summary with the source. Do not accept AI interpretations as findings without review.

When do findings need to be updated?

When offers, markets, buying flows, or inquiry types change, and when inspection shows old explanations are no longer helpful. Updates follow decision needs; Don't change the date just to make the article look new.