Technology should follow the locker workflow.
Smart lockers bring physical storage together with software, identity, credentials, network services and operational processes. The right design connects those layers around a useful user journey and clear ownership.
This library explains the decisions behind each technology area in plain language. Use it with IT, security, facilities, procurement and service teams. For every proposed connection, agree the data exchanged, the system of record, the failure path and the person responsible for support. Confirm product and connector availability for the exact project configuration before making it a requirement.
One service. Six connected layers.
Use this map to locate a requirement before selecting a connector or credential.
Before you design the technology
Write down the operational answers first. They determine which systems need to connect.
Choose the locker software around the service it must run.
Locker software is the control layer between people, compartments and the systems that initiate or record a handover. It can manage locker inventory, allocation rules, user entitlements, credentials, schedules, access events, administrator roles and operational reports. The product name matters less than the service boundary: which actions happen in the locker platform, which happen in another system, and who owns each decision when the two meet?
Begin with the transactions. A workplace employee may reserve a locker for a day, while an IT team member collects a laptop against an approved request. A parcel recipient may receive a temporary collection credential. A venue visitor may pay for time-limited storage. These journeys have different rules for allocation, duration, identity, notification, exceptions and audit. The software must represent those rules without forcing every workflow into the same pattern.
Ask suppliers to demonstrate administration as well as the user experience. Can an authorised operator find an item, reassign a compartment, cancel an entitlement, investigate a failed opening and see the resulting event? Can permissions be separated by site, role or function? How are software configuration, updates, user support and operational changes governed? For a multi-site estate, test whether central policy and local operating needs can coexist.
Map the software boundary before procurement. Identify which platform is the source of truth for people, bookings, assets, orders, payment status and access entitlements. Decide whether the locker service creates, consumes or merely displays each record. This prevents duplicate administration and helps scope interfaces. Confirm capabilities for the exact configuration in writing; a feature shown in a general product demo may not be available in the proposed deployment.
Questions to resolve
- Roles and permissions; allocation rules; audit events; support workflow
Treat the interface as an operating contract, not a feature tick.
An API is a defined way for systems to exchange data or request actions. A smart locker interface might involve users, compartments, allocations, credentials, transactions, status and operational events, depending on the platform and agreed integration. “Has an API” is not enough to establish fit. Ask which operations are supported, which data fields are available, what permissions apply, how requests are authenticated and what evidence shows the interface works for your use case.
Document direction and ownership for every exchange. A workplace platform might request an allocation; an identity service might supply a person or group; the locker platform might return an allocation result or a collection event. Decide which system owns retries, duplicate prevention, expiry and correction. Define what happens if a request arrives twice, a compartment is unavailable, a user has changed roles or a connection times out after the physical door has opened.
If the design uses event notifications or webhooks, confirm event names, delivery guarantees, signing or verification, retry windows, ordering, replay, filtering and retention. Do not infer these behaviours from the word “real time”. Agree how a receiving system acknowledges events and reconciles gaps. Use test credentials and representative non-production data; avoid copying production personal data into a development environment without approval.
Make API documentation part of the deliverable. It should describe authentication, endpoints or operations, schemas, versioning, errors, rate limits, timeouts, event subscriptions, change notices and support contacts. A contract test should validate both successful and rejected requests. End-to-end tests should include the physical locker action, because a successful API response does not by itself prove that a door opened or an item was collected.
Questions to resolve
- Interface catalogue and data map; error and retry rules; integration owner
Explore apis and events pathways in Vpod’s Integration Hub ↗
Connect sign-in, identity and locker entitlement deliberately.
Single sign-on (SSO) can let a user reach a locker service through an organisation’s existing identity environment. It can reduce extra credentials and align sign-in with established account policies. SSO answers a sign-in question; it does not automatically decide which locker a person may use, for how long, or what they may store. Authentication, identity attributes and authorisation should be designed as related but separate controls.
Agree the identity source and lifecycle. Determine how employees, contractors, visitors and service accounts are represented; which unique identifier links records; and how changes such as starters, movers and leavers reach the locker service. Define how groups or attributes map to locations, locker types and administrative roles. Test name changes, duplicate identities, disabled accounts, delayed updates and the removal of access when someone leaves a team or organisation.
The technical mechanism may use a supported federation or directory pattern, but do not assume compatibility from an SSO logo. Confirm the exact protocol, claims, attribute mapping, tenant configuration, certificate or secret ownership, and responsibilities for renewal. If an external visitor does not have a corporate account, define a different access route with its own expiry and recovery rules rather than weakening the employee identity policy.
Include identity operations in acceptance testing. Verify both a normal sign-in and blocked access, then check whether administrators can diagnose the reason without exposing unnecessary personal information. Agree how emergency access works, who can approve it, how it is recorded and how it is removed. Revisit role mappings whenever the organisation changes its identity groups or access governance.
Questions to resolve
- Identity source and unique key; joiner/mover/leaver timing; admin roles
Explore sso and identity pathways in Vpod’s Integration Hub ↗
Explore Microsoft Entra ID integration ↗ Explore Okta integration ↗
Check what the credential actually proves and how it is governed.
Radio-frequency identification (RFID) is a family of technologies for exchanging information between a credential and a reader over radio. In locker deployments, users may present a badge, card or tag. The word RFID does not specify the exact frequency, card technology, data format, security properties or reader compatibility. Ask which credential types the proposed reader supports and how that support will be validated against the badges already in use.
Where an organisation wants to reuse building badges, compare the locker access design with the existing access-control environment. Confirm what identifier is read, whether it is stored locally or checked against a service, how credentials are provisioned and revoked, and whether the badge identifier is treated as personal data. Do not assume that two cards described as RFID are interchangeable or provide the same assurance.
Map the full lifecycle. Who issues a card? What happens when it is lost, replaced or reassigned? How quickly does revocation reach locker access? How are temporary badges handled? What is the fallback for a visitor or a user whose badge cannot be read? The answer should preserve the access policy while giving support staff a safe recovery path.
Test the physical experience as well as the technical read. Users need clear feedback about where to present a badge, whether the reader accepted it and what to do next. Check reader placement, approach angle, accessibility, interference risks and behaviour during a network interruption. Include representative cards and readers in a site trial, then document the supported combinations in the installation handover.
Questions to resolve
- Supported card technologies; credential revocation; physical reader placement
Separate the radio interface from the credential and wallet design.
Near-field communication (NFC) is a short-range radio technology used by some contactless cards, phones and digital credentials. Its close presentation can make access feel straightforward, but “NFC access” is not a complete specification. The credential, reader, device, application, operating system, secure element or token service, and backend validation all affect the journey. Establish exactly which mode and credential the supplier proposes.
NFC is often confused with RFID because both use radio. The terms overlap in some practical conversations, but the words alone do not tell a buyer whether a particular card or reader combination is supported. A contactless payment credential, a building access card, a mobile wallet pass and a locker application may each use different identifiers and control paths. Treat each required use case as a separate compatibility question.
Ask how the experience behaves when a phone is locked, a pass is expired, a credential is revoked, a device has no network connection or the user presents the wrong credential. Confirm whether access is validated by the reader, a local controller or a connected service. Document any device or operating-system prerequisites and the recovery route for users who cannot use NFC.
Plan for co-existence. Some sites may retain physical badges while introducing mobile or wallet credentials. If so, define how each option maps to the same authorisation policy and event log. Use a test matrix that records credential type, device or card model, reader, firmware and result. The goal is a supportable configuration, not a generic claim that lockers accept contactless access.
Questions to resolve
- Reader/credential compatibility; device prerequisites; offline behaviour
Explore nfc and contactless pathways in Vpod’s Integration Hub ↗
Design the whole scan journey, including expiry and recovery.
A QR code can carry or reference a locker credential, booking, transaction or collection instruction. The user may receive it by email, text message, an app or a printed document and scan it at a reader or kiosk. The convenience depends on the complete journey: issuance, delivery, presentation, validation, door release, expiry and support. A QR image is only the visible part of that design.
Ask whether the code is static or time-limited, single-use or reusable, tied to one compartment or a wider entitlement, and protected from guessing or unauthorised reuse. Define what happens when a message is forwarded, a screenshot is shared, a user has multiple items or the code is scanned twice. The system should communicate whether a code is accepted, expired, already used or linked to a different task without exposing sensitive data.
Set out how QR access is delivered and recovered. A recipient might not have mobile data, may mistype an email address, delete the message or arrive with a damaged screen. Decide whether an authorised operator can reissue access, what evidence they need and how that intervention appears in the audit history. Consider printed codes for environments where phones are unsuitable, but control print, storage and disposal.
Validate the physical scan conditions. Test screen brightness, glare, reader distance, code size, damaged displays, lighting and the position of the scanner for seated and standing users. Test the expected throughput at peak periods and include a path for users who cannot scan. If a booking, payment or visitor system triggers a code, document the event sequence and clarify which platform can cancel or replace it.
Questions to resolve
- Code issuance and expiry; duplicate-use response; reissue and accessible fallback
Make code rules predictable for users and resistant to misuse.
A PIN provides access through a numeric code entered on a keypad or interface. It can suit temporary users who do not have a badge or app, and it may be easy to communicate through a booking or collection message. Its strength depends on how the code is generated, how it is delivered, what it authorises, how long it remains valid and how the system limits repeated attempts.
Specify code length and lifecycle in the context of the platform’s controls. Ask whether codes are unique, randomly generated, scoped to a user or transaction, one-time or time-limited, and whether an administrator can reset them. Confirm lockout, rate-limiting and monitoring behaviour after repeated failed entry. Avoid choosing a code policy by convenience alone; assess the environment, threat model and user support needs.
Plan delivery carefully. A PIN sent to the wrong phone number can create both a service issue and an access risk. Decide how contact details are verified, how codes can be reissued, how a user reports a compromised code and how operators validate a request before opening or resetting a locker. Avoid displaying a full code in reports or support screens when a safer partial reference is enough.
The interface must make entry understandable. Check keypad placement, legibility, response to incorrect input, timeout, privacy from shoulder-surfing and the route to assistance. Test peak usage and the effect of a network interruption. If PIN is one option among RFID, QR and mobile, make sure the access policy is consistent across methods and all successful and denied attempts are logged with appropriate context.
Questions to resolve
- Expiry and attempt limits; safe reissue; privacy on keypad and support screens
Treat the phone as a channel, not the access policy.
Mobile access can provide a user with an application, browser page, message or device credential for a locker journey. It can connect allocation, notification, directions, access and support in one place. The specific experience differs between native app, mobile web, deep link, QR code, PIN and wallet pass. Define which route is proposed rather than describing the entire category as “mobile access”.
Start with the users and devices. Employees may have managed phones; visitors and customers may use a broad mix of personal devices. Confirm supported operating systems and browsers, accessibility expectations, whether installation is required, and what happens if a phone is offline, discharged or lost. A route that requires an app download may be unsuitable for one-time public use even if it works well for regular staff.
Decide how the phone relates to identity. A link sent by SMS can prove possession of a channel but may not establish the same identity as an employee SSO session. A mobile application may hold a token or use a separate sign-in. Establish how the entitlement is bound to a person or transaction, how it expires, whether it can be forwarded and how it is revoked after cancellation or a change in status.
Design a fallback that maintains the same authorisation standard. Support teams should be able to verify a legitimate user and restore access without asking for excessive personal information. A mobile journey should clearly state the location, compartment or next action, while limiting sensitive details in notifications visible on a locked screen. Test a first-time user, a returning user, an expired link and a device without connectivity.
Questions to resolve
- App, browser or message route; device support; offline and recovery plan
Confirm pass behaviour separately from payment and device access.
A digital wallet pass can present a credential, ticket, identifier or instruction to the user from a supported mobile wallet. For a locker workflow, the pass may support a presentation step, but the pass itself does not define the locker entitlement, allocation, access rule or audit record. Confirm the precise pass design and how it connects with the locker platform and any booking, visitor or identity system.
Do not assume a wallet pass is equivalent to every NFC interaction. A visible barcode or QR on a pass, an NFC credential, a mobile application and a payment card can use different technical mechanisms and may require different readers and services. Vpod’s published guidance distinguishes these pathways, so buyers should confirm the exact credential and reader configuration rather than relying on a broad “wallet compatible” statement.
Plan pass issuance and lifecycle. Which system creates the pass? What event activates it? Can it be updated, cancelled or expired when a booking changes? How does a user receive it, and what happens if the pass is missing or the device is unavailable? Clarify what user data is passed to the locker service and what is retained in each connected system.
Test the full use case on the supported devices and account configurations. Check whether a pass can be presented from the expected screen state, whether the reader gives clear feedback and what happens when a pass is out of date. Provide an equivalent non-wallet route when the audience or device profile requires one. Record the operating-system, reader and platform versions used in acceptance testing.
Questions to resolve
- Pass issuer and update events; reader mode; non-wallet alternative
Explore apple wallet and digital passes pathways in Vpod’s Integration Hub ↗
Connect transaction state to access, support and reconciliation.
Paid locker use combines a commercial transaction with a physical service. The payment provider may authorise or capture funds; the locker platform may allocate a compartment and issue access; a booking or venue system may supply the entitlement. Define the sequence before selecting components. A payment being approved does not by itself prove that a compartment was assigned, access was delivered or the service was completed.
Map the key transaction states: price shown, payment started, authorised, declined, completed, access issued, locker opened, session ended, refund requested and refund completed. Decide which platform owns each state and how it communicates the result to the user. Define what happens if payment succeeds but allocation fails, a locker cannot be opened, the user abandons the journey or a refund is due after an operational exception.
Ask finance and operations to agree settlement, refund, reconciliation, tax and reporting requirements. Identify the transaction reference that links a payment record to a locker session without exposing card details in locker logs. Confirm the payment integration’s responsibilities and security scope with the provider and internal specialists. Do not assume that a locker platform handles card data simply because a payment terminal appears in the user journey.
Test contactless and other agreed methods in realistic conditions, including network loss, duplicate taps, interrupted sessions and refund workflows. Define who can adjust pricing, issue a refund, grant an exception or close a transaction. If a third-party payment integration is used, include its availability, support and change process in the service model. Vpod’s integration directory includes payment pathways such as Adyen; confirm the proposed scope for the specific site.
Questions to resolve
- Payment and locker state ownership; failed-payment flow; refund reconciliation
Unify physical access decisions with locker permissions and events.
Access control describes the rules and mechanisms that decide who may enter a space or use a resource. A building door system and a locker system may share credentials, but their policies are not automatically the same. A person authorised to enter a building may not be entitled to a specific locker, asset or paid storage session. Define the relationship between identity, location, compartment, time window and business purpose.
Map policy ownership. The access-control platform may govern doors; the locker application may govern compartment allocation; an identity provider may govern accounts; a workplace or service platform may initiate the workflow. Specify where each decision is made, how changes propagate and what happens if systems disagree. Reuse a credential where appropriate, but keep separate permissions and audit events where the risks differ.
Confirm integration direction and operational boundaries with the access-control owner. Does the locker system read an existing credential, receive an identity entitlement, or report events back? Is the physical locker event available to security operations? How are emergency access and overrides governed? Agree whether any access-control change requires testing of the locker workflow, and who is called when a door or compartment fails.
A useful access model is least privilege: grant only the access required for the user, purpose and period. Review administrator roles separately from end-user credentials. Retain a controlled route for manual intervention with an approver, reason and audit record. Vpod’s Integration Hub brings together access pathways such as HID and related identity or security contexts; confirm configuration and availability during technical scoping.
Questions to resolve
- Door vs compartment authority; least-privilege roles; override and audit procedure
Draw the path from the locker controller to every service it needs.
A network architecture explains how locker cabinets, controllers, readers, management services and connected systems communicate. Start with a data-flow diagram for the proposed site. Show which components are on premises, which are hosted, which connect to the internet or internal networks, and where identities, commands, status events and reports travel. Label the system owner and support boundary for each connection.
Ask for concrete connectivity requirements for the selected configuration. Record wired or wireless needs, network segmentation, DNS, time synchronisation, firewall destinations, ports, proxy behaviour, certificate handling and bandwidth assumptions where applicable. A general statement such as “needs Wi-Fi” is not a complete network design. The supplier and IT team should jointly document the traffic that must be allowed and the mechanism used to protect it.
Define operating behaviour when connectivity is interrupted. Which functions continue locally? Which actions are unavailable? How are queued events reconciled after recovery? What is the maximum acceptable interruption, and how do users get assistance? Treat failover as an operational scenario with a runbook and test evidence. Do not promise offline access unless the exact system behaviour is documented and verified.
Plan for more than day one. Network addresses, certificates, wireless policies, firewall rules and cloud endpoints can change. Assign an owner for change notifications and regression testing. Include the locker deployment in the organisation’s asset inventory and service maps. During commissioning, test from the actual installation location and network segment, not only from a supplier test bench. Keep approved diagrams and settings with the handover pack.
Questions to resolve
- Approved data-flow and traffic schedule; interruption behaviour; change owner
Explore network architecture pathways in Vpod’s Integration Hub ↗
Assess controls across hardware, software, identity and operations.
Security is a system property, not a single feature or certification. Consider the cabinet, physical locks, controllers, user credentials, administrator accounts, software services, integration interfaces, network paths, data stores and support processes. Identify what could be misused or fail, the consequences, and the controls that reduce the likelihood or impact. A buyer should request evidence linked to the proposed configuration rather than accepting broad statements without scope.
Review authentication, authorisation, credential expiry, privilege separation, encryption in transit and at rest where applicable, audit logging, vulnerability management, update processes, backup and incident response. Ask how secrets are stored and rotated, how security issues are reported, and who decides when a patch is applied to a live locker estate. Confirm the division of responsibility between Vpod, software providers, integrators, the customer and hosting services.
Include physical and service scenarios. What happens if a cabinet is damaged, a controller is removed, a door is forced, a user reports a stolen phone or an administrator account is compromised? How are events detected and escalated? Can an authorised person isolate a site or revoke a credential without disabling unrelated services? Ensure emergency opening is governed and recorded, not handled as an undocumented workaround.
Run a security review early enough to influence architecture and procurement. Capture evidence, exceptions, remediation owners and approval dates. Align retention and access to logs with policy and lawful purpose. Test negative cases such as an unauthorised user, expired credential, restricted administrator and unavailable integration. Reassess the design before major changes to identity, network, payment or connected systems.
Questions to resolve
- Threat scenarios; evidence and responsibility matrix; incident and patch process
Turn operational events into measures that drive decisions.
Locker reporting should help teams answer operational questions: which compartments are occupied, where demand peaks, how many transactions succeed, what exceptions recur and whether a site is meeting its service goals. Before reviewing dashboards, define the decision each report should support and the role that needs it. A long list of charts is not automatically useful if the data is delayed, ambiguous or disconnected from an owner.
Agree measures and definitions. “Utilisation” could mean occupied compartments at a moment, time occupied during a period, completed transactions or availability after exclusions. Define the denominator, reporting interval, treatment of reserved or unavailable lockers, and the source of each figure. Use consistent definitions across sites so portfolio comparisons are meaningful. Include a way to inspect exceptions without granting broad access to personal data.
Separate monitoring from reporting. Monitoring identifies events needing timely action, such as a cabinet outage or unusual fault rate; reporting supports review of trends and capacity. Specify alert thresholds, recipients, escalation windows and acknowledgement expectations. If connected systems supply booking, payment or identity context, indicate whether the report includes that context or only the locker event.
Validate reports against known test transactions. Compare timestamps, status changes, site identifiers and totals with the source systems. Check time zones, late-arriving events, duplicate records and changes to compartment inventories. Provide export and retention requirements to data owners. Tie every alert to a runbook, and every management report to a cadence and accountable team. Vpod’s smart-locker platform page describes central management and reporting capabilities; confirm the exact metrics in the selected deployment.
Questions to resolve
- Metric definitions; alert route and threshold; reconciliation against test data
Explore reporting and monitoring pathways in Vpod’s Integration Hub ↗
Minimise, classify and govern the information each workflow needs.
A locker transaction can involve identifiers, contact details, a site, a compartment, a time, an entitlement and an event. A connected design may also include booking, identity, payment or asset references. Map these data elements before implementation. For each field, document the source, purpose, destination, owner, sensitivity, retention, access roles and deletion or correction route. Collect only what is necessary to operate and support the service.
Separate operational identifiers from information that directly identifies a person where practical. Use consistent keys so connected systems can link a transaction without replicating entire records. Decide which data remains in the identity, visitor, payment or asset platform and which needs to reach the locker service. Avoid embedding sensitive personal data in QR codes, URLs, logs or notification previews unless there is a justified and reviewed need.
Set retention rules for operational events, access records, support notes and integration logs. Different categories may have different purposes and retention periods. Confirm how data is exported, corrected, deleted or preserved when a legal hold applies. Define subject access and incident handling responsibilities across suppliers and controllers. Contracts and technical design should describe the same flow rather than leaving data ownership implicit.
Governance continues after go-live. Name data stewards, review access to reports, record integrations in the system inventory and reassess the data map when a workflow changes. Verify deletion and retention behaviour using realistic tests. Consider data residency, subprocessors and cross-border access in the organisation’s normal supplier review. Vpod’s integration pathways can join workplace, identity, facilities, visitor and payment systems; scope each link and its data fields explicitly.
Questions to resolve
- Data-flow map; purpose and retention schedule; owner for every connected field
Explore data and governance pathways in Vpod’s Integration Hub ↗
Operate a distributed locker estate with controlled central tools.
Remote management can help authorised teams configure sites, administer users, review status and respond to issues without travelling to every cabinet. The value depends on which actions are available, who may perform them and how those actions are recorded. Define central and local roles, the boundaries between locations, and the approvals required for sensitive operations such as releasing a compartment or changing access rules.
For a multi-site estate, agree how common policy is applied and where local variation is permitted. A location may have different opening hours, workflows or support arrangements, but those differences should be visible and owned. Establish naming conventions for sites and locker banks so support teams can identify the right equipment quickly. Record the relationship between physical asset identifiers, software locations and network inventory.
Ask how administrators diagnose common faults remotely. Can they see whether a cabinet is online, whether a door state changed or whether a credential was rejected? Which actions can they take, and what remains a physical maintenance task? Confirm audit detail, permissions, alerts and escalation. Remote tools should reduce uncertainty without encouraging unreviewed changes in a live environment.
Create operational runbooks for user lockouts, offline cabinets, stuck doors, credential revocation, configuration updates and site handover. Test the escalation path across Vpod, the customer team and any software or connectivity provider. For significant changes, use approval, maintenance windows and rollback steps. The smart-locker page describes connected central administration and multi-site management; confirm the functions, roles and service coverage included for the specific deployment.
Questions to resolve
- Role-based remote actions; site inventory; change log and operational runbooks
Explore remote management pathways in Vpod’s Integration Hub ↗
Follow the technology into Vpod’s Integration Hub.
Move from a technology decision to the operational pathway it supports. The Integration Hub brings together Vpod integration contexts across workplace, identity, payments, security, facilities, parcels, wallets, venues and service management. Each project should confirm the exact trigger, data exchange, authentication method, exception handling, connector scope and operational owner.
For the core platform, use the Vpod Smart Lockers page to review how the hardware, management software and connected service fit together. Then take the relevant integration questions to technical discovery.