Orientation

What this document is

This is an architecture handbook, not a product spec and not a sales pitch. It answers one question in six parts: what should actually get built, in what order, to reduce the repetitive human work of operating your properties — without breaking the things that must never break.

It is written against your stated position: roughly 15 units live or imminent under your personal portfolio, ~200 personal units planned, and a company portfolio heading toward ~1,000 units across Japan, Bali and residential. Two countries, two legal regimes, two languages on the guest side and three on the staff side, and an existing operation that runs on LINE plus a low-cost PMS called SMARTORDER.

Everything here is organised around one principle you already articulated, which happens to also be the correct engineering principle:

Collect → organise → recommend → human approves → act → record.

Full autonomy is the last step of each module, never the first. This is not timidity. A system that proposes and records is measurable; a system that acts silently is not. You cannot safely automate a decision you have not first watched a human make a few hundred times with the machine's suggestion sitting next to it.

The one-paragraph answer

Do not build a PMS. Do not try to get your own Airbnb or Booking.com API keys. Put your reservations on an API-first PMS/channel manager that already holds certified OTA connections, and build a thin operations layer of your own on top of it: a shared data spine, a guest-message co-pilot with approval, a task system delivered to staff through LINE, a pricing recommender that shows its evidence, an inventory forecaster driven by the booking calendar, and — last — a daily digest that reads across all of them. Buy reliability, build judgement.

Why in this order

You named guest communication as the top priority and market intelligence as "potentially the easiest place to start." Both are right, and they are not in conflict, because they depend on different things.

• Market intelligence needs almost nothing from your existing stack. It needs your own rates and occupancy (exportable by hand if necessary) and an external comp-data source. It can be built and proven in weeks, in read-only mode, with zero risk to the operation. It is the ideal first module precisely because it cannot hurt you.
• Guest communication is the highest-value module and the one that most needs the data spine to exist first, because a suggested reply is only as good as its knowledge of which property, which reservation, which check-in time, which door code. Build it second, but start collecting the raw material — your past replies — immediately, on day one, because that archive is the single most valuable proprietary asset in this entire plan.
• Staff tasks are third and are where the compounding starts: once guest messages can create tasks and tasks can create guest updates, the loop you described closes.
• Inventory is fourth. It is genuinely easy maths but it depends on reliable occupancy and turnover counts, so it rides on the spine.
• The AI supervisor is not a module. It is a read-only view over four modules that already work. Built first, it summarises nothing. Built last, it is nearly free.

What "necessary" means for CRM and PMS

You asked specifically what is actually necessary here, so, plainly:

You do not need a CRM. Not in the Salesforce/HubSpot sense. A CRM is for managing a pipeline of prospects over long sales cycles. Your guest relationship is transactional and platform-mediated: the OTA owns the acquisition, the stay is short, and repeat direct booking is a marketing ambition rather than a current operational reality. What people in this industry call a "guest CRM" is really three narrower things — a unified inbox, a guest profile with stay history, and a messaging automation engine. You need all three. You need them as part of the operations layer described in Chapter 1, not as a separate licensed CRM product. Buying a CRM before you have a unified inbox is buying a filing cabinet before you have paper.

The exception, and it is a real one: when direct booking becomes a serious channel (and with a management fee tied to bookings, it should), you will want consented guest email/marketing lists with proper opt-in handling. That is an email platform plus a consent table, not an enterprise CRM.

You do need a real PMS, and it is the one component where custom-building is actively wrong. The PMS holds the calendar. The calendar is the thing that, if wrong, produces double bookings, angry guests, OTA penalties and refunds. Reliability there is worth far more than elegance. Chapter 5 sets out what a PMS must provide for this plan to work — a documented API, webhooks on reservation changes, certified OTA connections, and multi-property/multi-country support — and why SMARTORDER, on current public evidence, cannot be assumed to provide any of them.

The shape of the system

        ┌──────────────────────────────────────────────┐
        │            OTAs / direct booking             │
        │  Airbnb · Booking.com · Agoda · Expedia ·    │
        │  Trip.com · (Jalan / Rakuten in Japan)       │
        └───────────────────────┬──────────────────────┘
                                │  certified connections (BUY)
        ┌───────────────────────▼──────────────────────┐
        │   PMS / channel manager — system of record   │
        │   calendar · rates · reservations · guests   │
        └───────────────────────┬──────────────────────┘
                    API + webhooks │ (the only integration
                                   │  point you maintain)
        ┌───────────────────────▼──────────────────────┐
        │        OPERATIONS LAYER — what we build      │
        │                                              │
        │  ① Guest inbox + AI reply co-pilot           │
        │  ② Task engine (cleaning / maintenance)      │
        │  ③ Pricing recommender (with evidence)       │
        │  ④ Inventory forecaster                      │
        │  ⑤ Compliance register (JP / ID)             │
        │                                              │
        │        shared data spine + audit log         │
        └────┬──────────────────────────────┬──────────┘
             │ LINE (staff)                 │ web (management)
        ┌────▼─────────────┐        ┌───────▼──────────────┐
        │ Cleaners &       │        │ ⑥ AI Operational     │
        │ maintenance      │        │    Supervisor        │
        │ (LIFF mini-app)  │        │    daily digest      │
        └──────────────────┘        └──────────────────────┘

Read that diagram as a boundary map. Everything above the operations layer is bought and treated as a supplier. Everything inside it is yours, because it encodes how you run properties — and that judgement is the thing a management fee is actually paid for.

How to read the chapters

Each chapter follows the same structure: what you asked for → what is actually possible → how it should be built → what it costs you in effort and risk → what to decide. Chapters end with an explicit decision list, because the value of this document is not that it describes a system but that it narrows your choices to a handful of real ones.

Two conventions:

• Buy means a vendor, a subscription, and a contract you can leave. Build means it becomes your maintenance burden forever. The default is buy; build only where the alternative is a black box you cannot inspect or a workflow no vendor supports.
• Human-in-the-loop is used precisely: the system prepares a complete, sendable, editable artefact and a person presses one button. Not "the system asks a question and a person types an answer." The difference is the entire productivity gain.

What this handbook does not do

It does not price a specific vendor stack down to the yen. You chose architecture-first, and vendor pricing for this category is quote-gated above about 50 units anyway — Guesty, AirDNA Enterprise, Key Data and Breezeway all move to sales-led pricing at your scale, and any number printed here would be wrong by the time you negotiated. Chapter 8 gives cost shapes — per-unit-per-month, per-message, per-API-call — which is what you need to compare options, plus the exact questions to put to each vendor.

It also does not assume the current team is wrong. LINE is genuinely the right channel for your staff (Chapter 2 makes that case with evidence). SMARTORDER may well be adequate as a booking engine. The recommendations here replace as little as possible.