Find Out Why New Users Avoid a Lab Workflow

A new laboratory team adopts your platform, and everything looks fine except one step. Users skip it, work around it, or quietly pass it to someone else. The supervisor notices and asks you to fix it. Your first instinct might be to schedule more training, but that response treats a symptom as if it were the disease. Before you recommend anything, find out what actually happens at the point where users stop, and why.

Why This Conversation Goes Wrong

Most supervisors read a skipped step as a discipline problem. Staff are not following the protocol, so someone needs to make them follow it. That framing puts you, the customer success scientist, in an impossible spot. You do not manage the lab staff. You cannot assign consequences, adjust schedules, or order anyone to change how they work. If you accept the premise that this is a compliance issue and promise to get the team in line, you set an expectation you cannot meet, and you skip the one thing that would actually help, which is understanding why smart, trained people are choosing to avoid a step in their own workflow.

The real cause is usually one of a few things. Users do not know how to do the step correctly. They know how but do not trust the result enough to rely on it. They cannot get to a tool or system they need at that point. Or the step depends on a handoff to another person or team, and that handoff broke, often because someone changed roles and nobody updated the workflow map. Training fixes the first cause and does nothing for the other three. Recommending it before you know which one you are dealing with wastes everyone's time and can leave the actual gap open for months.

How to Prepare Before You Ask

Before you sit down with anyone, pull the current handoff map for the workflow in question and the approved materials that cover the step users are avoiding. Check whether either one has been updated since the last staffing change on the account. Look at usage data or support tickets to find the exact point where users stop, not just the general area. Knowing that people abandon the workflow after sample prep is useful. Knowing that they stop the moment they need to route a sample to a second reviewer is far more useful.

Identify two or three users who touch this step in different ways, a bench scientist, a shift lead, someone newer to the role. Their answers will differ, and the differences tell you something. Line up a short conversation with the supervisor and, separately or together, whoever owns the handoff on the other side of the gap. If this account has already had milestones slip because of a similar disconnect, the approach in Run an Onboarding Action Review After Early Milestones Slip (/industries/biotechnology/blog/biotechnology onboarding action review) works through how to structure that kind of review with a supervisor in the room, and much of it applies here.

What to Say When You Sit Down With the Team

Let the supervisor raise the issue first, in their own words. A supervisor might open with, Can you get the team to actually follow the sample handoff step. Do not accept the authority they are handing you. Say something like, I cannot direct your team, but I can help find out why they are avoiding this step. The users I talked to said they are not sure who receives the samples once prep is finished. Can we map that handoff with the lab manager before we talk about training at all.

The supervisor might push back or, more often, realize something out loud. They might say, Wait, I thought Marcus still owned that handoff, he moved to the other shift in July. That is usually the moment the real cause surfaces. Nobody removed Marcus from the workflow map when he changed shifts, so users are avoiding a step that points to a person who is not there to receive it.

From there, propose something concrete. You can say, Let's confirm who owns that handoff now, update the map, and put it in front of the team this week. I will check back with a few users after that to see if the step is clear. The supervisor agrees, and the conversation ends with an owner, a date, and a way to verify the fix worked, not just a promise that people will try harder.

Mistakes That Make the Problem Worse

The most common mistake is prescribing training on the spot because it feels like the safe, obvious answer. It is rarely obvious once you have talked to actual users. A close second is agreeing, even quietly, to direct staff behavior. That erodes your role and puts you on the hook for outcomes you cannot control. Another mistake is treating one user's explanation as the full picture. If you only interview the person the supervisor points you to, you get one version of a problem that likely has several contributing causes.

Closing the meeting without naming a specific owner is just as damaging. A vague agreement to update the workflow map goes nowhere without someone whose name is attached to it and a date it needs to happen by. And skipping the follow up check is how these gaps reopen. If nobody confirms that the update actually reached the team and made sense to them, you find yourself back in the same conversation in three months.

How to Practice and Score This Conversation

This is a skill you build through repetition, not by reading about it once. Set up a practice run with two fictional users who give different reasons for avoiding the same step, one citing confusion about ownership, the other citing a tool they cannot access. Have the trainee interview both, then summarize what they heard without assigning blame to either user or to the team as a whole. That summary is the real test. It shows whether the trainee is diagnosing a system or diagnosing people.

Score the proposed action against three things. Does it name a specific owner on the customer side. Does it point to an approved resource rather than an improvised one. Does it include a way to check, after the meeting, whether the handoff is actually understood. A plan missing any of those three is not finished yet, no matter how confident it sounds.

DealSpeak is built for exactly this kind of rehearsal, letting you run this conversation against an AI counterpart playing the supervisor and get scored on how well you separated the real cause from the assumed one. Biotechnology practice conversations (/industries/biotechnology) cover this scenario alongside related ones, including Review a Partial Delivery Hold Before Splitting a Laboratory Order (/industries/biotechnology/blog/biotechnology partial delivery hold review), which walks through a different kind of handoff breakdown further down the supply chain.

Keep the Root Cause in View

A skipped step is information, not an accusation. Your job is to find out what it is telling you before anyone reaches for training or blame. Do that consistently, and the fixes you propose actually hold.

You can rehearse this exact conversation in the Biotechnology practice conversations library before it happens for real. When you have this one down, read Run an Onboarding Action Review After Early Milestones Slip next.