A healthcare technology sale can look finished long before the work is actually done. The contract is signed. The implementation call is scheduled. Training is completed. The customer may even say the rollout went well. Then, a few months later, usage is uneven, only a small group is comfortable with the system, support questions keep repeating, and the expected operational improvement never fully appears.
That is not just an implementation problem. It is a post-sale adoption problem, and it is expensive because it can stay hidden behind activity that looks like progress.
The Sale Is Not the Same as Adoption
In healthcare, buying a technology and changing behavior are two different events. A hospital or practice can approve a product because the business case is sound, the clinical need is real, and the stakeholders agree. None of that guarantees that the people who have to use the technology every day will build it into their workflow (Greenhalgh et al., 2004).
The gap usually shows up after the visible milestones are complete. The vendor held the kickoff. The training attendance sheet is full. The customer received the materials. The project plan has green boxes beside the major tasks. But the more useful questions are harder: Who is actually using the technology? How often? Where are people still working around it? What questions keep coming back? Which teams have adopted it and which ones have not?
A project can be busy and still be stalled.
Where Adoption Breaks
Poor adoption rarely comes from one dramatic mistake. More often, several small gaps accumulate. Research on implementation keeps coming back to the same point: the technology by itself is not enough. The people, setting, process, and support around it matter (Damschroder et al., 2009).
Training may be too early, before users have enough context to remember what matters. A small number of champions may understand the system while the rest of the staff depend on them. Managers may assume that initial use means the new behavior has taken hold. The person named to own the rollout may not control schedules, staffing, policy, or the other departments needed to solve problems. And when questions surface after launch, there may be no clear cadence for answering them and checking whether the answer actually changed behavior. A team can support a change and still know it does not have the time, authority, or support to carry it out (Weiner, 2009).
Healthcare makes this harder because workflows are interdependent. A technology can be easy for one user and still fail operationally if another role cannot complete its part. A physician may support the change while nurses, technicians, schedulers, IT staff, or administrators encounter friction that was not visible during the purchase decision.
Measure What Changed, Not Just What Happened
Post-sale teams often track what they can count easily: meetings held, users trained, tickets closed, follow-up emails sent. Those measures matter, but they are inputs. They do not prove adoption.
A stronger scorecard asks what changed on the customer side. Useful measures will vary by technology, but they can include time to first meaningful use, repeat use after the initial trial, the number of active users versus trained users, usage across departments or locations, recurring support questions, workarounds that remain in place, time needed to complete the new workflow, and whether the intended clinical or operational process is actually occurring more consistently.
The point is not to create a giant dashboard. It is to separate motion from movement. The better test is whether the new practice becomes normal work, not something people do only when the rollout team is standing there (May et al., 2009).
The Handoff Needs an Owner Who Can Act
Another common problem appears when the commercial team hands the account to implementation or customer success and assumes the ownership question is solved. Naming an owner is not enough if that person cannot move the people and decisions that determine adoption.
The owner needs a workable path to action. That means enough authority to resolve routine issues, access to the right stakeholders, a way to escalate decisions, practical resources, and local people inside the customer organization who can reinforce the change when the vendor is not present.
If those pieces are missing, the owner can be held responsible for an outcome they were never equipped to produce.
Build Adoption Into the Post-Sale Plan
The most useful time to deal with adoption is before it becomes a rescue project. A simple post-sale plan should answer five questions:
- What specific behavior has to change for the customer to receive the value they expected?
2. Who must perform that behavior, and what can block them?
3. Who owns the next action on both the vendor and customer sides?
4. What evidence will show that use is becoming routine rather than remaining a trial?
5. When will the team reassess the plan if the expected behavior is not appearing?
Those questions force the team to think beyond launch. They also make problems easier to diagnose. If use is low, the cause may be training. It may be workflow design. It may be staffing. It may be a missing decision. It may be skepticism from users. It may be that the original value proposition was right for the buyer but never translated into the daily reality of the people expected to use the technology.
The Cost of Ignoring Adoption
When adoption is weak, the obvious cost is underused technology. The less obvious costs are often larger. Staff lose confidence in the rollout. Leaders become skeptical of the next initiative. Customer teams create workarounds. Support demand stays high. The vendor sees expansion or renewal opportunities weaken. And both sides can spend months debating whether the problem was the product, the implementation, the training, or the customer.
Many of those arguments are avoidable if adoption is treated as an operating outcome from the beginning.
A signed agreement matters. A completed implementation matters. Training matters. But none of them is the finish line. In healthcare technology, the real test comes after the launch: did the people who were supposed to use the technology actually change what they do, and can the organization sustain that change without constant rescue?
That is where post-sale value is either created or lost.
References
- Damschroder, L. J., Aron, D. C., Keith, R. E., Kirsh, S. R., Alexander, J. A., & Lowery, J. C. (2009). Fostering implementation of health services research findings into practice: A consolidated framework for advancing implementation science. Implementation Science, 4, 50. https://doi.org/10.1186/1748-5908-4-50
- Greenhalgh, T., Robert, G., Macfarlane, F., Bate, P., & Kyriakidou, O. (2004). Diffusion of innovations in service organizations: Systematic review and recommendations. The Milbank Quarterly, 82(4), 581–629. https://doi.org/10.1111/j.0887-378X.2004.00325.x
- May, C. R., Mair, F., Finch, T., MacFarlane, A., Dowrick, C., Treweek, S., Rapley, T., Ballini, L., Ong, B. N., Rogers, A., Murray, E., Elwyn, G., Légaré, F., Gunn, J., & Montori, V. M. (2009). Development of a theory of implementation and integration: Normalization Process Theory. Implementation Science, 4, 29. https://doi.org/10.1186/1748-5908-4-29
- Weiner, B. J. (2009). A theory of organizational readiness for change. Implementation Science, 4, 67. https://doi.org/10.1186/1748-5908-4-67
