Booking.comとAgodaを一元管理：Smart Orderを選ぶ条件
小規模ホテルがBooking.comとAgodaの在庫を一つのPMSで管理するなら、両方の接続・部屋割当手順を公開するSmart Orderを候補にできます。現在のPMSが安定しているなら、対応済みチャネルマネージャーを残す案も比較します。選定基準は部屋・料金プランの対応、将来予約の移行、例外の担当と接続込みの見積もりです。
二つの接続で違う条件
Booking.com向け手順は接続先SmartOrder International、部屋・料金プランの割当、将来予約の取込と手動有効化を記載しています。Agodaホテル向けはDingdandao ENを選び、予約配送の設定をSmart Order運営チームと完了する手順です。Agoda側も施設・部屋タイプ・料金プランIDが必要と説明します。Booking.comの在庫総数と検索条件で予約できる空室は別なので、人数や日付制限が一致する検索まで確認します。これは公開設定条件であり、稼働施設の切替承認ではありません。
公開機能と試用で確認すること
Smart Orderは部屋・料金・空室の集中管理と双方向OTA同期を説明しています。フロント機能には共有カレンダーとウォークイン入力があります。ただし、実際の権限、OTA接続とマッピングが自施設での動作を決めます。
この業務の受入チェックリスト
| テスト | 確認内容 | 残す証拠 |
|---|---|---|
| 新規予約 | 許可された予約を対応済み部屋に作成 | 正しい日付とチャネル番号で一件表示 |
| 変更 | 許可された手順で日付や人数を変更 | 不明な重複を作らず元の予約を更新 |
| 取消 | 取消後の空室を確認 | 予約状態と残り在庫が一致 |
| 制限 | 合意した販売停止や制限を変更 | 接続資料にある時間範囲で表示 |
| ウォークイン | PMSで手入力 | 各チャネルの残室へ反映 |
管理された試用を行う
施設・部屋・料金IDを整理し、異なる部屋名が同じ実室を使うか確認します。
テスト可能な部屋と日を選び、復旧担当とチャネルの許可範囲を確認します。
両側の参照番号と時刻を記録します。経過時間は観測値であり普遍的な保証ではありません。
最終室数、日付、人数、取消、関連決済を照合し、未解決差分を残してから拡大を判断します。
構成を公平に比較する
Smart Orderと既存PMS＋チャネル管理を同じ部屋構成で比較します。CloudbedsやSiteMinderは候補名であり同一パッケージではありません。接続サポートの担当と更新衝突時の正となるシステムを確認します。
重要な制限
一回の成功で過剰予約ゼロを主張しません。通信、販売制限、人的変更も結果に影響します。部屋数や接続数を増やす前に監視とエスカレーションを決めます。
確認できる製品仕様
| 項目 | メーカー記載と確認条件 |
|---|---|
| 提供形態 | Web型ホテルPMS・モバイルアプリ |
| 予約 | 共有カレンダー、空室、チェックイン・アウト |
| チャネル | 部屋・料金・在庫同期。実接続とプランを要確認 |
| 決済 | 予約に関連した記録。事業者と現地口座の条件が適用 |
公開されたソフトウェア機能であり、実際のホテルでの試験完了を示すものではありません。施設のプラン、口座権限、接続、事業者料金と提供国を確認してください。
よくある質問
公開機能は自施設での利用を保証しますか？
いいえ。実際のプラン、機器、接続、口座権限を実演で確認します。
試用で何を記録しますか？
各場面の期待動作、結果、参照番号、時刻と担当を記録し、不要な機微情報を残しません。
他社とはどう比較しますか？
同じ部屋と場面を使い、実演済み、開通が必要な機能、未確認条件を分けます。
一回成功すれば今後も保証されますか？
いいえ。変更・取消と例外の引継ぎを試し、監視と連絡経路を決めます。
次に何をすべきですか？
チェックリストを持って実演を依頼し、適用範囲と費用を書面確認します。合意した検証後に利用を拡大します。