Parcel locker software, for deliveries nobody is home for.
A door that opens twice, and remembers both times.
The software behind a parcel locker network: the courier drops a parcel and the door assignment happens in seconds, the recipient collects it whenever they like, and returns go back the same way. We build the carrier integration, the allocation logic that decides which door a parcel goes in, the notifications that get it collected, and the chain of custody that says who opened what and when.
What a parcel locker network runs on
A locker bank is easy. A network of them, shared between carriers and busy at the wrong times, is the actual problem. These are the parts we build.
Courier drop-off
The step that decides whether couriers use the bank at all. A scan, a door, a photo if it is needed, and the courier is gone, with the allocation choosing a compartment that fits rather than sending them to a door the parcel will not go in.
- Barcode scan to door assignment
- Compartment sizing from parcel dimensions
- Courier app or on-screen drop-off flow
- Bulk drops of multiple parcels in one visit
Customer pickup and notifications
Collection is a race against the next delivery needing the door. Codes go out immediately, reminders escalate before a parcel goes stale, and the pickup itself is a code or a scan rather than an app download nobody wanted.
- PIN and QR collection codes
- Notifications by email, SMS, or app
- Reminder escalation before expiry
- Nominated collection by someone else
Returns and reverse logistics
The return journey is where lockers earn their keep, because a customer can drop a parcel at midnight and a carrier can collect a full bank in one stop. Labels are generated or scanned at the locker and the return is booked before the courier arrives.
- Label-free returns with a code
- Label printing at the locker
- Return booked before courier collection
- Consolidated pickup by carrier
Multi-carrier and open networks
A bank used by one carrier sits half empty. Opening it to several means keeping their parcels, their access, and their reporting separate while sharing the same physical doors, which is a permissions problem more than a hardware one.
- Per-carrier access and parcel segregation
- Carrier API and webhook integration
- Door quotas and allocation rules per carrier
- Separate reporting and billing per carrier
Capacity, dwell time, and turnover
A parcel locker fails by filling up, not by breaking. We report dwell time per parcel, occupancy per bank across the day, and the sites where uncollected parcels are blocking doors, so the network is rebalanced on evidence rather than complaints.
- Live occupancy per bank and door size
- Dwell time and uncollected parcel aging
- Expiry, sweep, and return-to-depot rules
- Utilisation reporting per site
Chain of custody and proof of delivery
Every door event is recorded: which parcel, which door, which courier or customer, and when. That is what settles a dispute about a parcel that a tracking page says was delivered, and it is the reason the audit log is built first rather than added later.
- Per-door event log with identity and timestamp
- Photo capture on drop-off and collection
- Tamper and forced-door alerts
- Exportable audit trail per parcel
Mapping a vending estate to its legal establishments
A vending build rather than a parcel one, and it is here for the traceability. Every item was tied back to a registered supplier, validated against the official register, and reportable across the whole estate, which is the same discipline a parcel network needs to prove which door held what and who opened it.
Read the case study- 01Establishment resolution service
- 02Review queue for weak matches
- 03Change tracking against the register
How the work runs
Tell us what you need
A short written brief is enough to start: what you are building, the stack it has to live in, and the problem behind it. Someone technical reads it, not a sales rep.
passed when we reply with questions and a proposed shape
Scope and quote
We agree what the first release contains and what it costs before anything is built. Anything we cannot estimate honestly gets scoped on its own rather than padded into the total.
passed when the scope and the quote are agreed
Build in the open
Working software arrives in increments, in your repository, with our commits visible from the first week. Progress is something you can open and run, not a status report.
passed when a real user is doing a real job in it
Iterate, then hand over
What the first release teaches sets the priority for the next one. When you want it in house, documentation and a handover period are part of the engagement rather than an extra.
passed when your team can run it without us
How pricing works
Fixed price per milestone
You approve each milestone and its price before it starts, so the cost is known before the work is rather than after. Milestones are sized to be worth reviewing on their own.
Monthly rate for a dedicated team
A set team at a set monthly cost, with notice rather than a minimum term. Priorities move between sprints without renegotiating anything.
Scoping first, quote after
We work out what it should be with you before quoting it. There is no charge for that conversation and no obligation to go ahead.
Frequently asked questions
What every parcel network ships with
Every build ships end to end, from first scope to live deployment and ongoing support.
