How it works
From operational events to accountable action.
StowOS is built on one idea: the work a self-storage business needs to do is a consequence of what has happened, and it should change the moment what has happened changes.
This page explains the model underneath the product, what an action is, and how StowOS reads from and writes to the systems you already run.
01The model
Events become state. Rules turn state into consequences. Consequences are the actions.
- 01
Event
Something that happened, from any source: a lead created in the PMS, a payment, a web enquiry, a photograph from the site log, the clock passing a deadline.
Payment of £184.00 received on B-114
- 02
State
What is true now, built from every event so far. The customer's balance, the unit's condition, the lead's stage, who is on shift.
B-114 balance £0.00
- 03
Rules and context
Your policies, written down once: cadences, response times, evidence requirements, escalation paths, approval limits, site hours.
Chase balances over 14 days until cleared
- 04
Consequences
What the new state means under those rules: an action becomes necessary, stops being necessary, or needs someone more senior.
The rule no longer applies to B-114
- 05
Current actions
The work that needs doing now, each with an owner, a deadline and the reason it exists. Nothing more, nothing stale.
Chase on B-114 closed · reason: paid
The example running along the bottom is the whole idea in miniature. No one had to close the chase on B-114. The payment changed the state, the rule stopped applying, and the action closed itself with the reason recorded.
02An action’s life
A task is a note. An action is alive.
Task lists fail quietly: they fill with things that no longer matter and miss things that now do. Every StowOS action ends in a recorded state, and every state has a cause you can read afterwards.
| State | What causes it | For example |
|---|---|---|
| Open | A rule applies to the current state and someone owns the response. | Call back a lead quoted on Friday. |
| Done | The owner records an outcome, with evidence where the rule requires it — or an event proves the work is complete. | Fire door check closed with two photographs at 11:42. |
| Withdrawn | The reality that made the action necessary has gone away. It is closed with the reason, not deleted. | Callback withdrawn: the customer reserved online. |
| Superseded | A newer action replaces it, so nobody works from an out-of-date instruction. | ‘Send quote’ replaced by ‘Confirm viewing’ after the customer booked one. |
| Blocked | Something upstream prevents completion, and that blocker is itself an action with an owner. | Move-in prep blocked by damp reported in the unit. |
| Escalated | A deadline or threshold passed. The action moves to the next person in the line of authority. | Check not evidenced by 12:00, moved to the site manager. |
03The loop, layer by layer
Read, normalise, reason, act, write back.
Each layer has one job. That is what lets StowOS sit above a PMS without becoming tangled in it.
- 01
Read
Connectors take events from the PMS, website enquiry forms and the site log as they happen, and keep a faithful copy of what each source said.
Storman leads, reservations, agreements, payments, unit states and rates · web enquiries · staff-logged events with photographs
- 02
Normalise
Events are mapped to one vocabulary and matched to the right customer, unit and site. Duplicates — including the PMS echoing back something StowOS created — are recognised and merged.
Single lead record across sources · consistent status and outcome codes · per-organisation reference data
- 03
Reason
Rules and operating context are applied to the current state: cadences, priority profiles, response targets, evidence and escalation policies, pricing rules.
Rules are configuration, not code · pricing proposals recalculated on a schedule · every derived action records which rule produced it
- 04
Act
Actions appear on the surfaces where people work, filtered by role and site. People record outcomes; the outcome is itself an event, and the loop runs again.
Today · Leads · Jobs and checks · Site log · Decisions and screening · Approvals
- 05
Write back
Approved changes return to the PMS through a single outbound gateway that queues, rate-limits and retries, then checks the PMS agrees with what was intended.
Lead status and new leads · approved rates · mismatches raised as exceptions rather than silently overwritten
04Where people fit
StowOS works out what needs doing. People decide how.
Operational judgement stays with your team. StowOS removes the part of the job that is remembering, sorting and chasing — working out what is due, whose it is and whether it still matters — so that the judgement is spent on the customer in front of them.
Where automation is appropriate — closing a chase when a payment lands, withdrawing a callback when a customer reserves — it is written as a rule you can read, and every automatic change is recorded like a human one. Where it is not, such as a price change or a decision about a customer in arrears, StowOS prepares the decision and a named person makes it.
The result is a business that runs the same way on a Tuesday afternoon as it does when the owner is on site.
See your own operation in it.
A walkthrough is a conversation, not a pitch. Bring a real week — the enquiries, the move-outs, the maintenance — and we will show you where each piece would sit in StowOS, and be straight about where it would not.