When the Hotel Spreadsheet Becomes Infrastructure
There's a specific kind of spreadsheet in every hotel management company. It started as a quick fix for something that didn't have a better home. Someone built it over a weekend, shared it with the team, and it worked well enough that people started relying on it. Then they started relying on it every day. Now it's three years old, nobody fully understands it, and the business couldn't start the morning without it.
How it happens
The origin story is almost always the same. A revenue manager or operations director needed a view that didn't exist in the PMS or RMS. They built it in Google Sheets because that was the fastest option available. They made it exactly the way the team needed it — specific columns, specific calculations, specific formatting. The team liked it. Leadership started asking for it. It got added to the morning distribution list. It became the thing everyone looked at.
Over time, it acquired layers. Someone added a tab for the rate shop notes. Someone else added a comparison to last year. A regional director asked for a subtotal row by cluster. An owner wanted to see the budget variance in red when it was below minus ten percent. Each addition made sense when it was made. Taken together, they turned a simple shared view into something that requires a specific person's institutional knowledge to maintain.
The sheet became infrastructure without anyone deciding it should. That's both its strength and its problem.
Why this is actually fine — up to a point
I want to be clear about something: a spreadsheet that becomes infrastructure isn't automatically a problem. A lot of hotel companies are running real, successful operations on top of Google Sheets that would make a software engineer wince. The sheet works. The team uses it. The decisions get made.
The issue isn't the spreadsheet. The issue is what the spreadsheet depends on to stay current. If the answer is "one person, manually, every morning," then you have a fragile system dressed up as a reliable one. The sheet looks like infrastructure. It acts like infrastructure. But it has a single point of failure with a name and a job title.
The test for infrastructure is: what happens when the person who maintains it is unavailable? Real infrastructure keeps working. A spreadsheet that requires a person to build it every morning is not infrastructure — it's a recurring task that produces something that looks like infrastructure.
The signals that the sheet has become a liability
If a new revenue manager or ops director joined tomorrow, how long would it take them to understand how the sheet is built and why? If the answer is "weeks" or "they'd have to ask [specific person]," the knowledge is dangerously concentrated.
Manual assembly produces silent errors. A formula that's off by one row, a paste that landed in the wrong column, a date that rolled over correctly but left a stale figure in the comparison. If the sheet has produced wrong data that went unnoticed, the team's trust in it is more fragile than it looks.
If everyone except one person is implicitly banned from editing it because edits break things, that's a signal that the sheet's complexity has outgrown the team's ability to maintain it collectively.
Usually framed as "we should really clean this up sometime" — which means the person closest to it already knows it's more complicated than it needs to be and hasn't had the time or mandate to fix it.
If covering the morning report during a vacation requires a written set of instructions or a training session, the process has more complexity than it should. A well-automated workflow doesn't need a handoff document — it just runs.
What to do about it
The wrong answer is to replace the spreadsheet. The team uses it because it works for them. It shows the information in the format they understand. The right answer is to separate the spreadsheet's structure — which is fine — from its dependency on manual data entry — which is the fragile part.
In practice, this means building an automation layer that handles the data collection and population, while leaving the sheet itself exactly as it is. The PMS export still feeds the same cells. The rate shop data still lands in the same tab. The pickup calculations still use the same formulas. The only thing that changes is that those inputs arrive automatically instead of being pasted in by hand.
The sheet that's been running the company's morning for three years usually doesn't need to be rebuilt. It needs the data it depends on to arrive without requiring a person to deliver it. That's a much smaller problem than it sounds, and it's almost always the right starting point for an automation project.
The team keeps using the thing they already trust. They just stop being the ones who have to build it every day.
← Back to all postsGot a spreadsheet like this in your morning workflow?
The report stack mapper helps document what the sheet depends on, where the data comes from, and what gets updated manually — which is the starting point for figuring out what can be automated without touching the format the team already uses.