Use a Mapping Workshop When Teams Disagree on a Sample Handoff

A sample sits on a bench because the receiving lab thought the sending team already logged its readiness check, and the sending team thought receiving would confirm it on arrival. Neither team did anything wrong by its own rules. The rules were different. As a customer success scientist, you did not write either team's process and you should not rewrite it either. Your job is to make the current process visible so the people who own it can decide what to fix.

Why this conversation goes wrong

Handoff disputes turn into blame conversations fast. Someone missed a step, a sample degraded, a run got delayed, and now two teams each believe the other broke the process. When you get pulled into that conversation, the temptation is to act as referee, decide who was right, and hand down a fixed version of the workflow. That approach fails for three reasons.

First, you were not there when the sample moved, so you're working from secondhand accounts. Second, even if you could see every step, you don't own the protocol. Laboratory management and quality own the change control process, not the vendor account team. Third, when you propose a fix, you inherit responsibility for how it works. If the new process breaks something else six months later, the customer remembers that you delivered it, not the team.

The teams involved often don't disagree about what should happen. They disagree about what does happen, because the process changed informally over time. A technician left, a new hire learned the job from a coworker instead of the document, and small deviations accumulated until the written handoff map stopped matching daily practice. Nobody signed off on any of that drift. It just happened.

How to prepare

Before you schedule anything, gather what you can from records you already have access to, like ticket history, prior complaints, or notes from your own site visits. Do not walk in with a diagnosis. Walk in with questions.

Identify who actually owns the process. That is usually the laboratory manager for operational steps, and the quality liaison if the handoff touches document control or a validated procedure. If you're not sure who owns it, ask before the meeting. Inviting the wrong people wastes everyone's time and you will need a second meeting anyway.

Ask each team to bring one recent, specific sample. Not a hypothetical, not a summary of how things usually go. A real sample, with a real date, that both sides can walk through step by step. Specificity kills vague blame. When someone has to describe an actual Tuesday instead of a general impression, the account gets more honest and more useful.

Pull the existing written handoff map if one exists. You will need it during the workshop to compare against what people actually describe doing.

If your account also has an open thread about a related workflow issue, look at Set Boundaries for a Workflow Observation Follow Up for how to keep that separate conversation from bleeding into this one. Mixing an observation follow up with a handoff dispute confuses ownership and slows both down.

What to say

Open by naming what you can offer and what you can't. An operations coordinator might start the call this way. "Our teams keep pointing fingers over this handoff. Can you just rewrite the process so it works better."

You answer directly, without dodging the request or pretending you can grant it. "I can't rewrite your process, that decision sits with your lab manager and quality liaison. What I can do is run a workshop where both teams map what actually happens today, using two or three real samples. That usually surfaces the gap fast. Can we get the lab manager and the quality liaison in the room."

The coordinator pushes back a little. "We've mapped this before. Nothing changed."

You hold your position without getting defensive. "I want to find out why the last map didn't stick. Sometimes a map gets written and nobody updates it when staffing changes. I want to compare the written version against what happens with an actual sample from this month, not what should happen."

During the workshop itself, ask each team to walk through one sample from the moment it's ready on one side to the moment it's confirmed received on the other. For each step, capture who sent it, who received it, what information was required, where the decision point was, and what time the transfer happened. Write it down where everyone can see it. Then hold that account next to the written map and mark every place they diverge.

In one real version of this exchange, the sending team assumed the receiving lab checked sample readiness on arrival, because an earlier version of the process had them do that. The receiving lab assumed the sending team already confirmed readiness before shipping, because a newer training document said so. Both teams were following a rule that used to be true. The gap wasn't carelessness. It was an update that never reached everyone.

Mistakes to avoid

Do not propose a fix during the workshop, even an obvious one. The moment you suggest a specific change, the room stops mapping and starts debating your idea. Keep the session focused on describing what happens now.

Do not let the conversation turn into an argument about who caused a specific failed sample. That's a different conversation, usually with different stakeholders, and it derails the mapping exercise. If someone raises it, acknowledge it and park it for later.

Do not skip inviting quality when the handoff touches a controlled document. Even if the lab manager says it's fine to handle informally, a change to a validated procedure without quality's involvement can create a compliance problem down the line.

Do not let one team's account stand in for the truth. Map both sides independently, then compare. If you only hear from the more vocal team, you will build a map that confirms an existing bias instead of describing the actual process.

Do not close the meeting without naming an owner for the next step. A great map with no assigned owner just becomes a document that sits in a folder.

How to practice and score it

Have a trainee run this scenario with a fictional customer before doing it live. Give them a scenario where an operations coordinator asks them to rewrite a process, and time them for ten minutes mapping the workflow using sticky notes or a shared table.

Score the practice on three things. Did the trainee ask for a specific, recent, observed sample instead of accepting a general description. Did they capture the points where the two team accounts disagreed, rather than smoothing over the conflict to keep the conversation comfortable. Did they name the actual process owner by role, out loud, before the session ended.

Watch for the moment when the trainee gets asked to fix the process directly. That's the pressure point. A trainee who caves and starts proposing changes needs more practice holding the line between clarifying a process and owning it.

Biotechnology practice conversations cover this scenario along with related ones, including staffing changes that affect a rollout timeline, which you can read about in Revise an Adoption Milestone When Laboratory Staffing Changes. Rehearsing the mapping workshop in DealSpeak before you run it for real gives you a chance to make your mistakes in private.

A finished map does not fix anything by itself. It gives the laboratory a concrete, current picture of its own process, which is what its governance review actually needs. Your value in the room is clarity, not authority. Leave the decision with the people who have to live with it.