Description
A major on-demand delivery platform came to us with the problem every delivery business in a dense city runs into eventually: the last metre. Riders were losing ten minutes per drop in the lobbies of office towers and apartment complexes — waiting for a lift they could not use, calling a customer who was in a meeting, or leaving food at a reception desk that never agreed to be a parcel room.
The answer was a delivery locker: a bank of individually locking compartments in the lobby, where the rider drops the order and leaves, and the customer collects when they are free. KioskForce built the whole thing — cabinet, the software running on the machine, the cloud service behind it, the operator portals, and the API that the delivery platform’s own systems integrate against.
This was scoped as a delivery system rather than a click-and-collect one, and that distinction drove the design. A click-and-collect locker is loaded by staff who work in the building every day. A delivery locker is loaded by a rider who has never been there before, holding a code issued minutes earlier for a cell the platform picked while the customer was still choosing their order — so cell assignment, code issue, door control and the event trail all had to be driven by the platform’s API rather than by anyone on site.
The platform is open to other partners. It is finished, tested and publicly documented, and available to deploy for other delivery services, building operators, and grocery and pharmacy operators — see the delivery locker overview.
What We Delivered
- The locker cabinet — compartments sized to the traffic rather than a catalog. Ten cells per cabinet, ganged across three actuator boards for around thirty cells in a typical installation, on castors. Every cell has its own light, its own ultraviolet sanitising lamp that runs while the compartment sits idle after a collection, and active ventilation so a hot meal does not steam up its own cell. A heating pad is available per cell as a build-time option; per-cell weight sensors likewise.
- On-machine software — touchscreen interface, QR scanner, numeric code entry, door and hardware control, and full-screen advertising playback between transactions.
- The cloud service — cell allocation, reservation lifecycle, real-time instruction delivery to machines, and a scheduler running the grace-period and sanitisation cycles across the estate.
- A public integration API — REST and gRPC, with webhooks for every state change, published with an OpenAPI specification at delivery.kioskforce.com.
- Operator portals — locker and platform configuration, reservation tracking, per-cell open and recover, and advertising upload and assignment.
- A command-line tool — a single static binary for Linux, macOS and Windows, so the customer’s team could drive a real reservation end to end before writing integration code.
How a Delivery Runs
- The delivery platform reserves a cell as the customer places the order — with package dimensions, and a heated-cell requirement if the food needs one. It gets back a cell label, a drop-off code, a pickup code, and QR codes for both.
- The rider opens the cell — by QR scan, by typing the drop-off code, or by tapping unlock in the rider app, which calls our API. The cell light comes on and the door releases.
- When the door closes, a webhook fires and the platform passes the pickup code to the customer.
- The customer collects the same three ways. A grace period lets them reopen the door if they close it too early.
- The cell then runs its ultraviolet sanitising cycle while it sits idle, ventilates, and rejoins the available pool. It happens per compartment, so the rest of the cabinet stays in service throughout. Nobody has to attend the machine.
The Engineering That Mattered
Lockers live in basements and lift lobbies on marginal mobile signal, and a locker that misses a door-open instruction has stranded somebody’s dinner behind a locked steel door. So the instruction path was built to survive a bad network:
- Instructions are pushed over a live WebSocket, cached server-side for 30 seconds, and acknowledged by the machine before they are cleared.
- A machine that drops off and reconnects inside that window has its pending instructions replayed in order — and several queued instructions all survive, rather than the newest overwriting the oldest.
- An instruction that is never acknowledged is logged as an error against that locker, so a failing modem surfaces in operations rather than in customer complaints.
- Webhooks carry an event ID and an idempotency key, so a retry is safe for the platform to deduplicate.
- Older machines that do not announce acknowledgement support are served exactly as before. Backwards compatibility was a hard requirement throughout — units in a building lobby are not easy to reflash.
Deployment Scale
The system was provisioned across staging environments for both a regional edge deployment and the central cloud service, with a locker dataset spanning five cities across three continents, to prove out multi-region cell allocation, geospatial locker search, and per-platform isolation before any hardware shipped in volume.
Available to Integrate
The platform is complete, tested, and publicly documented. It suits:
- Delivery and on-demand platforms — food, grocery, pharmacy, courier
- Building owners and facility managers in office towers, apartments, co-living and student accommodation
- Grocery, pharmacy and QSR operators running their own delivery fleets into residential and office buildings
- Locker network operators who want to run an estate and sell access to several delivery platforms at once
Read the delivery locker overview, or go straight to the API documentation.
Setup cost shown is indicative for a pilot deployment. Final pricing depends on cell count, how many compartments carry the optional heating pad, locker quantity and integration scope. Contact us for a configuration-specific quotation.
Cost
- Initial Cost: $20000
