1
The final report or morning view.
Bring the thing the team actually uses: spreadsheet, email, PDF, dashboard screenshot, or rough notes. The output tells us what the workflow is trying to become.
Before the workflow review
Bring the messy version. That is the useful version.
A good hotel reporting workflow review does not need a polished deck. It needs the real sources, the real handoffs, the real spreadsheet, and a clear sense of what the team wishes showed up automatically every morning.
What to bring if you want the review to be useful.
This is the fastest way to turn "we do a lot manually" into a scoped pilot with a real output.
2
The source reports that feed it.
PMS exports, rate shop files, forecast reports, channel reports, pickup snapshots, accounting files, or anything that gets copied into the final view.
3
The manual steps nobody writes down.
Renaming files, cleaning columns, copying tabs, checking formulas, moving files into folders, emailing GMs, and the "I just know to check this" parts.
4
The timing and owner.
Who builds it, how often, when it needs to be ready, who reads it, and what breaks when the owner is busy, traveling, or out sick.
5
The decision the report is supposed to support.
Rate action, pickup review, occupancy risk, forecast gap, exception routing, GM follow-up, ownership summary, or another recurring operating decision.
6
The first win that would make the team care.
One clean daily email, one updated Google Sheet, one exception view, one folder of finished files, or one multi-property summary that arrives without manual assembly.
Four questions that reveal the most about reliability risk.
These come up in every useful workflow review. Worth thinking about before the call — even rough answers surface the part of the workflow that breaks first.
A
What happens when a source report doesn't arrive?
Does the brief go out late? Does someone manually pull a backup? Does it go out with yesterday's numbers and nobody notices? There is usually an answer — it just hasn't been written down.
B
Has the brief ever shown data from the wrong date?
The business date in the report versus the date the file arrived are often different — and most manual workflows don't check. If this has happened and went unnoticed for a day or more, that's worth knowing.
C
If an input is missing, does the output go blank or stay stale?
Stale numbers that look current are the worst failure mode — the team trusts the brief and the brief is wrong. Blank cells are obvious. Stale cells are invisible.
D
Who checks that the automation ran correctly before the team reads it?
For some teams the answer is nobody — the brief goes out and someone catches errors at the standup. For others there's a quick scan. Either way, understanding this shapes how much reliability infrastructure the first pilot needs.
If you want to send something before the call, use this.
No need to overthink it. The rough version is better than the corporate version.
Hi Chandler, I want to review a hotel reporting workflow. Company: Portfolio size: Workflow/report: Who builds it today: Who uses the output: How often it runs: Source reports involved: What is manual today: What the finished output should look like: What would make this worth automating first: Reliability notes (optional but useful): - What happens when a source report doesn't arrive on time: - Whether the brief has ever shown data from the wrong date: - What the output does when an input is missing (blanks / stays stale / other): I can send screenshots, sample exports, or walk through it live.
Prefer email? Start with the template.
The mail link opens a prefilled note. Add whatever context you have and attach examples if they are safe to share.
The point is not to make the workflow look good. It is to make it legible.
Once the workflow is legible, the first pilot usually becomes obvious: remove the manual assembly between the source reports and the morning operating view.