How 680 Smart Lockers Modernized a 24/7 Office in Bucharest

Most office locker rollouts are a procurement story: how many doors, what material, how long until installation. The 680-locker deployment we delivered in Bucharest last June was different. The brief was operational from day one.

The client runs a 24/7 service business out of a single office complex in central Bucharest, with hundreds of employees moving through shift handovers around the clock. Their existing setup — physical keys, fobs, and a clipboard sign-in sheet at the locker rooms — was creating real friction: lost keys every week, an HR team spending hours on onboarding paperwork, and no visibility into who used what when. They came to us looking for a system that would disappear into the background.

The hardware: 680 phenolic doors, two locker rooms

We installed 680 lockers across two locker rooms — one for male staff, one for female staff — sized and laid out around their peak-hour traffic patterns. The doors are compact phenolic resin: water-resistant, anti-bacterial, micro-perforated on the back for ventilation, rated for thousands of daily openings.

That last number matters. A 24/7 operation with three shift changes a day means each locker is opened and closed roughly 6–8 times per day. Across 680 lockers that is around 4,000 to 5,000 daily door operations — the kind of workload where a consumer-grade locking mechanism would start failing within months. The phenolic + electronic-lock combo we deployed is rated for that volume and then some.

The software: fingerprint, API, and conditional rules

What turned this into a real case study (rather than just an installation) was the software layer. The client runs on MyLock Cloud, which gave them three things their old setup could not:

Fingerprint authentication on every door. No keys to lose, no fobs to deactivate, no PINs to write on sticky notes. An employee shows up, presses a finger, the right locker opens. That is the entire user experience.

API-driven onboarding. The client's HR system creates a new employee record; our API receives the event; the system provisions a locker, captures the employee's fingerprint on first use, and emails them their assignment with usage instructions — all without HR touching anything. When someone leaves, the same flow runs in reverse: the API call deprovisions the locker the same morning their access card is revoked.

Conditional access rules. This is where the operational benefits compound. The admin portal lets the facilities team configure rules per locker bank: lockers expire automatically after a set number of hours of continuous use; access is blocked during scheduled cleaning windows; specific lockers can be flagged as "needs cleaning" by the on-site team and removed from the assignable pool until the cleaning crew clears the flag. None of this requires a developer or a support ticket — it is all in the admin UI.

The numbers that mattered

The metrics the client tracked in the months after rollout were not the ones they expected. The biggest improvement was not in security incidents (they had had very few to begin with). It was in HR time saved: the entire monthly onboarding-and-offboarding cycle for locker access dropped from roughly 4–5 hours per cycle to under 20 minutes of supervisor review. The cleaning team's daily routine got noticeably more efficient too, because the "needs cleaning" flag let them work through flagged lockers without checking every single one.

The lost-key problem disappeared entirely. There are no keys.

What this kind of deployment requires

If you are weighing a similar rollout — multi-shift operation, hundreds of doors, an HR system that should drive the locker lifecycle — three things matter more than locker count:

1. A real API on the locker management side. Without it, every onboarding becomes a manual step and the rollout never reaches the efficiency you sold internally.
2. Conditional rules that the facilities team can configure themselves. The cleaning and expiration logic in Bucharest was tuned three times in the first month based on real usage patterns. If we had to ship a code change each time, it would not have happened.
3. Hardware rated for the actual workload. Phenolic + a mechanical lock spec'd for 100,000+ cycles is not optional in a 24/7 environment.

We deliver this stack as a single project. If your operation looks like the one above and you want to see what the rollout would look like in your space, get in touch — we will walk you through the sizing, the API integration, and what a realistic deployment timeline looks like.