Set a Pilot Access Charter Before Research Data Is Shared
Help a research team define people, materials, and review steps before a pilot begins.
A pilot request rarely arrives with a clean scope attached. The customer wants to move fast, the champion on their side is excited, and speed starts to feel like the whole point. But a pilot that begins before anyone agrees on who touches the data, what each person does with it, and how the institution reviews that work turns into a pile of assumptions nobody signed up for. Setting an access charter before a single file moves keeps the pilot honest and protects you when someone later asks who approved what.
Why This Conversation Goes Wrong
Pilots move fast because the person asking for access wants a win, not a process. A core facility director or lab lead often has only a rough idea of who on their team will actually run the work, and assumes you can hand over broad access and let the team sort out the rest on their own time. That assumption puts you in a bad spot. If a data steward or compliance officer later finds that files moved without their approval, they hold you responsible, not just the internal team that asked. You also lose your ability to explain what the pilot actually tested, because nobody wrote down who touched what, under which terms. And once one analyst has access, others ask for the same without any review step, so a narrow pilot quietly becomes a wide one. A pilot with no defined scope is hard to defend later and even harder to renew.
How to Prepare Before the Call
Walk into this conversation already knowing what a workable charter requires. Know your company's standard terms for handling research data, know what your legal or scientific team needs before any file leaves your systems, and know which colleague owns exceptions when a customer pushes for something nonstandard. Read back through the account history for clues about who is actually involved. If you already discussed sample access earlier in the sales process, that conversation usually tells you who will show up wanting to touch data now, and Discover Prospective Sample Access Before Designing an Evaluation walks through how to surface that earlier rather than guessing at it during the access request.
Confirm your own approval chain too. Know who signs off on data sharing on your side and how long that decision realistically takes, so you don't promise a date you cannot hit once your own team weighs in.
What to Say When the Request Moves Fast
At a fictional partner university, a core facility director named Elena tells you, "My team wants access by next week so they can decide whether this data set fits their study."
You answer, "Let's make that specific before we schedule anything. Which people on your team need access, what will each of them actually do with the material, and does your institution require a review step for data like this."
Elena works through it out loud. "Two research analysts will run the initial comparisons, a training coordinator needs to walk them through the interface, and our data steward has to approve anything before it touches shared storage."
You reply, "Good, that gives us three distinct roles with three different needs. Let's write that down as a short charter so everyone understands their part before we share anything."
Elena pushes back once. "Can we skip the steward review for the pilot since it isn't a full purchase yet."
You hold the line. "No, that review has to happen regardless of whether this turns into a purchase, because it covers how the data gets handled, not what it leads to. I would rather take two extra days now than have your steward pull the pilot after your analysts already touched material outside policy."
Building the Charter Document
Write the charter down right after the call, while the details are still fresh in your head. A workable charter covers six parts.
- The research question the pilot is meant to answer.
- The named individuals who will access data or materials, listed by role.
- The single owner on the customer side who approves any change to that list.
- The exact materials or data types included, and just as important, what is excluded.
- The evidence or output the pilot produces, and who reviews it.
- A checkpoint date to confirm the pilot is on track or to close it out.
Send any question about data handling, storage, or security to the person who actually owns that policy on the customer side, not to whichever contact replied to your email fastest. If a purchase sits on the other side of this pilot, keep in mind the eventual order may need to run through a distributor rather than direct, and it is worth confirming that early rather than after the pilot wraps. Check Preferred Distributor Status Before Discussing a Purchase Route covers how to make that check part of your process, and you can read it at Check Preferred Distributor Status Before Discussing a Purchase Route.
Mistakes That Undermine the Charter
The biggest mistake is treating the charter as paperwork you fill out after access already went out. The order matters. The charter comes first, access comes second, every time.
A close second is letting the champion describe every role from memory without checking it against what the actual users need day to day. A director often does not know the details of an analyst's workflow, and a charter built entirely on their guesses tends to miss the person who actually needed access most.
Leaving the checkpoint date open ended is another common failure. "We will check in soon" is not a date, and pilots without a fixed checkpoint tend to drift for months with nobody accountable for closing them out.
Finally, do not assume a data steward or security contact will surface on their own. Most of the time they will not. You have to ask for that person by name, on the call, before you agree to a timeline.
How to Practice and Score This Conversation
This conversation is easy to describe and hard to run well under time pressure, which makes it worth rehearsing before a real pilot request lands. Practice the opening line with a colleague or manager. "Before we schedule access, I want to understand exactly what each participant will do and which review step your institution requires." Then listen for three things, a named owner, a decision date, and any stakeholder missing from the list. If nobody mentions a security or compliance contact, treat that gap as a real problem, not a detail to fill in later.
If you manage a team of research account executives, run this scenario through DealSpeak or another rehearsal setup where a rep plays this conversation against a champion pushing for speed. Score them on three outcomes, whether they got specific named roles instead of a headcount, whether they landed on one named decision owner on the customer side, and whether they set an actual checkpoint date before the call ended. If any of those three stayed vague, call it a miss and run the scenario again. You can find more scenarios built around this kind of account work at Biotechnology practice conversations.
A pilot without a charter is an experiment with no owner. Spend the extra minutes naming the roles, the reviewer, and the checkpoint date, and the pilot becomes something you can defend and renew instead of something you have to explain after the fact.
Practice these next
Connect an operational demonstration request to the customer’s actual decision process.
Help a research account executive turn a broad committee request into a bounded platform evaluation.
Guide a concern about computing capacity toward a technical discovery session that assesses whether the platform fits the laboratory’s computing environment.
Keep an exploratory consortium conversation separate from pricing or commitments while member institutions retain their own approvals.
Help a core facility define its real intake workflow and decision criteria before discussing a research platform evaluation.
Use customer dates and owners to plan a research evaluation without guessing at approval timing.