Cost, Sequence & Decisions

Cost shape

You chose architecture-first, and vendor pricing above roughly 50 units is quote-gated across this entire category — Guesty, AirDNA Enterprise, Key Data, Breezeway and Lighthouse all move to sales-led pricing at your scale. So what follows is the shape of each cost, which is what you need to negotiate and compare, plus the questions that actually move a quote.

The honest summary: software is not the expensive part. Engineering time is. Which is the real argument for the build order in Chapter 7 — each module must pay for itself before the next starts.

Three questions that change quotes more than negotiation does: what is the per-unit price at 200 units and at 1,000? — is there an API-only tier without the automation layer? — what does exit look like, and can we export full history?

What each module returns

Framed as labour and revenue rather than features, because that is the basis for deciding what to fund next.

Two of these compound. The audit log from the co-pilot is what eventually permits autonomy. The task history from the engine is what makes the pattern engine worth reading. Neither pays off in month one, and both are why the order matters.

Milestones worth calling done

• M1 — the spine breathes. Reservations from the PMS land in your own model, reconcile nightly, and every discrepancy is logged. Nothing user-facing. This is the only milestone with no visible output and it is the most important.
• M2 — the first number. A pricing recommendation with visible comp evidence, approved by a human, pushed to a channel. Management sees current / market / recommended for the first time.
• M3 — the group chat goes quiet. Cleaners receive tomorrow's schedule in LINE without anyone typing it, and complete it with photos. Measure success by what stops happening.
• M4 — the loop closes. A guest reports a problem; one approval sends the reply and creates the task; the technician resolves it in LINE; a follow-up message is drafted. End to end, in Japanese, with an audit trail.
• M5 — the empty screen. Inventory recommendations appear only when something needs ordering, and are usually right.
• M6 — the morning digest. Five things, on your phone, at 7am, correct.
• M7 — the first weekly pattern that surprises you. The point at which the system starts earning more than it costs.

Graduating to autonomy

You said you would prefer recommendation-with-approval initially, and that autonomy could follow if accuracy proves out. Make that promotion a rule rather than a feeling, per intent, in this order:

1. Pricing, downward within floors, far from arrival. Lowest consequence, easily reversed, and the floor is a hard stop.
2. Routine informational replies, one intent at a time. Wi-Fi, check-out time, bin day. Never access codes, never policy, never money.
3. Routine purchase orders below a value threshold with a known supplier and a stable consumption history.
4. Task assignment by rota where the rota is unambiguous.

The gate for each: sustained agreement above roughly 85–90% between recommendation and human decision, over a meaningful volume (thousands of messages, hundreds of rate decisions), with zero severe incidents in that intent, measured from the audit log — not from impression. And every autonomous action stays reversible and logged, with a kill switch per intent that anyone in ops can pull.

Two things never graduate: access credentials and anything involving money to or from a guest. Not because the model cannot do it, but because the downside is unbounded and the upside is a few seconds.

Open questions

These are genuinely open and shape the plan materially. They are the agenda for the call.

Structural

1. Personal (~200 units) and company (~1,000 units) on one platform or two? One is cheaper and simpler; two may be required by entity structure. This is the first fork.
2. Is the operations layer a cost centre or a product? If the company's 1,000 units and eventually third-party owners use it, that changes multi-tenancy, access control and support expectations from day one. It is much cheaper to design for now than to retrofit.
3. Japanese domestic OTAs in the next 12 months? Jalan and Rakuten Travel bring Temairazu or NEPPAN into scope.
4. Does marketing sit inside this system? You mentioned the fee assumes marketing on top. Direct-booking acquisition implies consented guest lists, an email platform and attribution — adjacent to this plan, not inside it, but it shares the guest record.

Operational 5. Who owns this internally? A build like this needs one ops-side owner who decides what "done" means. Without that person, engineering makes product decisions by default. 6. Approval coverage hours — and whether Japan and Bali cover each other's nights. With two regions this is a structural advantage most operators do not have. 7. Who verifies cleaning — manager review or trusted self-verification with spot checks? Determines how much management time the system consumes. 8. Rate floors and ceilings per unit — who sets them, reviewed how often?

Commercial 9. What does SMARTORDER actually expose? The written answer to Chapter 5's questions makes or breaks the migration decision. 10. What is the honest current cost of the repetition? Rough hours per week on guest messages, on cleaning coordination, on stock runs. Not for a business case — to prioritise correctly, because whichever of those is largest should probably move ahead of the others.

The first two weeks

Nothing here needs a decision about anything above.

1. Send the SMARTORDER questions in writing. Five questions, from Chapter 5. Everything downstream waits on the answers.
2. Open trials with Hostex and Hostaway. Three to five real units each, split Japan and Bali. Test webhook fidelity on a real booking, not the marketing site.
3. Trial PriceLabs on six units — three Japan, three Bali. The only question that matters: does the comp set it returns look like your actual competitors?
4. Start the property knowledge base. One structured document per unit. This is the critical path for the highest-value module and it needs an ops person, not an engineer.
5. Export your guest message history from every channel that allows it. Your archive is the most valuable proprietary asset in this plan.
6. Start snapshotting your own on-books and rates nightly, even into a spreadsheet. Pace data cannot be reconstructed later.
7. Write down the standard turnover kit per unit type. Two hours; unblocks all of inventory.
8. Count your repetition for one week. Rough hours on guest messages, cleaning coordination, stock. It will change the order of what gets built.

Items 4 to 8 cost no money and no engineering, and they are the difference between starting the build in week one and starting it in month three.

For the call

The three things worth deciding together, because they cascade:

• The PMS, since guest messaging, task generation and inventory forecasting all depend on it, and Airbnb message access is the gating requirement.
• The build order, and specifically whether pricing genuinely goes first. The argument for it is that it is risk-free and visible; the argument against is that guest communication is where your pain is. If your week of counting says guest messages dominate, invert them — but keep the spine first either way.
• Scope: personal, or personal plus company. It changes the platform choice, the multi-tenancy question, and roughly the size of everything.

Everything else in this handbook is a recommendation you can take or leave module by module. Those three are structural.