lab2sky / from pilot to adoption design a test that earns a clear next decision creation in motion / september 2026 https://lab2sky.com/corporate-toolkit/ for: corporate and startup teams preparing a jointly owned pilot allow: 90 minutes to plan; review before starting outcome: a pilot charter, decision rules and a practical handover or exit plan bring: an agreed challenge, baseline, named owners and known operating constraints. all examples, thresholds and figures are fictional. this worksheet is not an agreement, safety approval or evidence of a completed pilot. design the decision first a useful pilot reduces a specific uncertainty. a working demonstration alone does not establish adoption or commercial value. state the hypothesis and comparison describe what should improve, for whom and through which mechanism. decide how you will compare the result with the current approach. account for differences in customers, workload, season or operating conditions. where a credible comparison is not possible, be clear that the exercise explores feasibility rather than proving a causal benefit. worked example / illustrative a fictional distributor tests exception alerts on comparable delivery routes. it records a pre-test baseline and monitors a comparison group where feasible. the team checks load type and weather before attributing a change in spoilage to the alerts. check: what alternative explanation could produce the same apparent improvement? agree thresholds before seeing results choose measures that answer the business question and can be collected reliably. define success, failure, safety stops and an inconclusive outcome in advance. agree the observation period and minimum usable evidence with the relevant specialists. thresholds depend on the context; examples in this workbook are not lab2sky admission or investment criteria. worked example / illustrative the pilot team proposes a 20% reduction in measured spoilage on comparable routes, with complete records and no deterioration in agreed safety measures. its analysts must first judge whether the planned observations can support a useful conclusion. check: would missing data or too few relevant events make the result inconclusive? keep scope small enough to finish define the sites, users, workflows and integrations included, plus explicit exclusions. set a time and cost limit and a process for approving changes. separate the pilot from an eventual rollout. adding an attractive feature halfway through can make it difficult to know which intervention produced the result or whether the original question was answered. worked example / illustrative the team tests alerts for one product group over six weeks. automated purchasing and fleet-wide deployment are excluded. a request for a new dashboard is recorded for later instead of silently extending the pilot's budget and purpose. check: does every planned activity help answer the stated pilot question? make the pilot runnable confirm the people, permissions and resources before starting the measurement clock. assign operational responsibility identify a sponsor, delivery owner, measurement owner and person authorised to stop the test. define how staff report problems and obtain support. schedule review points and an escalation path. a partner can provide software while the corporate retains control of operations; the boundary needs to be understood by both teams. worked example / illustrative the distributor's operations lead owns route changes. the startup supports alert reliability. the measurement owner reconciles records weekly, and a named manager can pause the test if staff follow an unsafe response to an alert. check: can each user explain who helps them and who can stop the pilot? agree data, access and recovery document the minimum data, authorised uses, access roles and retention or deletion arrangements with the relevant owners. clarify rights in existing and newly created work. define how operations continue if the pilot service fails or stops. sensitive or regulated activity needs the appropriate specialist approval before it is included in a live test. worked example / illustrative the test uses route identifiers rather than unnecessary customer details. access is limited to agreed reviewers. the existing dispatch process remains available if alerts fail, and the parties agree how pilot records and accounts will be handled at the end. check: are access, ownership and recovery arrangements confirmed rather than merely described in a proposal? budget the whole experiment include external fees, equipment, internal staff time, integration, training, measurement and support. distinguish one-off pilot costs from recurring operating costs. confirm who pays, when payment is due and which changes need approval. a free pilot still consumes resources and may be difficult for a startup to support indefinitely. worked example / illustrative illustrative pilot budget: r60,000 partner fee, r20,000 integration, r10,000 training and r15,000 measurement and support: r105,000 in total. internal staff time is estimated separately and added before comparing alternatives. check: does the budget identify excluded costs and who will absorb them? read results without spin retain the original decision rules and explain the quality of the evidence alongside the headline result. compare like with like check definitions, periods, workload and completeness before calculating improvement. document any changes to the test and inspect whether the comparison remained credible. distinguish absolute change from percentage change. do not convert one pilot's result into a portfolio, industry or international claim without the additional evidence that would require. worked example / illustrative illustrative spoilage falls from 5% to 4% of comparable delivered units: a one-percentage-point fall, or 20% relative reduction. if the product mix changed substantially, that arithmetic alone would not establish the alerts caused the improvement. check: can the result be reproduced from the source data, including unsuccessful or missing cases? distinguish value from projected savings identify which benefits were measured, which could translate into cash and which are estimates. time saved may free capacity without reducing payroll. compare benefits with recurring delivery costs and required support. show assumptions before estimating a payback period, and do not extrapolate a short period without explaining why it is representative. worked example / illustrative a model assumes r30,000 monthly avoidable loss reduction and r12,000 recurring cost, leaving r18,000 before other costs. recovering r90,000 of rollout setup would take five months if those assumptions hold. neither the savings nor the payback is guaranteed. check: which benefit has been observed, who captures it and what could prevent it becoming cash? decide: adopt, adapt, stop or learn more compare results with the original rules and discuss operational feedback, unintended effects and evidence gaps. an inconclusive result is legitimate when measurement or exposure was insufficient. record disagreements and the accountable decision maker. continuing a pilot indefinitely can conceal an unresolved procurement or business-model question. worked example / illustrative alert reliability is good, but there are too few relevant incidents to assess spoilage. the team records feasibility as supported and impact as unresolved. it considers a justified extension with a new limit rather than announcing proven savings. check: does the decision say what was learned and what remains unknown? prepare the path after the test a successful pilot needs a buyer, operating plan and agreed next commitment before it becomes sustained adoption. connect the result to procurement identify the budget owner, supplier onboarding steps and approvals for ongoing use. clarify scope, price, service expectations, support and responsibility for changes. keep pilot success separate from a promise to buy. a startup should know which decision follows and when, while the corporate should understand the capacity required to deliver reliably. worked example / illustrative the sponsor supports rollout, but the operating department must approve the recurring budget and procurement must complete its review. those steps are listed before the pilot begins, then updated using the results instead of surprising the startup afterwards. check: who can approve continuing use, and what evidence and terms do they require? test repeatability before broad expansion choose a next site or customer deliberately. identify differences in users, data, equipment, support and economics. record which parts are reusable and what needs adaptation. a corporate channel can support market access, but sales outside the initial partner and international growth each require their own evidence and commercial arrangements. worked example / illustrative the next depot has older devices and a different dispatch process. the team tests those differences before committing to every site. a potential overseas partner is treated as a new-market hypothesis rather than counted as contracted demand. check: does the next stage test a meaningful difference instead of merely repeating the easiest setting? close the loop, including when you stop record the final decision, owners and dates. if proceeding, agree a handover, monitoring plan and review triggers. if stopping, settle agreed obligations, remove access appropriately, handle data as agreed and communicate how normal operations resume. preserve learning without retaining unnecessary sensitive information. a respectful close is a useful outcome even when a venture does not follow. worked example / illustrative the parties stop after finding that integration costs outweigh the likely benefit. they document the reason, complete the agreed payment and access closure, and retain an authorised summary of what they learned for future problem selection. check: is there a practical, owned plan for both adoption and exit? your pilot charter agree this with both delivery teams before starting; obtain the approvals and terms the work requires. question, baseline and comparison what changes, for whom, compared with what? record the source, period and possible confounders. your notes: ________________________________________________________________ ________________________________________________________________ scope, measures and decision rules sites, users, duration, exclusions, success, stop and inconclusive conditions. your notes: ________________________________________________________________ ________________________________________________________________ owners, permissions and recovery sponsor, delivery, measurement and stop authority; data, access, rights and fallback plan. your notes: ________________________________________________________________ ________________________________________________________________ budget, capacity and next buyer full costs, staff time, payment terms, change control and the route to ongoing procurement. your notes: ________________________________________________________________ ________________________________________________________________ your result and next commitment retain the original plan and explain any changes. label observations, estimates and unresolved questions. result and evidence quality result versus baseline, source, completeness, comparison quality and limitations. your notes: ________________________________________________________________ ________________________________________________________________ impact and delivery economics who benefits, unintended effects, observed versus estimated value, and recurring costs. your notes: ________________________________________________________________ ________________________________________________________________ decision, conditions and accountability adopt, adapt, stop or learn more; record reasoning, open conditions, owner and date. your notes: ________________________________________________________________ ________________________________________________________________ handover, next-site test or exit procurement, support and monitoring if proceeding; payment, access and data closure if stopping. your notes: ________________________________________________________________ ________________________________________________________________ further reading lab2sky: customer access and pilot learning https://lab2sky.com/insights/customer-access/ lab2sky: building an international growth case https://lab2sky.com/insights/international-readiness/ preparation tool; not an investment decision. keep sensitive information private.