VPOD FIELD GUIDE · ENTERPRISE DEPLOYMENT
TEST BEFORE YOU SCALE
How to Run a Smart Locker Pilot Project
A smart locker pilot should answer a specific decision, not just install a few lockers. Define the uncertainty, test the real workflow with representative users at a suitable site, measure it against a baseline, then use agreed thresholds to decide whether to proceed, adapt, extend or stop before a wider rollout.
THE SHORT ANSWER
Make the pilot prove or disprove an assumption.
A smart locker pilot project is a controlled, time-bound test of a defined operating model. It should establish what the team needs to learn, what evidence will count, who will review it and which decision follows. A small installation without a baseline, representative users or agreed success measures is a demonstration—not a useful proof of concept.
Start with a question that could change the investment or design: will this user group adopt the workflow, is the capacity mix right, can the required integration work, or can the service support a busy operating period? Test those uncertainties in a live but bounded environment before planning wider deployment.
01 / DECIDE WHETHER A PILOT ADDS VALUE
When is a smart locker pilot appropriate?
A pilot is useful when an unknown could materially change the design, operating model, cost or rollout decision. It is not required for every purchase. If the workflow, site conditions and specification are already proven in a comparable deployment, a direct phased rollout may be more useful.
Will users adopt it?
Test whether the intended users understand the journey, can access a locker and prefer it to the current process.
Is capacity right?
Check peak demand, compartment sizes, turnover and unmet requests across real operating days.
Will systems connect?
Exercise the identity, booking, payment, parcel or workplace integration that the future service will actually use.
Can exceptions be handled?
Test support ownership, access failures, abandoned contents, network loss and administrator actions.
02 / WRITE THE DECISION FIRST
What must the pilot help you decide?
Set the decision owner and decision date before the trial starts. This prevents the team from collecting attractive dashboard numbers that do not answer the business question.
Proceed as designed
The agreed evidence meets the thresholds and key dependencies are resolved.
Change the design
Keep the business case but adjust capacity, compartment mix, access, placement or user communication.
Collect more evidence
A seasonal peak, integration dependency or user-learning period has not yet been observed.
Redesign or close
The model misses a critical requirement, the risks are unacceptable or the expected benefit is not supported.
Agree thresholds and minimum evidence for each outcome. Avoid moving the goalposts after results are visible.
03 / CHOOSE A SITE THAT TELLS THE TRUTH
Select a representative pilot environment
The easiest site to install may not be the best place to learn. Pick a location that resembles the future estate in the ways that matter, while keeping the trial manageable and safe.
Compare candidate locations against user mix, typical and peak demand, operating hours, local support, connectivity, integration readiness and planned rollout similarity. Include the real workflow and intended user groups. For a workplace trial, that may mean hybrid attendance patterns and actual identity credentials. For paid venue storage, include event arrivals, payment steps and post-event collection. For parcel or asset workflows, test the handover and custody events.
A deliberately easy pilot can prove that the equipment opens doors in a quiet, well-supported setting. It cannot show whether the model works at a busier site, with multiple shifts, a complex identity system or an uneven demand profile. Choose a site that exposes realistic constraints without introducing avoidable project risk.
Record what differs between the pilot location and the sites you may roll out to. Those differences become assumptions to validate later or explicit design variations—not details to quietly ignore.
Use Vpod’s capacity-planning guide to size the trial ↗04 / KNOW WHAT “BETTER” MEANS
Establish the baseline before installation
Measure the existing process over a comparable period. Include ordinary variation, not one exceptional day. Document how each figure was collected, who owns it and where the current process creates friction.
Minutes spent assigning, opening, monitoring and reconciling storage.
Storage requests, peak occupancy, turnaways and compartment-size shortages.
Wait time, repeat questions, failed handovers and user feedback.
Lost keys or credentials, missing items, manual overrides and incident volume.
Floor space used, back-of-house storage and circulation constraints.
Labour, consumables, lock replacement, cash handling or third-party charges.
05 / BUILD A BALANCED SCORECARD
Define success measures that cover the whole service
Pick a small set of measures tied to the decision—not every number the platform can produce. For each metric, specify its owner, data source, calculation, target and review frequency. Use the downloadable scorecard as a starting point.
| Area | Example pilot measure | Evidence to capture |
|---|---|---|
| Adoption | Eligible users completing successful transactions | Unique eligible users; completed first-use and repeat-use transactions; communication exposure. |
| Reliability | Successful openings and completed workflows | Attempts, successful openings, failed transactions, door faults and repeat incidents. |
| Capacity | Occupancy, denied demand and size shortages | Peak and average occupancy by compartment size; waitlists, turnaways and unused capacity. |
| Efficiency | Staff time and manual interventions | Time spent on routine transactions, user assistance, exception handling and reconciliation. |
| Experience | User satisfaction and completion time | Survey responses, task completion time, drop-offs, complaints and qualitative observations. |
| Support | Incidents, recurring faults and resolution time | Incident severity, response, workaround, restoration, ownership and repeat rate. |
| Integration | Successful events, errors and reconciliation | End-to-end events, rejected messages, duplicates, retries and unmatched records. |
| Commercial | Revenue, costs avoided or payback evidence | Transactions, price, revenue share, operating cost and assumptions used in any projection. |
06 / TEST MORE THAN THE HAPPY PATH
Include normal use and exception journeys
A successful demonstration covers the cleanest transaction. A useful pilot exercises the conditions that can interrupt real work—and confirms who acts next.
Request → Allocate → Notify → Authenticate → Open → Complete
Observe a user completing the real deposit, issue, collection or return process. Record task completion and any assistance needed.
Test outcomes depend on the configured platform, access method, integrations and local procedures. Do not assume every locker system behaves the same when offline or during a fault.
07 / RUN LONG ENOUGH TO SEE THE PATTERN
Choose a representative pilot period
There is no universal ideal duration. Set the period around the operating cycle you need to test, the time needed for users to learn the process and the time required to resolve early configuration issues.
Allow enough time to distinguish launch effects from normal use. A short test may be sufficient to validate an interface or identity connection, but not seasonal demand or event peaks. Conversely, extending a pilot without a new question can consume time without improving confidence. Set a review date, extension criteria and end condition before go-live.
08 / TURN OBSERVATIONS INTO AN ACTION
Review the evidence and decide
Use the threshold agreed at the start. Record the evidence, gaps and rationale alongside the outcome so the wider organisation can understand why the programme will—or will not—move forward.
Proceed
Core measures meet target; dependencies and owners are understood.
Adjust
Evidence supports the case, with specific changes to workflow, sizing or support.
Learn more
A named uncertainty needs a defined extra period or additional test.
Redesign
Critical needs are unmet or the case is not supported by evidence.
A pilot is valuable even when the decision is to stop. It can prevent a larger investment in a model that does not fit the users, workflow or site.
09 / MAKE THE LEARNING REUSABLE
Turn the pilot into a rollout playbook
If the decision is to expand, capture what the next site team needs to repeat the outcome—not only the headline result.
Approved configuration
Locker models, compartment mix, access methods, screens and workflow rules.
Site readiness
Power, connectivity, access routes, space, signage and named local owners.
Integration pattern
Systems, data fields, events, credentials, errors and reconciliation steps.
Testing & acceptance
Repeatable scripts, exception tests, thresholds, evidence and sign-off roles.
People & support
Training, communications, help routes, escalation and incident ownership.
Measurement pack
Baseline definitions, dashboards, reporting cadence and rollout review points.
Separate standard requirements from approved local variations. Feed the site checklist, installation plan and training materials with what the pilot revealed. For a broader programme plan, use Vpod’s multi-site rollout guide, installation guide and enterprise specification guide.
FIELD EVIDENCE / PILOTS AND OUTCOME WINDOWS
Use case studies to shape your test—not replace it
Vpod’s published deployments show different ways to define and observe locker outcomes. Only Flip Out Lakeside is identified here as a proof of concept; the other examples show results from operating deployments, not pilot programmes.
PRIMARY PILOT EVIDENCEFLIP OUT LAKESIDE · LEISURE & PAID STORAGE
105 lockers. Six-month proof of concept.
Vpod describes a 105-locker deployment at Flip Out Lakeside as a six-month GainShare proof of concept. It gave the venue a live setting to test visitor storage demand and a managed operating model. The published case study also describes hardware, installation, software, maintenance and support within the service.
Use it as a prompt to define what your own pilot must resolve: demand at different times, user conversion, compartment mix, service workload, revenue assumptions and ownership of power, connectivity and support. The case study’s commercial terms and results are specific to that deployment.
Read the Flip Out Lakeside case study
Read the Skyscanner case study ↗Skyscanner
Vpod reports results across three UK offices, including reduced administration and improved utilisation. Use outcomes like these to define workforce adoption, utilisation and central-management measures.
Read the footwear retailer case study ↗National footwear retailer
Vpod reports six months of operational data at one 51-door location, including 5,500 annual orders and reduced staff time spent on collections. The wider programme had nine UK sites; do not present the single-location evidence as a trial result.
Read the YHA case study ↗YHA London
Vpod’s first-eight-weeks evidence reports transaction, revenue and collection-time measures across two hostels. It shows why a pilot or early review should observe performance over a defined period.
Another useful operating benchmark: Co-op Live reports results from its first five months, illustrating how venue adoption, throughput, revenue and operational measures can be assessed at scale. This is an operating deployment, not a pilot claim. See the Vpod case-study hub for further examples.
WATCH / VPOD SMART SOLUTIONS
See a managed locker model in operation
Vpod’s GainShare video is relevant when the pilot is testing paid storage, venue demand or a funded commercial model. Ask which parts of the video match your proposed configuration and what your own trial should measure.
Watch Vpod GainShare Watch Flip Out Lakeside case study video ↗For workplace pilots: Vflex Day Lockers User Journey ↗Browse the Vpod Smart Solutions channel ↗
VPOD GAINSHARE / SHARED-REVENUE SMART LOCKERSREADY TO TEST THE RIGHT QUESTION?
Plan a pilot that gives your team a decision.
Bring your workflow, users, candidate site, dependencies and known risks. Vpod can help scope a representative trial and define the evidence needed before wider deployment.