How to Conduct SaaS and B2B Software Customer Research: From Account Usage to Renewal Evidence

SaaS and B2B software customer research must simultaneously answer three questions: whether certain user types can complete critical tasks, whether the enterprise has achieved verifiable business value, and whether those who control budgets and renewals recognize that value. High login frequency does not equal high output, procurement satisfaction does not mean frontline adoption, and low seat usage may simply reflect over-purchasing relative to the actual qualified population. Aggregating individual survey responses, product logs, and contract status directly into a single "customer health score" conceals missing evidence and role conflicts.

The correct starting point is not a quarterly satisfaction survey but a choice of an account lifecycle decision: improving time-to-first-value, expanding departmental adoption, reducing administrator burden, or assessing renewal risk. Next, define the account, organizational units, roles, key tasks, observation windows, and business outcomes. Product research helps explain mechanisms, but renewals are also influenced by budget, organizational restructuring, procurement policy, alternatives, and contract timing—correlation cannot automatically become causation.

First Map Out Accounts, Organizational Units, and Four Role Types

• Economic buyer or budget holder: Evaluates business outcomes, total cost, supplier risk, and next-period investment but may not personally operate the product.
• Procurement, security, and legal: Focus on contracts, data, integrations, audits, and vendor processes; should not be asked to rate task-level usability.
• Administrator or implementation lead: Understands configuration, permissions, migration, training, support, and internal rollout; a key source of information on adoption conditions.
• Frontline user: Can report task completion, errors, workarounds, collaboration, and realized benefits but may not know renewal criteria or budget.

One person may hold multiple roles, so do not rely solely on job titles. Ask whether they are involved in selection, contracting, configuration, training, daily tasks, and renewal. Large accounts may also use and pay by region, business line, or subsidiary separately; the U.S. Census Bureau's guidance on economic surveys also shows that the enterprise, reporting unit, and final aggregation levels can differ. The research database should preserve the relationships between individuals, teams, accounts, and parent groups rather than treating twenty respondents from the same group as twenty independent customers.

Critical Task Coverage Is Closer to Value Than Seat Activation

Suppose an account purchased one hundred seats, seventy are assigned, and in the last thirty days thirty-two people completed a core approval task. Using purchased seats as the denominator, the task usage rate is only 32%, which looks alarming. But the administrator confirms that only forty roles actually need to initiate or complete this task; the remaining seats are used for low-frequency viewing, auditing, or backup. Using qualified users as the denominator, task coverage is:

32 ÷ 40 = 80%

Both numbers are true, but they answer different questions. 32% suggests that seat allocation and purchase volume may need review; 80% indicates high task coverage among target roles. If the team demands that all features "boost penetration" based on total seats, it may drive meaningless usage; if it looks only at qualified users, it may ignore over-purchased seats and weak internal diffusion. Reports should present the number and definition of people who purchased, assigned, qualified, active, and completed critical tasks.

Tasks also need defined start and end points. The GOV.UK Service Manual defines digital transaction completion rate as completions divided by all starts and emphasizes that the start, end, and failure of real tasks must be identifiable. The same applies to SaaS: opening a page is not starting an approval, and clicking save does not necessarily produce a usable result; events should be defined based on the work customers aim to accomplish, and handle returns after save, offline steps, and bot or internal test accounts.

How to Divide Work Among Product Logs, Surveys, Interviews, and Business Records

Logs show who completed which events under what version, permissions, and time; they do not know the user's original goal or capture work done in spreadsheets, emails, or meetings after export. Task tests show whether representative users can correctly and efficiently complete goals. NIST's usability measurement separates effectiveness, efficiency, and satisfaction, with common evidence including task success, time, errors, and self-reported experience.

Surveys are suitable for estimating difficulty, perceived value, and support experience across target roles, provided the denominator and exposure are correct. Interviews are suitable for reconstructing procurement, implementation, alternative tools, and organizational negotiations. Support records show issues raised but not those who never asked for help or have given up. Contract and financial records show renewal, expansion, or downsell outcomes but do not explain the separate roles of product, organization, and budget.

Before connecting these data sources, define authorization, purpose, minimal fields, and access controls. Research invitations should not secretly become sales-based monitoring of individuals; if responses may be seen by the account team, state this before participation. Those needing follow-up may voluntarily leave contact details, kept separate from confidential analysis data.

A Hundred-Account Experiment: Improved Time-to-First-Value, Yet Renewal Remains Uncertain

Below is an example account-level experiment. The team saw that many new customers invited users but did not complete their first cross-role workflow in time. The new onboarding flow first has the administrator select a real scenario, then invites one task initiator and one approver to complete the first closed loop with sample data; product features, pricing, support entitlement, and customer success teams remain unchanged. To avoid users in the same account seeing different flows, the team randomly assigned one hundred concurrent qualified new accounts at the account level to existing versus new versions, fifty each.

The primary outcome is completing the first real closed loop within fourteen days. In the existing version, 31 accounts achieved this (62%); in the new version, 41 accounts achieved it (82%), a difference of 20 percentage points. Using a simple two-proportion approximation, the 95% confidence interval is roughly 2.8 to 37.2 percentage points. Current evidence supports that the new version improves first-value attainment under these conditions.

