Case study · Property operations
A multi-property operator was running its month on manual entry. Information lived in whatever file the person who created it chose. Issues raised in the field went into a conversation and were missed. Seven systems now carry that work, and a five-person team runs the operation on them without a technical specialist.
The situation
Every system required someone to type into it. That is workable at one property and becomes the whole job at several. What made it worse was that the information was disorganized once it arrived, so the effort of entering it did not produce anything that could be looked up later. There was no durable record that anyone could reach when they needed it.
The clearest symptom was what happened to problems. An issue noticed at a property went into a message or a conversation, which is not a place that holds anything. Some were missed. Some were raised and never resolved, and nobody could say which, because there was no list to check against.
Setting up a new property was the same problem in concentrated form. It meant creating several trackers by hand, one at a time, in the right shape. Hand-built trackers did not always match what the automations expected, so the setup itself broke the things that were supposed to run afterward. The resulting files were spread across multiple drives, which meant the record of a property was wherever the person who set it up had put it.
What I built
A property directory holds the record every other system resolves against, and an employee web application runs the setup. Adding a property is now one guided process that creates the trackers and forms that property requires. The automations get the shape they expect, because the shape is generated rather than recreated by hand.
A master consumable catalog holds what is stocked. Change an item there and the change flows downstream into each property tracker. Seasonal inventory turns over every quarter, so this is a scheduled event rather than a rare one, and it stopped being a per-property editing job.
This began as a plain spreadsheet and picked up automations as it earned them. The master tracker was then built alongside the property directory and the consumable catalog rather than after them, so the three were designed to fit.
A master linen tracker orders against set inventory levels, so replenishment is triggered by the level rather than by somebody noticing. A master linen catalog holds the approved item list and is changed as availability and product tier change, without touching the individual property trackers.
The consumables inspection runs as a web application opened from a durable QR code at the property. It works offline once loaded, stages drafts on the device, requires a photograph against each of 28 governed items, and asks for sign-in only at submission. Repeated sends are made idempotent, so a retry cannot create a second record.
Bank-statement import and receipt reading, with a quality gate that blocks submission when the record does not hold up. The check happens before the month closes rather than during the review of it.
A turnover and issue tracker and an authenticated employee portal tie the rest together. The portal is live behind Workspace sign-in, and its protected interfaces fail closed to anonymous requests. The tracker reports on a schedule by email rather than waiting to be checked, and it names the specific things that are still open: an issue that gates a guest occupying a property, or stock that needs replenishing before it runs out.
What changed
Adding a property is one process. It was several manual builds that had to be done in the right order and in the right shape. It is now a guided setup that produces both, which also removed the failure where a hand-built tracker quietly broke an automation downstream.
A property’s records are in one place by construction. Not because people were asked to file consistently, but because the system that creates them decides where they go.
A change to what is stocked is made once. The catalog sits upstream of every property tracker, so the quarterly seasonal turnover is one edit rather than one edit per property.
Replenishment answers to inventory levels. Linen purchasing is triggered by the level being reached rather than by a person noticing that it was.
Issues have somewhere to land, and the record comes looking for you. An issue goes to a tracker with a durable record attached, so it stays visible until it is closed instead of ending in a conversation nobody can search. The reports do not wait to be opened: they go out by email and name what is still unresolved, including an open issue that gates a guest occupying a property and inventory that needs replenishing before it runs out. Something that would stop an arrival gets raised before the arrival rather than discovered at it.
Whole classes of error stopped being available. A generated tracker cannot be the wrong shape for the automation reading it. A retried submission cannot create a second record, because submission is idempotent. An expense that fails the quality gate cannot be submitted at all. These are not fewer mistakes by people being more careful; they are mistakes the system no longer accepts.
The people who run it are not technical. Five of them run the operation on these systems. That is the actual test of whether something was built for an operation or for its builder.
Stated as an estimate: building one tracker by hand ran to more than two hours, and onboarding a new client to more than forty. Those are my considered estimates from having done the work, not measurements taken from a system. Nothing counted them, and I am not presenting them as counted.
In build now
A contract and onboarding system is in build. The goal is the one that has worked everywhere else here: a single guided setup that populates the forms, the property directory entry, and the contracts a new property needs, instead of assembling each of them separately and reconciling them afterward.
It is not in production, and nothing on this page depends on it.
Mapped to the method
The method
What is not claimed
The time figures above are estimates and are labelled as estimates wherever they appear. No system measured them. They sit apart from the counted figures on this page deliberately, because an estimate placed next to a count borrows credibility it did not earn.
The contract and onboarding system is in build and is described as such. The client is not named, which applies across this site.
Contact