Define the decision before starting the experiment.
“Explore AI” leaves too much unresolved. A useful pilot asks whether a defined product can improve a particular workflow enough to justify adoption. It names the operational owner, the evidence that person needs and the commercial decision that follows.
For Dr.O Innovation Hub, pilot design connects the technology team’s claims with the industry partner’s operating reality. Our starting point is a brief that both can work from.
01. Write the operating brief.
Choose one process with a named owner. Record how it works today, who touches it, its normal volume and the kinds of exception that make it difficult. Identify the budget owner early enough to understand what a purchasing decision would require.
- Workflow: the start and end of the task, users and existing systems.
- Baseline: current time, cost, quality and failure rate, measured on a defined sample.
- Environment: available data, access permissions, integration and hosting requirements.
- Decision: who reviews the results and what would justify the next stage.
Agree responsibilities for data preparation, installation, user training and support. Otherwise, an apparent product result can conceal extra work carried by the customer’s team.
02. Measure the whole workflow.
The metric must reflect what the buyer needs. Include the time spent checking, correcting and escalating outputs. Use a representative sample and document the conditions under which the comparison is made.
These examples illustrate how the measurement changes by application; they are starting points for a pilot brief, not claimed results.
- Enterprise document agent
- Measure cost per accepted document and exception rate. Include human review and rework; a fast draft is not necessarily a finished task.
- Building energy optimisation
- Compare energy use alongside comfort and equipment constraints. Account for weather, occupancy and operating hours before attributing a change to the product.
- Care administration tool
- Measure completion time, missing information and staff review effort. Operational results do not by themselves establish clinical safety or effectiveness.
- Financial reconciliation
- Measure correctly matched transactions and time to resolve exceptions. Preserve an audit trail and distinguish automation from unresolved errors.
Define the acceptable error and escalation process with the people responsible for the workflow. Where health, financial or other regulated activity is involved, the responsible specialists must establish the appropriate scope and requirements.
03. Agree what follows the result.
A pilot should end with a review against the agreed baseline. Include limitations, operating costs and failures alongside successful examples. The next decision can be to extend the trial, change the product, proceed towards purchase or stop.
Before recommending expansion, work through the commercial model: installation effort, recurring cost, service responsibilities, support capacity and what changes at higher volume. Identify the remaining approvals and the owner of each next step.
What was tested · What changed against the baseline · What did not work · Total operating cost · Remaining conditions · Next decision and owner
Make the learning reusable.
The first implementation should leave the team with more than a demonstration. It can produce a repeatable evaluation, clearer integration requirements and a more accurate delivery model. Those are useful foundations for the next customer.
For founders, the brief makes the product’s value easier to examine. For industry partners, it connects a technology experiment to an operating and purchasing decision. For us, it reveals how technical progress might become a scalable business.