Barriers to adoption in B2B

For providers of complex solutions in complex domains, getting your customers and their users to embrace and operationalise your products can become an endless cycle of resistance and compromise.

A sale is not adoption. The contract may be signed and the system installed, but until the people who use it every day have made it part of how they work, neither the customer nor the provider sees the value they were promised. In my experience, the barriers are rarely just technical, and they need to be planned for as deliberately as the product itself.

Why it’s hard

Management and users value different things

B2B sales teams do deals with management, not with end users. And the larger the organisation you are selling into, the bigger the gap between what management value and what users value.

Management buy for strategic reasons: compliance, cost, fewer suppliers, better reporting. Users judge a system by whether it makes their shift easier. A casino may buy a new management system to strengthen its AML controls, while its cashiers judge it by how many clicks it takes to cash a ticket with a queue at the window. Both views are valid, but only one of them was in the room when the deal was done.

Workarounds

Once a system has been deployed for some time, users will inevitably have found clever ways to fill gaps in functionality that was never explicitly provided. A simple example is an operator repurposing a field in a player profile, say an unused fax number, to record a player’s preferred table. If we later deprecate that field, or the new system has no equivalent, we break a process we never knew existed.

Workarounds rarely appear in a specification or a demo. They live in the habits of the people using the system, and they only surface when something takes them away.

Entrenched operations

Users adapt to bad systems. Over the years they learn its quirks, build their routines around them and become expert in them, and that expertise is hard to give up, even for a system that is objectively better.

Resistance is usually most fierce at the beginning. Users will eventually adapt to your new solution, and in time it will become the entrenched system that the next one has to displace. The cycle continues further down the line.

Complex third-party integrations

Customers rarely run your system on its own. In a casino, the management system may be connected to a hotel, point of sale, kiosks, a jackpot system and the regulator, and some of those connections will be older than the people who maintain them.

It is easy to overlook dated technologies during discovery: a nightly flat-file export, a serial link, a database view someone set up years ago. Rebuilding every legacy integration before go-live takes too long, and YAGNI applies again. Some of these integrations are much loved, though, and revamping them can be a project in its own right. Find out early which ones matter.

What to do

None of these barriers can be removed entirely, but they can be found early and managed.

1. Identify broad customer segments

Group your customers using whatever model works well for your business, for example by region, revenue or market type, such as VIP versus mass-market. Customers within a segment tend to share regulation, operations and expectations, so a segment is a sensible unit for planning a rollout, and for choosing early adopters who represent the rest.

2. Identify oddities and potential blockers

Perform a case-by-case review of each customer’s operations and existing systems. Identify and analyse integrations, workarounds, regulation, bespoke functionality and any other exceptions to the norm. Speak to the users as well as management: they are the only ones who know about the fax number field.

3. Prepare a readiness for adoption report

Bring the findings together in a short report for each customer or segment: what they use today, what they rely on, the blockers found, and what must be built, configured or retrained before they can move. Give each a simple rating, such as ready, ready with changes, or not yet ready.

The report serves two audiences. For the customer, it sets honest expectations, and gives management and users the same picture. For the product team, blockers that recur across a segment are candidates for the roadmap, and one-off oddities are a prompt to ask whether they are still needed.

4. Roll out in waves, starting with a pilot

Use your segments to plan the rollout in waves. Start each segment with a pilot customer who is representative of the rest, rather than the friendliest or the simplest. Their users will find the problems the review missed, and once they are up and running they become the reference for everyone who follows.

Involve users from the pilot onwards, as well as management. Find champions among them: respected, hands-on people who can help shape the configuration and training, and help bring their colleagues along. Resistance is easier to meet one customer at a time than across a whole segment at once.

5. Measure adoption, not installation

Going live is only the halfway point. Afterwards, measure whether the system is being used as intended: which features are used and how often, whether old workarounds are reappearing in new places, and whether users are bypassing the system altogether. Share the findings with management, who bought the system expecting results, and act on them.

Putting it into practice

Treat adoption as part of the product. Budget time for it and give it an owner. Some resistance is healthy, too, as it often points to something the product genuinely lacks.