How to run unmoderated usability tests for complex enterprise B2B workflows

Unmoderated usability testing works well for consumer apps with short, self-contained tasks. But enterprise B2B software is a different problem. Workflows span multiple screens. Tasks depend on data that already exists in the system. Users need domain knowledge to make sense of what they are looking at. And the environments themselves may require configuration before a participant can do anything meaningful.

None of this makes unmoderated testing impossible for enterprise products. It does mean the standard playbook—write a few tasks, send a link, collect recordings—will produce weak results unless you invest in preparation that most guides skip over entirely.

This article covers how to design, set up, and run unmoderated usability tests for the kinds of complex, data-dependent workflows common in enterprise B2B software.

Why unmoderated testing matters for enterprise B2B

Moderated testing is the default for many enterprise research teams, and for good reason. A skilled moderator can guide participants through unfamiliar environments, answer clarifying questions, and probe deeper when something interesting happens.

But moderated sessions are expensive to schedule. Enterprise participants—procurement managers, system administrators, financial controllers—are hard to recruit and harder to get on a calendar. Running moderated sessions across time zones with senior professionals often means weeks of scheduling for a handful of sessions.

Unmoderated testing lets you:

• Reach more participants without coordinating calendars
• Test across time zones and geographies simultaneously
• Observe unassisted behavior, which more closely mirrors how people actually use enterprise tools in their daily work
• Run studies faster, especially when you need to iterate between sprints

The tradeoff is that you lose the ability to intervene in real time. Everything the participant needs to succeed must be built into the study design itself. For complex B2B workflows, this requires more upfront work—but the payoff is research that scales.

The core challenge: realism

Most enterprise workflows are not self-contained. Consider a few examples:

• A supply chain manager cannot evaluate a demand forecasting screen without historical order data already in the system
• An HR administrator cannot test an employee onboarding flow without existing organizational structures, roles, and policies configured
• A financial analyst cannot assess a reconciliation workflow without transactions, accounts, and matching rules pre-loaded

If the test environment is empty or filled with obviously fake data—"Company ABC," "Test User 1"—participants cannot engage with the task the way they would in their real work. They end up guessing, or they focus on the artificiality of the data instead of the interaction design.

Realism in unmoderated enterprise testing has three dimensions:

1. Data realism—the system contains enough representative data for the workflow to make sense
2. Environmental realism—the product is configured in a way that mirrors how a real customer's instance would look
3. Task realism—the scenario reflects an actual goal the participant would have in their day-to-day work

Getting all three right is the core challenge, and the rest of this article addresses how to do it.

Building realistic test environments

Start with a reference customer

Rather than inventing a fictional scenario from scratch, base your test environment on a real (anonymized) customer setup. Talk to your customer success or solutions engineering team—they often maintain demo environments that reflect realistic configurations.

Take one of these and strip out identifying information. Replace company names, employee names, and any sensitive figures with realistic equivalents. The goal is a sandbox that feels like a real instance without exposing anyone's actual data.

Create synthetic data that behaves like production data

Synthetic data is not the same as dummy data. Dummy data fills fields. Synthetic data reflects the patterns, distributions, and relationships present in real usage.

For example, if you are testing an analytics dashboard, your synthetic data should include:

• Realistic variance across time periods (not flat lines or perfect trends)
• Edge cases the user might encounter (missing values, outliers)
• Enough volume to trigger pagination, filtering, and aggregation behaviors

Work with your engineering team to write scripts that generate this data, or export anonymized subsets from staging environments. Document the dataset so you can reuse and update it across studies.

Pre-configure the environment for each task

Enterprise products often require setup before a user can perform a workflow—permissions, integrations, preferences, organizational hierarchies. In a moderated session, you might walk a participant through this. In an unmoderated session, all of this must be done in advance.

Create a checklist of preconditions for each task you plan to test:

• What user role and permissions does the participant need?
• What objects, records, or configurations must already exist?
• Are there dependent workflows that need to have been completed first?
• Does the participant need to be at a specific point in a process?

