Run a User Feedback Session Before Planning More Research Training

A customer success scientist gets a support ticket that reads like every other one. Adoption is low on a workflow step, and the account team wants to schedule more training. The instinct is reasonable and often wrong. Training fixes a knowledge gap. It does nothing for a broken handoff, an unclear owner, or a step that nobody explained was theirs to do. Before you book a session, you need a real conversation with the people who actually touch the workflow, and that conversation has its own risks if you run it badly.

Why this conversation goes wrong

Most feedback sessions fail before they start because the customer success scientist walks in with a solution already picked. You open with "we think a training session would help" and the customer nods along, because agreeing is easier than pushing back. Now you have booked a session nobody asked for and the actual barrier is still sitting there unnamed.

The second failure mode is vagueness. You ask "how is the workflow going" and get a shrug or a general complaint about busy schedules. General questions produce general answers, and general answers do not tell you where in the process a user actually stops moving. You need the specific point of friction, the specific words the user said, and the specific person or system that owns that point. Without those three things you are guessing, and a guess dressed up as a training plan still costs the lab time and does not fix the problem.

The third failure is treating the session as a data collection exercise instead of a decision point. You leave with three pages of notes and no action. The lab leader reads a summary email a week later and nothing changes because nobody agreed on what to try first. A feedback session only earns its time if it ends with one choice, one owner, and a date to check whether that choice worked.

How to prepare before the session

Look at the support tickets and usage data before you schedule anything. If three different users mention the same step in three different ways, that is your starting point, not a fresh open ended survey. Write down the specific workflow step you suspect is the problem and hold it loosely. You are not there to confirm your theory. You are there to test it against what users actually say.

Decide who needs to be in the room. A lab administrator can describe patterns across many users, but only the bench scientists who hit the wall can describe what actually happened in the moment. If you can, get both. If you can only get one, get the person closest to the work, not the person closest to the account.

Prepare four or five open questions and nothing else. Do not prepare a slide deck pitching a training curriculum. The moment you show a slide about a solution, the conversation stops being a feedback session and becomes a sales pitch for something you have not yet earned the right to propose. If you want a companion approach for cases where you need feedback from a wider group rather than one account, read about how to Use User Office Hours to Gather Adoption Feedback. Office hours work well for broad signal across many labs. A direct listening session works better when one account has a specific pattern you need to understand in depth.

What to say

Start by naming what you noticed, not what you plan to do about it. In a session with a core facility, the customer success scientist opens with, "I saw that training requests keep coming in for the sample intake process, but attendance at the sessions we offered has been low. I want to understand what is actually happening before we plan anything else."

The lab administrator responds, "Honestly, people ask for training because they do not know what else to ask for. New users get stuck and nobody has told them who to go to."

That answer is still too general to act on, so the scientist asks the question that does the real work. "Can you walk me through the last time a new user got stuck? Where exactly did they stop, and what did they say was confusing?"

The administrator thinks for a moment and says, "It was a new hire two weeks ago. She logged the sample intake correctly, but then she did not know who releases the sample for processing after that. She assumed the software would route it automatically. It does not. Someone has to manually flag it, and that someone is not always obvious depending on which team is on rotation."

Now you have something specific. The barrier is not a software skill gap. It is an unclear handoff between intake and processing, made worse by a rotating assignment that even experienced staff sometimes struggle to track. Training on the software will not touch that problem. A clearer intake contact, a posted rotation schedule, or a short reference sheet might. Ask the administrator directly, "Of the options we just named, which one would you want to try first, and how would we know in two weeks whether it worked?" Let the customer pick. Your job is to surface the barrier and the choices, not to decide for them.

Mistakes to avoid

Do not accept the first answer as the real answer. "Training attendance is low" is a symptom. Keep asking where and what until you reach a specific step and a specific quote from a user. If you stop at the symptom, you will build a plan around the wrong problem.

Do not let the conversation turn into a list of every frustration anyone has ever had with the product. Feedback sessions can drift into a general complaint session if you do not redirect. When that happens, bring it back with a simple line like, "That is useful, let us come back to it. Right now I want to stay on the intake handoff since that seems to be where new users get stuck."

Do not propose a fix before you understand who owns the step that is broken. If the barrier is a local process question, like who releases a sample, that decision belongs to the lab's own operations owner, not to your training catalog. Routing it correctly matters more than looking helpful in the moment.

Do not leave the room without a single agreed action and a date. A session that produces sympathy but no decision has wasted the time of everyone who showed up.

How to practice and score it

This kind of session is hard to get right the first time because it requires you to sit with discomfort. Silence after an open question feels like a gap you should fill, but filling it usually means suggesting an answer for the customer instead of letting them find their own. Practicing the exchange out loud, with a partner playing the lab administrator, exposes exactly where you jump in too early or where you accept a vague answer instead of pushing for specifics.

DealSpeak gives you a way to rehearse this conversation against an AI counterpart built for biotechnology accounts, so you can practice the pushback and the redirect before you are in front of a real customer. You can browse Biotechnology practice conversations to find scenarios that match this kind of listening session, then run it several times and watch how your questions change the quality of the answers you get. Score yourself, or have a manager score you, on three things. Did you ask for a specific moment and specific words rather than a general impression. Did you resist naming a solution until the customer named the barrier. Did the session end with one action, one owner, and a date to revisit it.

If the barrier turns out to be a disagreement between two teams about who owns a step, rather than a single unclear contact, a listening session may not be the right format at all. In that case, a structured session built for cross team disagreement works better, and you can read about that approach in the article on how to Use a Mapping Workshop When Teams Disagree on a Sample Handoff.

The payoff

A good listening session replaces a training request nobody wanted with a specific fix the customer chose themselves. It takes less time than building a training curriculum and it is far more likely to actually change what happens at the bench. Practice the questions until asking them feels natural, because the value of this conversation lives entirely in the specifics you manage to pull out of it.