Crossing the chasm inside the account

Signing a contract with a new customer can feel like the finish line. In scientific organisations, it's closer to the starting line of a different race.

The scientists who evaluated your software were chosen for the evaluation team because they had a specific problem, a curiosity to explore a new approach, and enough motivation to invest time in the evaluation. They are, in Moore's terms [1], your early adopters. Winning them over is necessary, but it is only the start of a successful relationship.

The rest of the organisation didn't choose this tool. They weren't in the evaluation meetings, didn't feel the same urgency, and have workflows and workarounds that function well enough without it. From their perspective, something new has arrived on their desk. It’s uninvited, potentially disruptive, and requires effort they haven't budgeted for. The rational response is to carry on as before.

This is the chasm that exists inside every account, not just across a market. Crossing it requires a different approach from the one that won the evaluation.

Training is the obvious and important starting point. Scientists need to know how to use the tool, and, as the vendor, you are the right person to show them. But training alone doesn't cross the chasm. It enables scientists to use the software, but it often doesn't give them a compelling reason to change their habits.

Your job after training is less visible but more important: designing the conditions under which adoption can occur, and then supporting it without being its face.

Enable your champions, then get out of the way

The most persuasive voice in any scientific organisation is a colleague, not a vendor. A scientist who has used the software on a real project, with their data, and seen a result they trust. That person presenting their work carries more credibility than any vendor demo.

Your role is to identify who on the evaluation team is willing to share their experience and give them the support they need. Equip them with the right framing for an internal project update or team meeting. What did they do? What did they find? What would they do differently? Those are the questions that resonate with sceptical colleagues.

You don’t need to be in the room for the presentation, and it’s often better if you’re not.

Partner with leadership early

I've seen the same software deployed across two sites of the same multinational with dramatically different results. In Europe, where the purchase originated, senior leadership actively encouraged its use. The scientists engaged, and adoption grew. Scientists in the United States hadn't been involved in the evaluation. The software was deployed with limited context and without local champions. They were given the choice of whether to use the new platform, so most didn't.

The difference wasn't the software or the training. It was whether leadership created an environment where use was expected and supported.

The evaluation had been driven entirely from Europe, which meant the relationships, proof points, and leadership conversations all existed in a single geography. The vendor was having a single conversation with European leadership and scientists. The second conversation, with US leadership, never happened. Indifference was the predictable result of a decision made elsewhere and handed to scientists with no stake in it.

Management support doesn't mean mandate. It means making clear that this is a tool the organisation believes in, and that using it is consistent with how good work gets done here. That's a message you can help them deliver, but their leadership has to deliver it.

Make the results visible before asking for commitment

The hardest sceptics to reach are the ones who won't engage long enough to form a view. One approach that works is to make use expected without making the outcome binding. Integrate the software's outputs into existing workflows so the data appears in front of scientists without requiring active effort on their part. Let them observe as the results accumulate. If the software does what it should, the evidence makes its own argument over time.

I saw this described at a recent medicinal chemistry symposium. A team had introduced ML property predictions into their compound design process. Every compound got the predictions run. Scientists could still make whatever design decision they chose, but the data was consistently there, and trust built incrementally as the predictions proved their value in practice.

Your role here is practical: work with the internal champion or IT to make the tool present in the workflow from the start, rather than waiting for scientists to seek it out. Passive availability is not enough. The output needs to be where scientists already are.

The contract is permission to start

Crossing the internal chasm takes longer than most vendors plan for, and it requires a different kind of engagement from winning the evaluation. Training gives scientists the capability. What crosses the chasm is peer evidence, leadership context, and results that accumulate until sceptics form their own view.

None of that happens by itself. And it's harder to design if the pre-sale work didn't lay the foundation, including the believers, the relationships,  and the proof points that make adoption possible. The vendors who get this right treat the signed contract not as the end of the commercial process, but as permission to begin a different one.

[1] Moore, Geoffrey A. Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers. Harper Business, 1991. The chasm refers to the gap between early adopters and the early majority in technology adoption.