Weekly occupancy and revenue reporting, assessed for automation.

The business

Both walkthroughs follow one unnamed hospitality group: it runs three boutique hotels and an event venue in the same city, with a shared back office. Bookings live in a property-management system, revenue in the point-of-sale, purchasing in supplier spreadsheets, and the team coordinates changes by email.

• Owner and manager: The group’s general manager, who owns the weekly report and the event policies the workflows are configured against.
• Team: Front-desk, kitchen, and events coordinators working across shifts — which is exactly why requests and figures get lost between desks.
• Systems involved: The shared inbox, the property-management system, the point-of-sale, the supplier spreadsheets, and the shared event calendar.

The workflow today

Every Friday, the group’s general manager publishes a weekly report on occupancy, rate, outlet revenue, and event follow-ups across the three hotels and the venue. Today the work is manual, spread across four people, and almost always finished against the clock — ahead of the weekend, when nobody has time to fix it.

The proposed workflow

The proposed workflow keeps the same people and the same decision rights, and replaces only the repetitive assembly: collection, completeness checks, drafting, and distribution become scheduled and recorded. Human approval stays in the middle of the flow.

Assessment dimensions

Each dimension below is reasoned on its own. There is no aggregate score — a workflow is judged by where it is strong, where it is conditional, and whether the preconditions in the next section are met.

1. Recurrence

   How often does this work happen?

   High — weekly and predictable

   The report runs on a fixed weekly cadence with a defined input set and a defined output. Recurrence is what makes a workflow worth automating at all.

2. Value

   What does automation save or improve?

   Moderate, compounding

   Assembly and reconciliation consume several hours of coordinator and manager time each week, and late reports delay rate and purchasing decisions. The value here is a hypothesis about time and reliability — not a measured result, because nothing has been measured yet.

3. Measurability

   Can we observe the outcome?

   Strong

   Success is visible and countable: report delivered on time, all sources included, no unapproved changes, follow-ups closed. Proposed measures are listed in the pilot section below; none are presented as achieved.

4. Data readiness

   Are the sources accessible and stable?

   Conditional

   The property-management system and the point-of-sale have stable, documented access. The purchasing spreadsheet currently depends on one person emailing it, so automation needs an approved access path or a replacement source before the pilot can cover it.

5. Integration effort

   How much work is required to connect?

   Low to moderate

   The connections are read-only and the workflow performs no writes to source systems. The main effort is mapping the purchasing spreadsheet and agreeing which fields are authoritative.

6. Action risk

   What could go wrong?

   Low

   The workflow does not contact guests, change bookings or rates, or move money. Every output is reviewed by a human before distribution, so the blast radius of a mistake is an internal draft, not a consequential action.

7. Change burden

   How much must the team change?

   Low

   Roles and ownership stay the same: properties still provide numbers and the general manager still approves the report. What changes is who assembles it — which is precisely the repetitive part.

8. Pilot suitability

   Is this a good first workflow?

   Strong candidate

   It is read-heavy, approval-gated, and low-risk, with an accountable owner. Suitability is a reasoned judgment across the dimensions above, not a weighted score — and it is conditional on the preconditions listed below.

Ownership and boundaries

Owner and trigger

• Owner: The group’s general manager, who owns the report, its distribution, and the follow-ups it raises.
• Trigger: A configured weekly schedule — collection Thursday, draft Friday morning, distribution after approval.

Systems and permissions

• Read-only: Property-management system, point-of-sale, and purchasing spreadsheet — metrics are pulled, never written.
• Write: Only the shared report folder, where the draft and the approved report are stored.
• Distribution: The existing distribution list, used only for the approved report.

Explicit exclusions

• No guest-facing messages of any kind.
• No changes to bookings, rates, or financial records.
• No writing to source systems, even to “clean up” data.
• No interpretation of what the numbers mean — that stays with the general manager.

Human checkpoints

• Data owners confirm or supply missing inputs (followed up by the agent).
• The general manager reviews and approves every draft before distribution.
• Action items are assigned to named owners by the manager, not by the agent.

Exceptions

• Business exception: A property disputes a KPI definition — how no-shows count against occupancy, for instance — or wants different figures. The customer decides; the agent pauses and waits for direction.
• Technical exception: A source system is unreachable or an export is malformed. Disponi owns monitoring, recovery, and communication; the report is marked incomplete rather than silently filled in.

Reasons to defer or reject this workflow

• KPI definitions are disputed and no one owns them.
• A required source has no approved access path and no replacement.
• There is no accountable process owner to approve drafts and own actions.
• The report is expected to make or authorize consequential decisions with no human gate — automation is deferred until a human checkpoint exists.

Pilot scope, acceptance, and recommendation

Pilot scope

A four-week, read-only pilot covering the property-management system and the point-of-sale. The pilot separates responsibilities clearly:

• The pilot does: Collect sources (read), run completeness checks, follow up on missing inputs (coordination), and assemble the draft (preparation).
• The pilot does not: Approve, distribute, or track actions. Approval and distribution stay fully manual, and no write is made to any source system.

Acceptance criteria

• Four consecutive weekly reports completed through the pilot flow.
• Every expected source collected on time at least 95% of the time.
• No unapproved change to any figure between collection and draft.
• The general manager recognizes every draft and approves it before distribution.
• No data is written to a source system, and no message is sent to a guest.

Measurement plan

The pilot would measure: source collection time, completeness rate, time from collection to approved draft, number of missing-input follow-ups, review time, and drafts needing correction. These are proposed measures for the pilot — none of them are achieved results, because the pilot has not run.

Conditional recommendation

Proceed with a four-week read-only pilot, on three conditions: the general manager formally owns the report and its follow-ups; the purchasing spreadsheet gets an approved access path (or a replacement); and a human approves every draft before distribution. If KPI definitions remain disputed or source access is not approved, defer. If the report’s role expands toward consequential action without a human gate, reject.

Why this comes before coordination

Reporting sits at the start of the progression: it observes and prepares, it is read-only, and every output is reviewed. A safe first deployment should be the least risky useful thing — which is why the workflow walkthrough shows a later stage, where the same group coordinates event and supplier-order changes with approval gates and bounded action. Not every customer follows this path, and Disponi does not claim otherwise.

1. ObserveRead-only workflows that collect and prepare information.
2. PrepareDrafts, checks, and follow-ups that stay inside the team.
3. Coordinate with approvalCross-system coordination that pauses for customer approval at consequential points.
4. Act within policyBounded, recorded actions inside rules the customer defines.

See the workflow walkthrough — the later, bounded stage →

The shared-operation boundary

The same responsibility model applies to every workflow: business judgment and final accountability stay with the customer; platform operation and technical incidents stay with Disponi.