The software behind every locker we run.
Access control, payments, inventory, resident app, operator reporting and 24/7 support routing in one system, and underneath it, software that reads how your building actually uses the hub and adjusts the offering to match.
Hardware is the easy half of a locker
Cabinets and smart locks are a solved problem. What decides whether an installation is still useful in year three is everything around them: who can open which door, how a payment reconciles, what happens when a lock fails at 2am, and whether anyone can tell you what the building actually used.
That layer is the product. It runs every Lentra installation (the convenience hub, the Click & Collect bank, and the reporting the property team sees) from one system rather than three that have to be kept in step.
One system, three surfaces
- The locker Door control, sensors, codes and the kiosk in the lobby.
- The resident An app that handles browsing, booking, paying, unlocking and asking for help.
- The operator A dashboard with revenue, usage, availability and the request queue.
Everything an installation needs to keep working
Each one is part of the running service rather than an add-on with its own login.
Access & locks
Compartment control, one-time codes, permissions and an audit trail on every open.
Payments
Saved methods, instant checkout, receipts, refunds and reconciliation.
Inventory & demand
What is in each compartment, what is running out, and what the next restocking run should carry, sized against real demand rather than a fixed list.
Resident app
Browse, reserve, unlock, pay, suggest items and report an issue, branded per building.
Operator dashboard
Revenue, usage, availability, top items and a projection you can model.
Support routing
Issues raised in the app land with Lentra's 24/7 desk, not the building's front desk.
Monitoring
Remote diagnostics, door and sensor health, and alerts before a resident finds the fault.
Demand learning
Reads real usage and resident requests, then suggests what to add, what to retire and what to stock more of.
Exports & DMS
Reusable ZIP, FTP, SFTP and FTPS destinations for delivering data where it needs to go.
On our hardware, or on yours
Most buildings take the software as part of a Lentra installation. Operators who already have lockers in the ground do not have to replace them to get the software layer.
With a Lentra installation
The default. Hardware, software, app, support and reporting arrive together and are operated by us.
On an existing estate
The software runs against lockers already installed, subject to what their controllers expose. Scope is established before anything is promised.
Under your own brand
Resident app, kiosk and notifications carry the operator's identity rather than ours, with our software underneath.
What can be supported on third-party hardware depends entirely on the lock and controller in question. We establish that in a technical review before it goes in a proposal, not after.
It learns what the building actually wants
The software reads usage as it happens and keeps refining what the hub carries, so the selection in each building reflects the people actually living or working in it rather than a standard list. In practice that means supplying what is in demand, retiring what is not, and recommending new items before residents even ask.
What it reports is what happened: usage, availability, support requests and resident feedback. Positioning effects do not come out of an installation, and the software does not pretend otherwise.
The loop, month after month
- 1 Watch Every rental, purchase, reservation and resident suggestion is counted against the building it happened in.
- 2 Suggest Slow lines are flagged for retirement, busy ones for more stock, and new items proposed from what residents keep asking for.
- 3 Adjust The property team approves the change; the next restocking run carries it and the app catalogue updates.
A sale is one yes. Use is everything after it.
Almost every consumer product business learns exactly one fact about its customer: that they bought it. After the till, the signal stops. A hub that lends things out and takes them back does not have that blind spot, and the models running on top of it turn that difference into something you can act on.
What a purchase tells you
- One event, at one moment, with no context around it
- Nothing about whether it was ever taken out of the box
- Nothing about the second use, or whether there was one
- A product bought and abandoned scores exactly like one that gets loved
- Returns and complaints arrive only when something went badly wrong
What continued use tells you
- Whether the first use happened at all, and how soon
- Whether they came back, and whether that became daily, weekly or never again
- How long each use actually lasts
- Whether it settled into a staple or died after one go
- What residents asked for and could not find
Better prices on what people use
Volume concentrates in a small set of items in every building. Knowing which ones, in this building, is what makes it possible to price them down rather than spreading a margin thinly across a catalogue nobody touches.
Retire what nobody reaches for
A line that has not moved in a quarter is occupying a compartment something else could earn from. The models flag it, propose a replacement from what residents have been asking for, and the next restocking run carries the change.
Evidence for the people who made it
Brands and suppliers almost never learn what happened after the sale. We can tell them: which products became habits, which were tried once, where the drop-off sits. That is a better brief for the next version than a units-sold figure.
What we do not share
Insight that leaves Lentra is aggregated and anonymised. A supplier learns that a category is used twice a week and abandoned after the third try; they do not learn who, which flat, or anything that could be traced back to a person. Resident-level data stays with the resident's own account and the terms in the building's contract.
The honest limit still applies: the system counts what happened. It does not know why someone stopped, and it will not manufacture a reason to fill the gap.
Why one number is the worst way to judge a productInsight the building has never had before
Amenity decisions are usually made on instinct, a competitor's brochure and whatever the on site team happens to remember. An operating hub produces something better: a continuous record of what the people in this building reach for.
Demand, by building
Which categories move, which sit, how that changes by season and by hour. The same operator running four properties can finally see how differently each one behaves.
Engagement, not impressions
Weekly actives, repeat use and what residents request and cannot find. A count of who uses the amenity, rather than a count of who was shown it on a tour.
Evidence for the next spend
Something to hold the next amenity decision against. Where residents actually spend their attention is a better brief than a competitor's feature list.
One limit worth stating. The system knows what was opened, reserved, bought, requested and reported. It does not know why someone stopped borrowing the steamer, and it will not invent a reason. Everything in the portal is a count of something that happened.
Software questions
Can we license the software without the hardware?
Is there an API?
Where does the data live?
What happens if the network drops?
Can the app carry our brand?
Talk to us about the software
Whether it is a full installation, an existing estate or a white-label deployment, it starts with a technical review rather than a quote.