We will look at your site and equipment and tell you what can be connected
Which cabinets and locks are already installed, what they expose, which access scenarios you need and where it makes sense to start.
Software for storage rooms and lockers
Software for luggage storage, storage points and cabinets with electronic locks
A cabinet of lockers is metal and locks. Software turns it into a service: a person gains access by code or card, the locker opens by itself, the system knows which locker is occupied, by whom and until when, and every opening stays in the log. Below is how it works — from a tap on the screen to the click of the lock and the entry in the history.
What software for
luggage storage and lockers is
Locker software — a system that decides who gets which locker, opens its electronic lock at the right moment and keeps a record of every opening: who, when and on what grounds.
The difference from an ordinary cabinet is clear from a single example. With a key or a padlock, a person is responsible for the locker: they handed out the key, remembered the number and took it back. A lost key means forcing the door, a dispute is settled by what the shift remembers, and how many lockers are free right now is known only by whoever is standing there.
An automated locker has no key. The right to open the door is a record in a database: this code is valid for that locker until that time. A code can be issued, revoked, extended and passed to someone else without going anywhere near the cabinet. And the occupancy of every locker at every site is visible in one list.
An example. A shopping center visitor leaves their bags in a locker: they scan a QR code at the screen, the door opens, they close it and walk away. Two hours later they open the same locker with the same code. Two opening records remain in the system, along with the storage start time and a note that the locker has been freed up and is ready for the next session.
Luggage storage automation begins where the answers to three questions no longer fit in the attendant's head: how many lockers are occupied right now, who exactly opened a particular locker today at 14:20, and what to do about belongings that have been sitting there for a second day.
- 1User
- 2Identification
- 3Rights check
- 4Cabinet controller
- 5Electronic lock
- 6Door sensor
- 7Event log entry
- 8Administration panel
The link works both ways: the command travels left to right, the confirmation comes back. An opening counts as having happened not when the command is sent but when the door sensor answers. Without that step the system would report what it believes about its lockers rather than what is actually happening on site.
What the system knows about every locker
- Where it is — site, zone, cabinet, locker number and size type
- Whether it is occupied — free, reserved, occupied, awaiting release, blocked
- Who is using it — the storage session with its start time, duration and access method
- What opens it — which code, card or user account is valid for it right now
- What has happened to it — every opening and closing with an exact time and a reason
- Whether it is working — whether the lock responds, whether the controller is connected, whether the door closes
How this differs from a parcel locker
The equipment looks similar — the same cabinet, the same locks, the same codes. The difference is in the purpose. A parcel locker hands someone else's parcel to a recipient: a courier puts the item in, the addressee takes it out, the compartment is freed. Luggage storage is rented to a person for a period: they put their own belongings in and take them out themselves, and the locker is charged by duration.
Hence the different requirements for the software: for a parcel locker what matters most is the link to the online store and the delivery service, while for luggage storage it is the session, the term, the extension and returning the locker to circulation. Order collection is covered in detail on the self-service systems page.
How it works: from the code to the open door
The whole path a single request takes — from the person at the cabinet to the entry in the log. Further down the page each of these links is examined in more detail.
1. The cabinet and the lockers
The physical part: cabinet sections, lockers of different size types, doors. Every locker is registered in the system as a separate object with its own number, size, zone and state. The cabinet can be extended with a new section — in software terms that is adding lockers, not a rebuild.
2. Electronic locks
A lock opened not by a key but by an electrical pulse from the controller. A door sensor usually sits next to it and reports whether the door actually opened and closed. A lock without a sensor works too, but then the system only knows about the command, not about the result.
3. The cabinet controller
A small device inside the cabinet that all the locks and sensors are wired to. It receives the command open locker 14, sends a pulse to the right lock and returns the result. One controller serves dozens of lockers, so the cabinet connects to the system over one channel rather than forty wires.
4. The user access point
Whatever the person uses to reach the system: a screen on the cabinet, a separate terminal in the hall, a card reader or their own phone. There can be several at once — the scenario is the same, only the input method differs.
5. The server side
Where decisions are made. The server holds the lockers, sessions, codes, rights and log, validates the request and sends the command to the controller. It also counts the storage period and prepares notifications and reports. Hosting — in a data center or on the customer's own equipment — is decided by the project.
6. The admin panel
The workplace of a site employee: a map of cabinets, locker occupancy, active sessions, events, manual opening, blocking a locker, roles and reports. It opens in a browser, with nothing to install.
- InputThe person holds a QR code up to the scanner or types a PIN on the cabinet screen
- Rights checkThe server looks for a valid session against that code: does it exist, has it expired, which locker does it belong to, has the attempt limit been exceeded
- CommandA command to open the specific locker goes to the cabinet controller; the code itself is never sent to the controller
- Pulse to the lockThe controller applies voltage to the lock of the right locker and waits for the door sensor's answer
- ConfirmationThe sensor reported that the door is open. Only now does the opening count as having happened — not at the moment of the tap
- RecordThe log receives the locker, time, access method, session and outcome. A record is created on refusal too — code expired is an event as well
- ClosingThe sensor reports that the door was closed. If that has not happened within the allotted time, the system raises a separate event
The order matters exactly as it stands. The rights check happens on the server, not in the cabinet: the controller does not store codes and does not decide who to let in — it carries out a command. That is why access can be revoked from the panel in a second, without going near the equipment.
The software ecosystem of the solution
The system is assembled from modules. Not every site needs all of them: office lockers do not need a payment module, and luggage storage at a railway station does not need corporate roles. The composition is determined by the task, but the modules are designed to fit together in advance rather than being bolted on later.
User interface
What the person sees: the cabinet screen, a browser page behind a link, or a mobile app. Three or four steps — choose a size, get a locker, open it, close it. Errors are explained in words: the storage period has expired, not error 403.
Administration panel
The employee's workplace: cabinet occupancy, active sessions, events, manual opening with a stated reason, blocking a locker, tariff and rule reference data, reports. All in a browser, with role-based separation.
Locker management
A register of lockers: site, cabinet, number, size type, zone, current state and history. A locker can be taken out of circulation for repair, reserved for a specific purpose or grouped with others under shared access rules.
Electronic locks
The layer that works with the lock: the open command, waiting for a response, handling a failure, retrying. The lock type is accounted for here too — with or without a door sensor, with feedback on the bolt position or with a pulse only.
Equipment controllers
Exchange with cabinet controllers: the command queue, connection monitoring, port state, firmware version. Different models are connected through separate exchange modules but look identical in the interface.
Identification
Checking who is standing at the cabinet: QR code, PIN code, card, an account in the app. The methods can be combined and enabled per site — a code on one cabinet, an employee card on another.
Reservations
A locker is taken in advance: for a period, for a date, for a recurring interval. The reservation holds the locker until the person arrives and is released automatically if they do not come — otherwise half the cabinet stands reserved for nothing.
Payment module
Where storage is paid: the tariff, calculating the amount, payment, a surcharge for overstay, refunds. The specific payment methods depend on the connected provider and equipment — this is an integration, not a built-in function.
Notifications
Messages to the user and to the employee: the access code, a reminder that the period is ending, a door left open, a locker freed up, a cabinet failure. The delivery channel is chosen during rollout.
Action and event log
An immutable history: openings and closings, access refusals, service openings, changes to tariffs and rights, employee actions. Records are not edited — a correction is entered as a new record.
Equipment monitoring
The state of cabinets and locks: whether the controller is connected, whether the lock responds, whether a door is stuck, whether there is power. A faulty locker is taken out of allocation automatically rather than discovered by a visitor.
Employee roles and rights
Attendant, site administrator, service team, manager. Manual opening, extending a session, changing a tariff and viewing personal data are separate rights, not one administrator bundle.
API and integrations
The system's external interface: issue a locker, get a code, check a state, close a session, pull the log. It is how accounting systems, CRM, the site's access control system and the customer's own services connect.
Analytics and reporting
Utilization by hour and by day, locker turnover, the distribution across size types, the share of overstays, equipment failures, revenue where storage is paid. Reports export to a file and can be built on a schedule.
Backend platform
The core that ties all of the above together: session accounting, command queues, the scheduler for deadlines and notifications, log storage, backups with restore verification.
How a user
gains access to a locker
There are two access scenarios, and they do not replace each other. In the first, a person walks up to a free cabinet and takes a locker on the spot. In the second, a locker is assigned to them in advance: reserved, rented by the month or issued as a workplace locker.
Access on the spot. The visitor chooses a size on the screen, the system picks a free locker of that size type and opens it. At the same moment a storage session is created and a code is issued — on the screen, on a printed slip or in a message. That code is the key: it works only for that locker and only until the end of the period.
An assigned locker. Here the person themselves becomes the key: an employee card, an account in the app, a permanent PIN. The locker opens once they are recognized, no new session is created on each visit, and the term is set by a contract or a schedule rather than by hours of storage.
What happens between openings:
- The locker stays assigned — it is not given to anyone else until the session is closed
- The code can be reused — where the site's rules allow it: put something in, leave, come back, add more
- The clock is running — the system counts the storage time and warns in advance that it is ending
- Access can be handed over — a second code for the same locker is issued to another person where the scenario allows it
- Access can be revoked — the code stops working immediately, with no need to go to the cabinet
- 14:05 — selectionThe visitor chooses the medium size on the screen; 12 lockers of that size type are free
- 14:05 — allocationThe system assigns locker no. 27, creates a session and opens the door. The code is shown on the screen and duplicated in a message
- 14:06 — closingThe sensor confirmed that the door is closed. The paid time starts counting from this minute
- 16:40 — reopeningThe same code, the same locker. The event is recorded, the session continues, the locker stays assigned
- 18:20 — warning40 minutes left of the paid period. A reminder goes out with two options: collect the belongings or extend
- 18:52 — completionThe visitor takes their belongings and confirms completion on the screen. The session is closed, the surcharge is calculated and paid
- 18:53 — back into circulationThe locker is marked free, the code is voided, the next allocation can happen immediately
A screen from the system; the times are illustrative. Note the last step: the locker goes back into circulation at the moment the session closes, not whenever an employee notices. Otherwise by evening half the cabinet is recorded as occupied while physically standing empty.
Exceptions
There are only a few of them, and all of them are planned for in advance — otherwise each one turns into a call to the administrator.
- The code is lost — it is reissued against the same session: through a message to the phone given at allocation, or through an employee who holds the right to perform this operation
- The door did not open — the command went out, the sensor is silent. The system does not close the event as a success: it retries, and on a second failure it takes the locker out of circulation and creates a service task
- The door was not closed — a separate event stating the locker and the time. While the door is open, the locker counts as neither correctly occupied nor free
- The period expired with belongings inside — the locker moves into the overstay state: user access is either kept or blocked according to the site's rule, and an employee receives the list of overdue lockers
- Opening by an employee — always possible, but it is a separate right and a separate log entry with a mandatory reason
- The connection to the cabinet was lost — requests to it stop rather than piling up blindly; the option of the controller working offline is covered below
Methods of identification
Identification answers one question: does this person have the right to open this locker right now. The method is chosen to suit the site and the equipment — what works at a railway station does not suit an office locker. Whether a specific method is possible depends on what is installed on the cabinet, so the set is determined during discovery.
QR code
The code is shown on a phone screen or printed on a slip, and the cabinet reads it with a scanner. Convenient for one-off visitors: there is nothing to memorize or type. It requires a scanner on the cabinet and a working screen on the user's side.
PIN code
A few digits typed on a keypad or on the screen. The least demanding method: it works without a phone, without the user having internet and without extra equipment. It requires a limit on attempts and a validity period.
Card or fob
A contactless credential held up to a reader. The main method wherever people already carry a pass: an office, a plant, a fitness club. It often makes it possible to use the passes already issued at the site — this is confirmed by card type.
Mobile app
The locker is opened by a button in the app rather than by a code on the cabinet. Suited to regular users and subscriptions; it is also a convenient place to show the history, the term and the payment. It requires the user to have a connection at the moment of opening.
Document barcode
An existing document becomes the key: an order number, a ticket, a coupon, a delivery note. The locker is linked to it and no separate code is issued to the person. Whether this is possible depends on where the document comes from and whether it can be reached through an integration.
Biometrics
A fingerprint or a face instead of a code or a card. Technically it connects as one more reader, but it requires a separate decision on the storage and protection of personal data, so it is treated as a possible option for a specific project rather than as a default method.
| Site and scenario | Primary method | Why |
|---|---|---|
| One-off visitors, footfall, payment on the spot | QR or PIN | Nothing has to be issued in advance and taken back afterwards |
| Employees with passes | card | The credential is already in hand, no separate code is needed |
| Subscriptions and regular customers | app | The term, the payment and the request history live in the same place |
| Handing an item from one person to another | separate codes | The person who puts the item in and the person who collects it each have their own code |
| A site where visitors have no reliable internet | PIN only | It does not depend on a phone or on connectivity at the person's end |
The methods do not exclude each other: one cabinet can run a card for employees and a code for guests at the same time. What matters is which method is the primary one, because the validity period, the number of attempts and the reissue rules are configured around it.
Electronic locks
and equipment controllers
This is the most physical part of the system, and whether the software tells the truth depends on it. Electronic lock is opened by a short electrical pulse: voltage arrives, the bolt retracts, the door is released. The lock itself knows nothing about people or codes.
The controller — a device inside the cabinet that the locks and sensors are wired to. It receives the command open locker 27 from the server, sends a pulse to the right output and returns the result. One controller serves dozens of lockers, so the cabinet connects to the system over a single communication channel.
Door sensor — what separates an assumption from a fact. Without it the system only knows that the command was sent. With it, it knows the door actually opened and how long it took to be closed. Whether sensors are present is a question about the specific cabinet model, and it is answered before work begins.
What is taken into account when connecting equipment:
- Lock type — pulse or holding, with or without feedback on the bolt position
- Presence of a door sensor — it determines whether the system can tell opened apart from tried to open
- Controller interface — exactly how commands are issued to it and in what form it returns state
- Lockers per controller — how many outputs are in use and how many are left for extending the cabinet
- Power — what happens to the locks when power is lost and whether a backup supply is provided
- Mechanical opening — whether there is an emergency way to open a locker without electricity and who controls it
We do not claim support for specific brands of locks and controllers in advance. The set of connectable equipment is determined during discovery, from the manufacturer's documentation and from the interface the device exposes; where no ready interface exists, the question is settled separately and before work begins, not with a promise of compatibility.
What happens when the connection drops
The link between the cabinet and the server breaks — that is a normal situation, not a once-a-year emergency. The behavior at such a moment is designed in advance, and there are two options.
Without an offline mode the cabinet simply stops serving: the screen reports that there is no connection and no new lockers are allocated. The belongings inside are safe, but they cannot be collected before the connection is restored without an employee.
With an offline mode the controller holds a limited set of valid codes and keeps opening lockers against them, stacking events in a queue. When the connection returns, the whole queue goes to the server. This mode is a separate design decision: it requires memory on the controller and makes code revocation less than instant.
The states the system distinguishes
| What the equipment returned | How it is interpreted |
|---|---|
| Command accepted, the sensor confirmed the opening | opened |
| Command accepted, the sensor is silent | needs checking |
| The door has been open longer than allowed | event |
| The controller did not answer the command | event |
| The cabinet is not coming online | event |
| The door opened without a command | event |
The sensor is silent line is the most important one. The system treats such an opening as neither having happened nor not having happened: it marks the locker as needing checking and does not allocate it to the next person until the matter is settled.
Occupancy and locker states
A locker is always in exactly one state, and the transitions between states are set by rules rather than by an employee's decision on the spot. These states are what add up to the answer to the question of how many lockers are free right now — and that answer has to be correct without a walk to the cabinet.
Free
The locker is working, empty and can be allocated to the next person. Only such lockers take part in selection at allocation and in reservations.
Reserved
Assigned in advance and not given to others, but nothing has been put in it yet. A reservation has a deadline: if nobody comes, the locker returns to circulation by itself.
Occupied
A storage session is under way: there is an access holder, a start time and a term. This is the main working state, and the locker spends most of its time in it.
Awaiting collection
An item was placed by one person for another. The locker is occupied but the key belongs to the recipient — the handover and order collection scenario.
Overdue
The storage period has expired with belongings inside. The locker is not allocated, goes onto a separate list and is handled under the site's rule — by a surcharge, a block or removal of the contents.
Needs checking
The opening was not confirmed by the sensor, the door was left open, or an opening without a command was recorded. Until this is investigated the locker is taken out of allocation.
Faulty
The lock does not respond or the controller reported an error. The locker is taken out automatically and a task is created for the service team.
Blocked manually
An employee took the locker out of circulation: cleaning, section repair, operational need. A block has an author, a reason and a time — otherwise it is unclear who closed ten lockers and why.
240lockers at the site
171occupied now
9overdue need investigation
4out of circulation
A screen from the system; the figures are illustrative. The breakdown by size type matters more than the overall figure: a site with 71% of its lockers occupied may have not a single small one free — and small lockers are what most visitors come for. The same table shows which sizes are worth adding when the cabinet is extended.
Reservation, handover
and item drop-off
Reservations is needed wherever a person's arrival is predictable: they know they will come on Thursday and want to be sure a locker will be there. The system assigns a locker for the interval and does not offer it to anyone else.
A reservation always has a waiting deadline. Without one, a site quickly reaches the state where no lockers are free while the cabinet is half empty: people reserve and do not turn up. If they do not arrive by the agreed time, the reservation is released, the locker returns to circulation and the person receives a notification.
Types of reservation:
- One-off — a locker for a specific day and interval
- Recurring — every Tuesday and Thursday, for subscriptions and schedules
- Long-term — a locker assigned for a month or for the term of a contract, like a rented storage room
- Operational — a locker reserved by the site for a specific purpose and not allocated to people
Handover and collection — the second scenario, in which the locker becomes a handover point between two people. One person puts an item in, another takes it out, and they never have to meet.
Technically this is the same session but with two different access rights: a drop-off code and a collection code. The first is voided once the door closes, the second becomes valid from that moment. This way the system knows not only that the locker is occupied but that the item has been dropped off and the recipient has not been yet.
- AssignmentAn employee or the system picks a free locker of a suitable size and creates a handover session
- Drop-off codeGoes to the person leaving the item. Valid for a limited time and for one opening only
- Drop-offThe locker is open, the item is inside, the door is closed. The drop-off code is voided and the session moves to the awaiting collection state
- Collection codeGoes to the recipient together with the site address, the locker number and the deadline the item will wait until
- CollectionThe recipient opens the locker with their own code, takes the item and closes the door
- Closing the sessionThe locker is freed up. If the recipient does not come in time, the session goes overdue and lands on the investigation list
Splitting the codes is not a formality. As long as there is one shared code, the question of who exactly opened the locker — the person who left the item or the person who collected it — cannot be answered. With two codes, every opening in the log has an author and a role.
How the system picks a locker
Selection is not a matter of taking the first free number. The rule is configured for the site and usually takes several conditions into account at once:
- Size type — the smallest one that fits, so a large locker is not given to a small bag while large ones are in short supply
- Zone and height — lower rows are more accessible and can be reserved for those who need them
- Even wear — lockers are allocated in rotation rather than the same few being used ten times a day
- Working order — lockers with open events are excluded from selection
What to do about overstays
The site's rule determines what happens when the period has expired with belongings inside. The options differ, and they are chosen before go-live rather than at the moment of the first case.
- Surcharge — access is kept, but the locker can only be opened once the overdue time has been paid for
- Block — code access is closed and the locker is opened only by an employee
- Removal — after a set period the belongings are moved to a designated place and the locker returns to circulation; the removal itself is recorded as a separate entry with an author
In every option the person is warned before the period ends, not after a penalty has been charged.
Payment for storage
where storage is paid
Not everyone needs a payment module: employee lockers and cloakroom compartments in a club work without money at all. But wherever a locker is rented out, money becomes part of the session, and the calculation rules have to be defined as strictly as the access rules.
How the cost is calculated. The tariff is tied to the locker size type and to time. The most common schemes are: a fixed price per session, a price per interval (hour, day) rounded up, a stepped tariff where the first hour costs more than the following ones, and a long-term subscription.
When payment happens. This is a project decision too. Paying up front for a chosen interval with a surcharge on extension is the simplest and most predictable scheme for the site. Paying afterwards, on completion of the session, requires a guarantee that the person will pay — a pre-authorization hold on the card, for example.
What belongs to the payment part of the system:
- Tariffs — by size type, site, time of day and day of the week
- Calculating the amount — from the actual session duration, with rounding rules
- Extension — a surcharge for an additional interval without ending the session
- Overstay — a separate tariff for time beyond what was paid for
- Refund — when a locker fails to be allocated the money is refunded rather than staying with the site
- The link between payment and session — two-way: the session shows the payment, the payment shows the locker and the time
- Reconciliation — daily matching of operations against the payment service's register
We state the boundary plainly. The specific payment methods — card, contactless, QR, payment in the app, cash through a bill acceptor — depend on the connected payment service and on the equipment on the cabinet. This is an integration whose scope is determined during discovery, not a built-in function available in every project. Fiscal requirements are set by the country's legislation and by the device model.
Calculating one session
- First hour, medium size type120
- Following hours, 4 × 60240
- A partial hour rounded up to a full oneincluded
- Paid when the locker was allocated, 2 hours−180
- Surcharge on completion of the session180
The rounding rule is announced to the person before payment rather than discovered in the final amount. It is the one line of the calculation that causes disputes at sites.
When payment and opening diverge
There is one dangerous scenario: the money is charged and the locker does not open. The system does not treat such an operation as completed — the session does not start, the locker stays free, and the payment goes into the refund queue with the reason stated.
The reverse situation — the locker opened but the payment was not confirmed — is handled just as strictly: the session is created but flagged as unpaid and lands on the investigation list. The system cannot quietly overlook a discrepancy, otherwise by the end of the month nothing will add up.
Notifications and the event log
An event is any change the system is obliged to remember: an opening, a refusal, the end of a period, an employee action. Some events go out to people as messages; all of them without exception land in the log. The delivery channels — the app, a message to a phone, email, a messenger — are connected through integrations and chosen during rollout.
To the user: access
The access code, the locker number, the site address and the storage period. Sent at the moment of allocation and again on request if the code is lost.
To the user: the deadline
A reminder before the paid time runs out, with the option to extend, and a separate message when the session goes overdue.
To the user: handover
A message to the recipient that the item has been dropped off and the locker is waiting, and a confirmation back to the sender that the item was collected.
To the employee: equipment
A locker did not open, a door was not closed, a cabinet is offline, a controller returned an error. The event is addressed: it has a site and a responsible person.
To the employee: overstays
The list of lockers whose storage period has expired, with the session start time and a way of contacting the person if one was left.
To the employee: investigation
An opening without a command, a run of failed code entries, a manual opening by an employee, a mismatch between payment and allocation.
| Time | Event | Grounds | Outcome |
|---|---|---|---|
| 14:05 | Locker no. 27 allocated | Session 8842, medium size type | success |
| 14:06 | Door closed | Door sensor | success |
| 16:40 | Opened by code | Session 8842, QR code | success |
| 16:47 | Door open longer than allowed | Door sensor, 6 min | event |
| 18:20 | End-of-period notification | The 40 minutes before rule | delivered |
| 18:49 | Access refused | Code entered incorrectly, attempt 2 of 5 | refused |
| 18:52 | Session closed | Confirmation on the screen, surcharge 180 | success |
| 19:14 | Service opening | Attendant Asanov, reason locker cleaning | manual |
A screen from the system; the data is illustrative. Note the 18:49 line: a failed entry attempt is an event too. A log that records only successes is no use for resolving a dispute, because refusals and manual openings are exactly what such disputes are about.
Administrator
employee roles and rights
The admin panel is a workplace, not a settings screen. Most of the time an employee is looking at two things: what is happening with the lockers right now and what needs their intervention.
What is on the first screen: a map of cabinets with occupancy by size type, a list of open events by urgency, overdue lockers, lockers taken out of circulation. Not the full list of lockers one after another — otherwise at a site with two hundred lockers the first screen is useless.
What the administrator can do:
- Open a locker manually — with a mandatory reason that goes into the log together with the employee's name
- Extend or close a session — when the person cannot do it themselves
- Reissue a code — against an existing session, without creating a new one
- Block a locker — take it out of circulation for cleaning, repair or an operational task
- Resolve an event — record what was checked, what was found and how it ended
- Change tariffs and rules — if the role holds that right; the change is recorded with its author and time
Rights are granted by role, not to a person. At a site with three employees the difference is invisible, but as soon as there are twenty, individual settings stop being auditable: nobody can say who currently holds the right to open other people's lockers. A role answers that question in one line.
- See occupancy and events at your own siteattendantBasic access: without it an employee cannot work a shift
- Reissue a code against a sessionattendantThe most common support operation; recorded in the session log
- Open a locker manuallyattendant, with a reasonA reason is mandatory and picked from a list; the system will not process an opening without one
- Close someone else's session earlysite administratorNot available to an attendant: this ends a paid service rather than helping a visitor
- Remove belongings from an overdue lockersite administratorA separate right with a mandatory note on where the contents were moved to
- Change tariffs and storage rulesmanagerThe change takes effect from a stated date and is stored together with the previous value
- Grant rights to other employeesmanagerA right that cannot be granted to oneself: role assignment always comes from above
- See users' personal dataa separate rightNot part of any role by default and granted individually, with a justification
The last two lines are not over-caution. The right to grant rights and the right to see personal data bypass every other restriction, so they are always kept separate rather than bundled into an administrator package.
Several sites in one panel
When the cabinets stand at a single site, a list is enough. When there are ten sites, everything a single location never faces appears.
- Grouping — by site, zone, cabinet type and responsible person, with its own summary for each group
- Its own addressee — an event goes to the attendant at the site where it arose rather than into a shared list
- Escalation — an event nobody picked up within the allotted time goes to the next person in the chain
- Comparing sites — where utilization is higher, where overstays are more frequent, where equipment fails more often
- Shared reference data — tariffs and rules are defined once and applied to a group of sites
What an employee sees about a person
Exactly as much as the job requires: session number, locker, time, access method, payment status. Contact details, if they were collected, are shown under a separate right and with an entry in the log — the act of viewing is an event too.
What data is collected about a user is a project decision, and it is determined by the site's requirements and by legislation rather than by what the system can do. A scenario in which nothing is stored about a person beyond the locker number and the time is workable and often sufficient.
Equipment health
monitoring
A cabinet stands unattended, and that is its defining property. Which means the system has to learn about a fault by itself — otherwise it will be reported by a visitor whose locker with their belongings did not open.
What is monitored continuously:
- Connection to the cabinet — whether the controller checks in on time or stays silent longer than the permitted interval
- Lock response — whether the locker opens on command and whether the sensor confirms the result
- Door position — closed, open, open longer than allowed, opened without a command
- Power — whether there is power at the cabinet and at what moment it was lost
- Peripherals — whether the scanner, the screen, the card reader and the payment unit are working
- Controller errors — the codes it reports itself, where the model provides for that
Silence is an event too. A cabinet that is not coming online does not mean all is well: it means nothing is known about the state of two hundred lockers and the belongings inside them. That is why a loss of connection creates the same kind of event as a lock failure instead of leaving a gap in the monitoring.
What happens to a faulty locker. It is automatically removed from selection: it will not be offered to the next person. A task is created for the service team with the cabinet number, the locker number and a description of the failure. The locker can only be returned to circulation by a note that the work is done — it does not recover on its own.
The approach to equipment monitoring is the same one we use in IoT monitoringsystems: an indicator, a norm, a hold time, an event, a responsible person. The only difference is that what is measured here is not temperature but lock response and connectivity.
Not every deviation is an emergency
There are three levels, and the level determines who the system disturbs and how quickly.
- Note — written to the history, disturbs nobody: a short response delay, a single failed code entry
- Event — requires a response, but not an urgent one: a door open longer than allowed, one locker not responding, a locker overdue
- Emergency — the cabinet is offline, power is lost, a group of locks has failed: a message goes out immediately and to several employees
The hold time — how long the system waits before raising an alarm — is set for each event type. Without it, cleaning the hall and routine servicing turn into a stream of false messages that people stop reading.
Availability report
For any period you can see, for each cabinet, how long it was online, how many lockers stood out of circulation and for how long, and how many failures fell on each locker. These figures answer a practical question: which lockers are due for replacement and which cabinet stands in a spot where the connection does not hold.
Locks and controllers
Code and card access
Administration panel
A log of every opening
Security
of access and data
Security in a system like this is not made of one measure but of several simple rules, each of which closes off a different way of getting into someone else's locker.
A code is valid within limits. Every code has a term, a locker and a number of permitted uses. A code that never expires and works on any locker is not a key but a skeleton key, so the system does not allow that state even for employees.
Codes cannot be brute-forced. The number of entry attempts is limited, entry is blocked for a while once they are used up, and a run of failures becomes an event for investigation. Without this a four-digit PIN can be guessed in an evening.
The server makes the decision. The cabinet controller does not store codes and does not decide who to let in — it carries out a command. That is why access to the equipment does not give access to the lockers, and revoking a code takes effect instantly.
Every opening is recorded. The log is immutable: a record cannot be edited or deleted, and a correction is entered as a new record. This applies to employees too — a service opening appears in a locker's history alongside an ordinary one.
Rights are separated. Viewing, manual opening, changing rules and working with personal data are different rights. A single account that can do everything is the one point of failure for the entire protection scheme.
What the system is not responsible for. It controls access but does not replace physical security: the strength of the cabinet, video surveillance in the area, staff procedures and the rules for storing valuables remain the site's responsibility. It is more honest to say so plainly than to leave the impression that software turns a cabinet into a fireproof safe.
What goes into the investigation queue
- A run of failed entries — several wrong codes in a row on one cabinet within a short interval
- An opening without a command — the sensor reported a door opening that the system did not initiate
- Payment without allocation and allocation without payment — a mismatch between the two flows for one session
- Frequent manual openings — one employee opens other people's lockers noticeably more often than the rest
- A reissued code — a code for one session was issued several times in a row
None of these events means a violation on its own: honest people mistype codes too, and lockers are opened manually for a dozen legitimate reasons. The point of the queue is that such cases do not dissolve into the general log but gather in a separate list that someone reviews regularly.
Personal data
What data is held about a user is determined by the site's scenario. One-off storage can manage without any of it — just the locker, the time and the code. A subscription requires an account. Corporate lockers are linked to the HR system. The less data is collected, the less of it has to be protected, so the scope is discussed before development rather than expanded just in case.
Integrations and APIs
A storage system rarely lives on its own: it stands inside a site that already has its own software. The exchange is built through an API — an external interface another system can use to allocate a locker, get a code, check a state or pull the log. Below are the exchange directions that come up most often.
Our own API
The basic way to connect: allocate a locker, issue and revoke a code, check occupancy, close a session, pull events. Everything else connects through it, including the customer's internal services.
The site's pass system
Where people already carry cards: the locker opens with the same pass as the turnstile. It requires agreement on the card type and on the interface the existing access control system exposes.
HR and accounting systems
For corporate lockers: an employee is hired and a locker is assigned; they leave and access is withdrawn and the locker freed. Otherwise within a year half the lockers are registered to people who are no longer on site.
Payment services
Accepting payment, refunds, reconciling operations. The specific provider and payment methods are determined by the project, and the fiscal requirements by the country's legislation and the equipment model.
Notification channels
Delivering messages to users and employees: the app, messages to a phone, messengers, email. A channel is connected separately and chosen per site.
Online store and delivery
The scenario of handing over orders through a locker: the order arrives from outside, a locker is assigned, and codes go out to the sender and the recipient. This layer is covered in detail on the self-service systems page.
Equipment monitoring
Passing cabinet and lock states to an external monitoring system where the site already has one, or using our own layer IoT monitoring.
Bookkeeping and reporting
Exporting data on paid sessions and payments to the accounting system. There is only ever one owner of the tariff reference data — either the accounting system or the storage system, but never both at once.
Data export
Regular delivery of the log and the indicators to the customer's data store or reporting system — for when site analytics is built inside the company's shared layer rather than separately.
We do not state a specific list of integrations in advance: whether an exchange is possible depends on the interface the system on the customer's side exposes. What connects immediately, what will require work on the other side and what will have to be handled by file exports becomes clear during discovery — before work begins, not along the way.
Where such systems are used
The equipment and the logic are the same everywhere: a locker, a lock, a code, a session, a log. What differs is the scenario, the storage period and whether the service is paid — and the differences in configuration come from exactly those three things.
Shopping centers
One-off storage for a few hours: purchases, strollers, bulky items. The footfall is high and the visitors are random, so what is needed is simple code access, fast allocation and a firm rule that lockers return to circulation by closing time.
Railway stations and transport hubs
Classic left-luggage storage: baggage for a few hours or days, charged by time, operating around the clock. What matters most here is reliable offline operation and a clear overstay rule — people miss their transport.
Fitness clubs and swimming pools
A locker for the duration of a workout, most often free and opened with a club card. The value of the system is not in payment but in the administrator being able to see which lockers are in use and open a forgotten one without breaking the lock.
Offices and coworking spaces
A personal locker for an employee or a resident: an assigned locker, access by pass, a term set by contract. The link to the HR system removes the main problem — lockers still assigned to people who have left.
Business centers
Lockers for tenants and visitors, handing documents and keys between companies without meeting. This is where the two-code scenario — one for drop-off, one for collection — is needed most often.
Self-storage facilities
Storage rooms rented by the month: a long session, payment by subscription, access by card or code. The software side handles the term, extensions, blocking on non-payment and the visit history.
Manufacturing plants and warehouses
Lockers for tools, instruments and workwear. The point is not payment but accountability: who took what, when they returned it, what has not come back by the end of the shift. Here the log is the system's main output.
Educational institutions and libraries
Lockers for students and visitors, issuing and receiving books and equipment through a locker. What is usually needed is a link to the existing system that tracks people rather than a separate user directory.
Medical and government institutions
Lockers for visitors in the waiting area and staff lockers. The requirements for the log and for the separation of rights are higher than usual here, while the range of data collected is kept to a minimum.
Analytics
and reporting
The system accumulates a lot of data, but only a little of it is useful. Four questions have practical value: are there enough lockers, which sizes are needed, where is time being lost and which equipment is due for servicing.
What utilization shows. Not an average figure for the month but the distribution across hours and days: a site can be 45% utilized on average and still have not a single small locker free every Saturday between 14:00 and 18:00. The answer is to add lockers of the right size, not another whole cabinet.
The indicators calculated per site:
- Utilization — the share of occupied lockers by hour, day of the week and size type
- Turnover — how many sessions pass through one locker over a period
- Average session duration — separately by size type and by day of the week
- Failed allocations — how many times a person did not get a locker because none of the right size was free
- Overstays — the share of sessions that ran past their term and how long they held the locker
- Equipment availability — how long lockers stood out of circulation and for what reason
- Revenue — where storage is paid: by site, size type and period
A failed allocation is the most underrated indicator. Occupancy is visible to everyone, but the person who walked up, found no free locker and left leaves no trace in ordinary statistics at all. And yet it is exactly that number which answers the question of whether the cabinet needs extending.
Reports export to a file and can be built on a schedule — on the first of every month across all sites at once, for example.
Utilization by hour
Two hours of full occupancy on the chart do not mean nicely utilized — they mean a queue and refusals. This indicator always sits next to the number of people who left without a locker; otherwise the peak reads as a success.
What these figures give you in practice
- How many lockers to add and of which kind — from the refusals and from utilization broken down by size type, not from a general impression
- Whether the tariff should change — if lockers are held for eight hours, the tariff is not restraining turnover but encouraging it
- Where a second cabinet is needed — a comparison of sites by refusals and peak utilization
- Which lockers to replace — from the number of equipment failures on a specific locker over a period
Implementation sequence
The stages come in exactly this order. Skipping discovery is the most common reason a system ends up built around equipment that does not accept the commands it needs.
1. Discovery
What is already on site: cabinets, locks, controllers, readers, connectivity, power. Which scenarios are needed, whether storage is paid, who is responsible for the lockers. The output is what connects immediately, what requires work and what the site is missing.
2. A pilot on one cabinet
One cabinet end to end: exchange with the controller on live equipment, verification of openings and sensors, tuning of terms, tariffs and rules against how people actually behave rather than against the documentation.
3. Rules and roles
Who is responsible for which sites, which events go to whom, what counts as an emergency, how overstays are handled. Employee rights and the procedure for manual openings are configured here as well.
4. Rollout
The remaining cabinets and sites follow the proven pattern, and new equipment types come as separate exchange modules. From there the history accumulates, and period reports and data for expansion appear.
Our Clients
Let us discuss your storage system
Contact us today
Tell us what kind of site it is, how many lockers you have and which cabinets are already installed, whether storage is paid and who will be working with the system. We will tell you what can be connected to the existing equipment, which access scenarios would suit and where it makes sense to start the pilot.