Set all of this up before the participant touches the environment. If multiple participants will use the same environment, decide whether they can share a single instance (read-only tasks) or whether each needs their own (tasks that modify data).

Provide environment access that actually works

This sounds obvious, but it is a common failure point. Enterprise products often have complex authentication—SSO, MFA, VPN requirements. For unmoderated testing, you need to remove as many access barriers as possible without compromising security.

Options include:

• Dedicated test accounts with credentials provided in the study instructions
• Magic links that bypass authentication for the sandbox only
• Sandbox environments hosted on a separate domain that does not require VPN access

Test the access flow yourself, end to end, from outside your corporate network, before launching the study. If a participant spends ten minutes trying to log in, you have lost the session.

Designing tasks for unmoderated enterprise testing

Write scenario-based tasks, not instruction-based tasks

An instruction-based task tells participants what to click: "Go to Settings, select Integrations, and connect the Salesforce connector." This tests whether participants can follow directions, not whether they can accomplish a goal.

A scenario-based task gives participants a goal and context: "Your team has just started using Salesforce and your manager has asked you to connect it to the platform so that contact data syncs automatically. Set this up."

Scenario-based tasks are more realistic and reveal more about how people think through workflows. They are also harder to write well, because you need to provide enough context for the participant to understand what they are trying to achieve without giving away the solution.

Break complex workflows into stages

A workflow that takes 15 minutes in production is too long for a single unmoderated task. Participants lose focus, and if they get stuck early, you lose data on everything that follows.

Instead, break the workflow into logical stages. Each stage should have a clear starting point and a clear completion point. If stages are dependent—stage 2 requires the output of stage 1—set up the environment so the output of stage 1 already exists, and let participants start stage 2 from that point.

This gives you usable data even when participants cannot complete every stage.

Build in escape hatches

In a moderated session, you can help a stuck participant move past a blocker. In an unmoderated session, you cannot. If a participant gets stuck on step 2 of a 5-step workflow, you lose insight into steps 3 through 5.

Escape hatches solve this. After each critical step, provide a fallback: "If you were unable to complete the previous step, click here to continue with a pre-configured version." This lets participants skip ahead to the next stage without abandoning the study entirely.

You can implement escape hatches as:

• Links to a version of the environment where the step has already been completed
• Instructions to navigate to a specific screen where they can pick up the next task
• A brief note explaining what would have happened, with a prompt to continue

Provide context documents when the task requires them

Enterprise workflows often involve reference materials—a spec sheet, a policy document, a spreadsheet of data to import. If the task would normally involve these materials, include them in the study.

Attach files directly to the task instructions or provide links. Keep them short and clearly labeled. If a participant would normally look up information in another system, provide that information in a reference document instead.

Recruiting the right participants

Generic usability testing panels rarely include people with experience in enterprise procurement software, ERP configuration, or clinical trial management. You need participants with relevant domain expertise, not just general tech literacy.

Screen for domain knowledge, not just job title

Job titles in enterprise software vary wildly across organizations. A "Business Analyst" at one company might do work that a "Product Operations Manager" does at another. Screen for specific tasks and experiences rather than titles:

• "Have you configured automated workflows in an enterprise platform in the past 12 months?"
• "Do you regularly work with financial reconciliation across multiple accounts?"
• "Have you administered user roles and permissions for a team of 20 or more?"

Use your own customer base (carefully)

Your existing customers are often the best source of qualified participants. They have domain expertise and familiarity with the problem space. However, they also have familiarity with your specific product, which can bias results if you are testing new designs.

Be explicit about what you are testing. If it is a redesigned workflow, tell participants that the interface may look different from what they are used to. If you are testing a net-new feature, existing customers can be excellent participants since they understand the context but have no learned behavior for the new interaction.

Coordinate with your customer success team to avoid over-soliciting the same accounts.

Compensate appropriately

