Trust
Clear boundaries, recorded decisions, data kept where it belongs.
StowOS works close to money, customer records and safety evidence. You should know exactly what it can touch, what it cannot, and how you would find out what it did. This page sets that out plainly.
01System boundaries
What StowOS can do, and what it cannot.
StowOS can
- Read the records your PMS holds about leads, customers, agreements, payments and units
- Create actions, jobs and exceptions from those records and from what your team logs
- Write back new web leads, lead status and approved rates, in areas you have switched on
- Store photographs and documents your team attaches as evidence
StowOS cannot
- Take or refund payments, or change what a customer has been invoiced
- Change a rate without a rule you configured or a named person's approval
- Show one operator's data to another
- Delete history: closed and withdrawn work is kept with its reason
02Data
Where your data lives and who can reach it.
- Hosted in the United Kingdom
- The StowOS database and file storage run in the London region. Connections are encrypted in transit and data is encrypted at rest by the hosting platform.
- Isolated at the database, not just the screen
- Every table carries row-level security that restricts each record to its own organisation, and database functions are denied public access by default and granted back only where needed. Isolation does not rely on the interface behaving correctly.
- Evidence kept private
- Photographs and documents are stored in a private bucket and served through short-lived signed links to signed-in users, never as public URLs.
- A deliberately small public surface
- Where a public website needs pricing or submits enquiries, it reads a purpose-built projection holding only publishable fields, and writes through a single validated endpoint. Internal views are never exposed.
03Access and accountability
Authority is configured. Actions are attributed.
Four roles, configured per organisation
Director, manager, staff and maintenance. Which pages and actions each role may use is held as configuration that a director can change, and the same permissions are enforced by the database.
People are invited, not self-registered
Accounts are created by invitation from a director; there is no public sign-up. When someone leaves, their access is withdrawn and their history stays attributed to them.
Every change is attributable
Outcomes, approvals, overrides, automatic changes and writebacks are recorded with who or what made them, when, and the rule or reason behind them.
04Writeback safety
Changes to your PMS are few, permitted and checked.
Writeback is off until you switch it on, and it is switched on by area. When it runs, every change goes through one outbound gateway that queues requests, respects the PMS’s limits and retries failures, so a busy morning or a PMS outage does not lose an update.
After a change is written, StowOS reads the PMS again to confirm it holds what was intended. If it does not — or if someone later changes the value directly in the PMS — an exception is raised for a person to resolve. StowOS does not quietly overwrite what it finds.
Security questionnaires and data processing
If your organisation needs a security questionnaire answered or a data processing agreement in place before connecting customer data, ask during your walkthrough. We answer in writing, and we will tell you plainly if something you need is not yet in place.
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.