At six months, 39 accounts in the existing version renewed (78%); 42 in the new version renewed (84%). The difference is 6 percentage points, with an approximate interval from -9.3 to 21.3, still including zero. This cannot be presented as "the new version increases renewals by six percentage points"; it can only be said that the point estimate is higher but uncertainty is large. Renewal is a more distal outcome, passing through diffusion of use, value demonstration, support, organization, and budget.

The experiment must also check balance on account size, industry, and contract cycle, analyze by original assignment, and record concurrent interventions beyond onboarding. If customer success managers spent more time only on new-version accounts, the version effect is confounded with human support. Even if first-value improvement is clear, guardrails such as administrator hours, support volume, misconfiguration, and user understanding should be observed to prevent buying superficial achievement with hidden service costs.

Multi-Role Disagreement Is Not Noise but Renewal Information

In another example, 48 accounts up for renewal had both economic buyer and administrator responses. Among economic buyers, 36 leaned toward renewal (75%); among administrators, 30 believed implementation was sustainable (62.5%). Looking only at the two marginal proportions suggests overall account health.

Paired analysis shows: 24 accounts had both positive, 12 only buyer positive, 6 only administrator positive, and 6 neither positive. Eighteen accounts had directionally inconsistent responses, accounting for 37.5%. Buyer positive but administrator negative may indicate an acceptable value narrative but accumulating governance burden; administrator positive but buyer negative may indicate smooth usage but business value not entering budget discussions. Actions should be designed by conflict type rather than averaging the two scores.

Paired analysis also reminds researchers: a single contact's rating cannot represent a customer. Each account should have an evidence matrix indicating which roles are covered and which critical questions are missing. A missing budget-holder response should not be automatically treated as budget-holder satisfaction; missing frontline user responses cannot be substituted by administrators.

Renewal Research Must Go from Contract Outcomes Back to the Value Chain

A verifiable value chain can be written as: target roles are granted access, complete critical tasks, outputs are used downstream, organizational metrics change meaningfully, and evidence is seen by budget holders before renewal. Each link requires events and accountable people. Many logins without usable outputs do not prove value; business metric improvements without reasonable comparison cannot be fully attributed to software.

Churn interviews should confirm the original contract goals, deployment scope, actual usage, alternative processes, organizational events, and the final decision sequence. Asking former customers to multi-select from "price, features, service, competitor" compresses a multi-stage decision into a label. Also cover downsells, silent churn, and prospects who never bought; interviewing only willing churn narrators misses those with the most severe disconnection and broken relationships.

Customer Health Scores Should Preserve Raw Evidence and Missing Status

Health scores can be useful for organization, but don't coarsely sum signals across different proportions, levels, and timeframes. At minimum, retain raw fields for task coverage, failures, administrator burden, role attitudes, support resolution, contract, and organizational changes, with timestamps, denominators, and missing flags. No data should be "unknown," not automatically zero or full score.

High usage may stem from mandatory processes; low usage may be due to seasonality or low-frequency tasks; many tickets may indicate product problems or active deployment; zero tickets may mean very smooth operations or users giving up. Any automated risk label should allow account teams to add auditable context and must not be used to reduce service, change prices, or evaluate individual employees without disclosure.

Boundaries for Cross-Period and Customer Group Comparisons

Quarterly trends must keep roles, account stage, product version, and invitation criteria consistent. If last quarter was mainly administrator responses and this quarter is mainly procurement, score changes may only reflect role shifts. Reports should present the number of enterprise accounts, individuals, responses per account, and role coverage, so that multiple responses from large accounts do not dominate the total.

Grouping by industry, size, plan, and region requires sufficient bases, and avoid post-hoc selection of the most flattering combinations. Different groups have different purchase goals, implementation resources, and contract durations, so raw renewal differences cannot be directly attributed to product experience. When causal claims are needed, randomize where feasible at the appropriate level; when randomization is not possible, pre-specify comparisons and remaining confounders.

Publishing Checklist

1. Define relationships among account, parent group, business unit, team, and individual.
2. Verify budget, procurement, administration, usage, and renewal roles beyond job titles.
3. Key tasks have real starts, ends, failures, and qualified-user denominators.
4. Report purchased seats, assigned seats, qualified users, active, and task completion separately.
5. Logs, surveys, interviews, support, and contract data answer only their respective questions.
6. Keep multi-role evidence, disagreements, and unknowns per account—do not let one person represent all.
7. Account-level interventions are assigned by account to avoid version contamination within the same organization.
8. Explain first value, diffusion, business value, and renewal separately by evidence distance.
9. Health scores trace back to raw fields and do not optimistically treat missing or forced usage.
10. Reports distinguish product, implementation, customer organization, commercial, and market factors.

For sampling units and multi-role pairing, continue reading B2B enterprise sample design; for key task research, reference Post-usability-test survey; for account experiments, plan with Randomization and sequence control, while long-term versions and fields are preserved via Data versioning and lineage. What SaaS customer research truly needs to deliver is not a health leaderboard but a verifiable evidence chain—from target roles completing tasks, to the organization seeing value, to the renewal decision.