Enterprise professionals are expensive to recruit. Their time is valuable, and their employers may need to approve participation. Offer compensation that reflects this—industry rates for senior enterprise professionals in unmoderated studies typically range from $100 to $300+ depending on the role, the length of the study, and the domain.

Analyzing results from unmoderated enterprise studies

Unmoderated studies generate recordings, written responses, and behavioral data. For complex enterprise workflows, analysis requires understanding not just what participants did, but why they did it—and that can be harder to assess without a moderator's follow-up questions.

Watch recordings with task context in mind

When reviewing session recordings, keep the task preconditions visible. A participant's confusion might stem from the task design or environment setup rather than the product itself. Note when issues appear to be environment-related versus interaction-related so you can distinguish genuine usability problems from study artifacts.

Code problems by workflow stage

Rather than tagging issues by screen or UI element alone, organize findings by the workflow stage where they occurred. This helps product teams understand where in the process users struggle, which is often more actionable than knowing which button was hard to find.

Triangulate with follow-up questions

Most unmoderated testing platforms let you include post-task and post-study questions. Use these to fill gaps the recording cannot:

• "What were you trying to do when you paused on that screen?"
• "Was there a point where you felt unsure about what to do next? What happened?"
• "How realistic did this scenario feel compared to your actual work?"

The last question is particularly important for enterprise testing. If participants tell you the data or environment felt unrealistic, factor that into how much weight you give their behavioral data.

Tools like Dovetail can help you organize and analyze these recordings and responses at scale—tagging patterns across sessions, clustering findings by workflow stage, and connecting usability insights to broader product themes across multiple studies.

Common mistakes to avoid

Testing too much in one session. Enterprise workflows are long. Resist the urge to test an entire end-to-end process in a single unmoderated session. Thirty minutes is a reasonable upper limit, including orientation and follow-up questions.

Underinvesting in environment setup. If you spend two days writing tasks and two hours setting up the test environment, the ratio is wrong. For complex B2B workflows, environment preparation often takes more time than study design—and it should.

Assuming participants will figure it out. In a consumer app, you can drop someone on a home screen and say "complete a purchase." In enterprise software, participants need more context: who they are in the scenario, what has already happened, and what they are trying to accomplish. Provide a brief orientation at the start of the study.

Ignoring pilot testing. Always run at least two pilot sessions before launching. Have someone outside your team attempt the study from scratch, on their own, with no additional guidance. If they get stuck on setup or access, your real participants will too.

Making unmoderated testing a repeatable practice

The upfront investment in test environments, synthetic data, and task design pays off most when you can reuse these assets across studies. Maintain a library of sandbox environments, test datasets, and task templates that your team can adapt for new research questions.

Document what worked and what did not after each study. Over time, you build institutional knowledge about how to test your specific product's workflows in an unmoderated setting—what level of data realism is sufficient, which access methods work best, and how much orientation your participants need.

Enterprise B2B products are complex, but that complexity does not make them untestable without a moderator. It makes them worth testing more carefully.

Yes, but you need to plan carefully. Never use real customer data in test environments—create synthetic datasets that mirror the structure, volume, and complexity of production data without exposing personally identifiable information. Work with your security and legal teams to establish what can be shared externally. Sandbox environments with anonymized data are the standard approach, and most enterprise organizations already have processes for provisioning these for QA or demo purposes.

For qualitative usability testing, 5–8 participants per distinct user role is a reasonable starting point. Complex B2B products often have multiple user types—an admin configuring a system behaves very differently from an end user completing a daily task. You may need separate studies for each role. If you are testing a single workflow with one user type, 5 participants will typically surface the most critical usability issues. For quantitative benchmarking, you will need larger sample sizes, often 20 or more per segment.

The biggest risks are participants getting stuck with no way to ask for help, unrealistic test environments that produce misleading results, and recruiting participants who lack the domain expertise to complete the tasks meaningfully. You can mitigate these by providing clear setup instructions, building realistic sandbox environments pre-loaded with test data, screening participants rigorously for relevant experience, and including escape hatches in your task design so participants can move forward even if they cannot complete a step.