Business outcome
What must improve: administration, utilisation, access, asset control, customer service, revenue or another measurable outcome?
Enterprise procurement guide
How to Specify an Enterprise Smart Locker System
Turn operational needs into clear, testable requirements for smart locker hardware, software, access, integration, security, deployment and support.
- Ten specification areas
- Testable requirement format
- Supplier evaluation framework
The specification principle
Specify the service the organisation needs—not a predetermined locker product.
A strong enterprise smart locker specification begins with the transaction to be controlled: who deposits or stores an item, who retrieves it, how identity is confirmed, what information is recorded and what happens when the normal journey fails.
Only then should the buyer define cabinet construction, compartment mix, access devices, locker management software, integrations and service levels. This order gives suppliers room to propose an appropriate design while keeping the required outcome unambiguous.
Good specification test: every important requirement should be understandable, measurable and capable of being demonstrated, inspected or accepted before launch.
If the organisation has not yet confirmed the category or budget, first review smart lockers versus traditional lockers, smart locker pricing factors and the ROI and total-cost framework.
Before writing requirements
Agree five decisions internally.
Workflow scope
Which storage, issue, return, delivery or collection journeys are included—and explicitly excluded?
User groups
Employees, visitors, customers, couriers, contractors and administrators may require different credentials and permissions.
Estate scope
Which locations are in the first phase, what differs between them and what future scale should the platform accommodate?
Decision ownership
Identify the operational owner plus facilities, IT, security, procurement, finance and accessibility stakeholders.
Requirements architecture
Ten areas an enterprise smart locker specification should cover.
Outcomes and scope
Purpose, workflows, locations, volumes, constraints, success measures and exclusions.
Users and journeys
User groups, deposit and collection steps, credentials, notifications, exceptions and accessibility.
Capacity and layout
Demand basis, peak concurrency, door quantities, compartment sizes, banks, growth and space constraints.
Physical system
Materials, dimensions, locks, finishes, environment, power, ventilation, charging and specialist accessories.
Access and allocation
Authentication methods, permissions, fixed or flexible use, reservation, time limits, release and overrides.
Software and administration
Roles, configuration, estate view, live status, reporting, alerts, audit records and data export.
Integration and data
Connected systems, use cases, data ownership, interfaces, events, error handling, testing and support boundaries.
Security and compliance
Physical access, identity, permissions, logging, privacy, hosting, retention, assurance and incident responsibilities.
Delivery and acceptance
Surveys, dependencies, logistics, installation, configuration, testing, training, pilot, handover and acceptance.
Service and commercial terms
Availability, support hours, response targets, maintenance, parts, updates, pricing basis and contract exit.
Operational workflow
Write the user journey before listing features.
Describe the normal journey and the important exceptions. A feature matters only when it supports one of these steps.
1Request or depositWhat starts the transaction?
2AllocateHow is a compartment selected?
3NotifyWho receives which message?
4AuthenticateHow is identity verified?
5Collect or returnWhat completes the journey?
6Record and releaseWhat is retained and reset?
Specify exception journeys
- credential not received or forgotten;
- incorrect or occupied compartment;
- door does not open or close;
- item is not collected or returned;
- network, power or connected system is unavailable;
- administrator or emergency access is required.
Specify acceptance evidence
- demonstrated end-to-end transaction;
- named test data and test users;
- expected notification and event records;
- verified permission and override behaviour;
- documented recovery and support procedure;
- signed operational acceptance criteria.
Physical specification
Translate the environment and item profile into a locker configuration.
Define the smallest, largest and most common items, then size the compartment mix around actual demand. Include door clear opening, internal usable dimensions and any charging, ventilation or weight requirement that affects safe operation.
The environment determines whether steel, compact laminate, wood-based or outdoor construction is appropriate. Record moisture, cleaning, temperature, impact, fire strategy, accessibility, floor loading, power, network and surrounding-furniture constraints for each site.
Review Vflex cabinet and configuration options
Technical and operational requirements
Specify what the platform must do and how the buyer will verify it.
| Area | Requirement questions | Evidence to request |
|---|---|---|
| Access | Which credentials, identity sources, time rules, offline behaviours and override paths are required? | Live demonstration, supported-device list and documented exception behaviour. |
| Allocation | Fixed, flexible, temporary, reserved, team, asset-led or mixed? When is a locker released? | Configured workflow demonstration using representative users and rules. |
| Administration | Which roles can view, assign, open, override, configure and report across which sites? | Role-and-permission matrix plus administrator interface demonstration. |
| Reporting | Which live states, historic events, utilisation measures, exports and retention periods are needed? | Sample reports, field definitions, filters, export formats and retention statement. |
| Integration | Which system initiates each event, what data is exchanged and who owns failures? | Architecture, interface documentation, test approach and responsibility matrix. |
| Security | How are access, administration, data, updates, vulnerabilities and incidents controlled? | Security responses, certifications or assurance evidence, policies and data-flow detail. |
| Availability | What service availability, monitoring, backup, recovery and local continuity are required? | Service description, availability commitment, recovery approach and escalation route. |
| Support | Who supports users, hardware, software and integrations, during which hours and to what targets? | Service-level schedule, support boundaries, escalation model and parts coverage. |
Writing requirements
Use a structure suppliers can answer consistently.
Assign every requirement a unique identifier, priority, response format and acceptance method. Separate mandatory requirements from scored preferences so that suppliers know which conditions determine compliance.
Avoid words such as “easy”, “robust”, “real time” or “seamless” unless the specification defines how they will be assessed.
Example requirement
- ID
- ACC-04
- Priority
- Mandatory
- Requirement
- The system shall allow an authorised administrator to issue a time-limited temporary access credential without creating a permanent user account.
- Supplier response
- Comply / partially comply / does not comply, with explanation.
- Acceptance
- Demonstrate credential creation, successful access, expiry and audit record using agreed test data.
Supplier evaluation
Score the complete operating solution—not the longest feature list.
The example weighting below is illustrative. Procurement should agree weights and pass/fail requirements before supplier responses are opened.
Use pass/fail gates
Apply mandatory legal, security, site, interoperability or service requirements before weighted scoring where appropriate.
Score evidence quality
Differentiate a stated capability from a demonstrated workflow, reference deployment or contractually committed service.
Test with real scenarios
Give shortlisted suppliers the same representative user journeys, exception cases and integration assumptions.
Procurement risks
Common smart locker specification mistakes.
Starting with a door count
Quantity without demand, item dimensions and allocation rules can over- or under-size the system.
Mandating technology without purpose
A named reader, app or terminal may constrain the design without explaining the user or security requirement.
Leaving integrations vague
“Must integrate” does not define the systems, events, data, ownership, testing or operational support needed.
Ignoring exception handling
Normal journeys may demo well while lost credentials, faults, uncollected items and outages remain unresolved.
Comparing purchase price only
Software, integration, internal administration, maintenance and change belong in the total-cost comparison.
Deferring acceptance criteria
If success is not defined in the procurement documents, disagreement is more likely during commissioning.
Supplier brief checklist
Information to include with an enterprise smart locker enquiry.
- Business context
Problem, objectives, sponsor, stakeholders and target timescale.
- User journeys
Normal and exception flows for every in-scope user group.
- Demand data
Users, items, transactions, peaks, concurrency, growth and seasonality.
- Site information
Locations, drawings, photographs, dimensions, access, power and environment.
- Technical landscape
Identity, access, workplace, service, parcel, payment and other relevant systems.
- Governance
Security, privacy, accessibility, legal, data and internal approval requirements.
- Delivery expectations
Pilot, rollout, testing, training, acceptance, support and change control.
- Response format
Compliance matrix, assumptions, exclusions, evidence, timescale and complete commercial schedule.
Bring the requirement before the product list
Scope an enterprise smart locker system with Vpod.
Share your workflows, users, demand, sites, access methods and connected systems. Vpod can help translate them into an appropriate locker, software, integration and deployment scope.