A HealthTech pilot should begin with a credible route to adoption, not merely permission to run a trial. Before implementation starts, the supplier and healthcare organization need to know who could buy the product, which budget could fund it, what evidence will inform the decision and how procurement would proceed.
This does not mean every successful pilot will become a contract. Clinical priorities can change, funding may not be available, and procurement rules may require further competition or assessment. It does mean the pilot should address the questions standing between a promising technology and routine use.
In an EU-Startups opinion article about healthcare pilot culture, contributor Kieran Daly argues that unresolved budget ownership, implementation responsibility, systems integration, training and support contribute to a gap between pilots and long-term adoption. He also warns that a clinician champion may be unable to secure the support of finance, IT, operations and procurement.
Those observations do not establish that every European health system has the same problem. They are, however, useful prompts for founders preparing to sell to a large public healthcare organization. The practical response is to conduct a scale-readiness review before agreeing to a pilot.
Name the economic buyer and budget owner
The department interested in testing a product is not necessarily the part of the organization that can fund wider use. A clinical team may sponsor the pilot while a digital, transformation, workforce or operational budget would have to pay for adoption. In other cases, the benefits may appear in one department while the cost falls on another.
Before signing a pilot agreement, ask the healthcare organization to identify three roles:
- Clinical owner: accountable for the intended care or service outcome.
- Economic buyer: able to support the commercial decision and justify the expenditure.
- Budget owner: responsible for the budget line that could fund continued use.
One person may hold more than one role, but the functions should not remain unnamed. The parties should also distinguish pilot funding from adoption funding. A grant, innovation fund or departmental allowance may cover a short trial without providing a route to recurring expenditure.
The supplier does not need an unconditional purchasing commitment. It does need a candid answer to a more basic question: if the agreed results are achieved, where could the money come from? If no plausible budget exists, the project may be better described as research, discovery or evidence development rather than a procurement-oriented pilot.
Build cross-functional ownership before implementation
A clinical champion is valuable, but enthusiasm within one department does not settle questions about information governance, integration, workflow changes, financial approval or tendering. A pre-pilot group should therefore include appropriate representatives from clinical services, finance, IT, operations and procurement. Regulatory, information governance, cybersecurity or legal specialists may also be needed, depending on the product and local requirements.
Each participant should have a defined question to answer. Finance can test whether the proposed economic case matches the organization’s budgeting method. IT can assess integration, identity management, hosting and support dependencies. Operations can examine workflow and staffing effects. Procurement can explain the available commercial route and the documentation it requires.
This involvement should happen while the pilot can still be redesigned. Asking these teams to assess a completed trial may create rework or reveal that the evidence collected is insufficient for the intended adoption decision.
Turn success criteria into adoption gates
A pilot objective such as “demonstrate value” is too vague to guide a purchasing decision. The parties should agree on a focused set of measurable gates covering the dimensions that matter to the intended buyer.
Clinical criteria
Define the intended clinical or service outcome, the relevant population and the comparison being made. Where a pilot is not designed to establish clinical effectiveness, say so explicitly. Do not let an operational feasibility exercise acquire a stronger evidential claim after the event.
Operational criteria
Measure whether the product can function in the real workflow. Relevant questions may include whether intended users adopt it, where work is added or removed, how exceptions are handled and whether the service can continue without intensive supplier intervention.
Financial criteria
Agree on how costs and potential benefits will be calculated, including whose costs count and over what period. A reduction in one activity does not automatically create cash savings. The economic case should distinguish direct expenditure, released capacity, avoided future costs and benefits that cannot readily be converted into budget.
Each gate should have an evidence source, a responsible owner and an agreed decision threshold. The group should also record what will happen if the result is mixed. A pilot that meets clinical criteria but misses an operational threshold may justify redesign rather than immediate purchase or rejection.
Map integration and evidence requirements
A limited pilot can conceal the work required for broader deployment. Temporary data transfers, manual account creation or standalone workflows may be acceptable for testing, but they should not be mistaken for a scalable operating model.
The pre-pilot plan should document the proposed production environment: systems that need to exchange data, technical dependencies, access controls, monitoring, incident management, data responsibilities and internal teams needed for deployment. It should separate what will be tested during the pilot from what would remain to be completed before adoption.
The same discipline applies to regulatory and evidential requirements. Founders should ask the customer which product documentation, approvals, assurance materials and local assessments are necessary at the pilot and procurement stages. Requirements vary by technology, use case and jurisdiction, so a checklist copied from another customer is not a substitute for local review.
The NHS Innovation Service guidance, for example, presents innovation as a journey involving evidence, market access and adoption considerations rather than an isolated trial. The relevant pathway will differ outside the NHS, but the operating principle is useful: identify downstream requirements before selecting what the pilot will test.
Price training and support as part of the product
A pilot may appear successful because the startup’s team provides unusually intensive onboarding, troubleshooting and encouragement. That can be appropriate during early learning, but the adoption case should show what support would look like in routine use.
Document who will train new users, how often training will be required, which materials will be supplied and who will handle first-line and specialist support. Include escalation routes, expected service responsibilities and any customer resources needed to administer the product.
This exposes an important commercial question: can the supplier support wider deployment at the proposed price and service level? If every new site depends on senior founders delivering bespoke training, the pilot may validate demand without validating a sustainable delivery model.
Agree on the adoption decision and procurement route
The pilot agreement should name the body or role that will review the results, the expected decision date and the possible outcomes. Those outcomes might include stopping, extending the evaluation, redesigning the implementation, progressing to a procurement process or adopting through an available route.
Procurement staff should confirm what is legally and commercially possible in the relevant jurisdiction. A successful trial may inform specifications or a business case, but it should not be presented as guaranteeing a direct award. Wider adoption may require competition, use of an existing framework or another formal process.
Founders should work backwards from the proposed route. If procurement will require defined service levels, insurance evidence, security documentation, financial checks or deployment pricing, prepare them during the pilot rather than after it. NHS England’s innovation and commercial guidance can help suppliers understand the NHS context, although it does not replace instructions from the contracting organization.
Make evidence portable beyond the first department
Young suppliers face a track-record dilemma: prospective customers may prefer established vendors, yet a startup cannot build a record without early adopters. A successful pilot with one enthusiastic team helps, but its evidence may be difficult to use elsewhere if the context, intervention and results were poorly documented.
To improve portability, agree in advance what the supplier may retain and share, subject to consent, confidentiality and data obligations. Produce a clear account of the service setting, user group, baseline, implementation inputs, outcome definitions and limitations. Record both the technology’s contribution and the customer resources that made implementation possible.
Separate reusable evidence from customer-specific conclusions. Technical performance, implementation lessons and training requirements may transfer across sites more readily than a local financial result. Avoid turning a small or narrowly designed pilot into a universal claim.
Evidence is also more credible when evaluation ownership and methods are agreed before results are known. Where appropriate, customers and suppliers can define who validates the analysis and how disagreements will be recorded. The objective is not to manufacture a glowing case study; it is to create evidence another decision-maker can interpret.
A pre-pilot scale-readiness checklist
Before starting, the supplier and healthcare organization should be able to answer the following:
- Who owns the clinical problem, purchasing decision and potential adoption budget?
- Is adoption funding distinct from pilot funding, and is there a plausible source?
- Which clinical, finance, IT, operations, procurement and assurance stakeholders must participate?
- What clinical, operational and financial gates will inform the decision?
- How will each measure be collected, interpreted and validated?
- Which temporary pilot arrangements would need to change for production deployment?
- What integration, regulatory, security and evidence requirements apply?
- Who will provide training, administration and ongoing support at scale?
- Who makes the post-pilot decision, when will it be made and what outcomes are available?
- Which procurement route could be used, and what documentation will it require?
- What evidence can be carried into discussions with other departments or customers?
If several answers are missing, delaying or narrowing the pilot may be the commercially responsible choice. A trial can still be worthwhile for discovery, technical validation or research, but its purpose should be stated honestly.
The central shift is to treat a pilot as one stage in an adoption pathway rather than as the sales objective itself. For HealthTech founders, the most useful pilot is not necessarily the easiest one to secure. It is the one designed around the clinical, operational, financial and procurement decisions that follow.
