Korat宿泊施設の管理ソフトウェアはたいてい日単位と月単位の線で割れます。片側にホテルの PMS、もう片側に賃貸の台帳、そして両方をやっているオーナーが二つのシステムを手で合わせている。Korat の宿泊モジュールはその分割を拒みます。ホテル、リゾート、アパート、コンドミニアム、一軒家、ゲストハウスは一つの業種で、その下に一つの部屋タイプのカタログがあります。同じ客室グリッドから2泊の予約も1年の賃貸契約も取れて、月末のレポートは両方を含みます。
単位は個々の部屋ではなく部屋タイプ
物件は、個別に設定された部屋の一覧ではなく、部屋タイプの集合として記述されます。それぞれに写真、1泊の料金、室数、説明、設備。料金と空室が実際に取る形がこれだからです。同じスーペリアツインが8室あるなら、それは数量8の一つの商品であって、8つの商品として扱えば、料金を直す場所が8箇所になり、直し忘れる機会も8回になります。閲覧はグリッドかリストで、「〜から」の価格、評価、種別バッジが付くので、ゲストハウスとコンドミニアムがタップの前に見分けられます。
カードの評価は、宿泊を証明できる客だけが書いたもの
カードの評価はオーナーが設定した数字ではありません。Korat のすべての評価と同じく、データベースのトリガーがレビューの行から再計算します。そして書けるのは、そこに泊まったとプラットフォームが証明できる客だけです。宿泊は、レビュー資格のビューにある有資格の取引の一つです。
季節料金と販促——一度計算して二度使う
料金は変わります。ソンクラーン（タイの4月中旬の旧正月にあたる祝日で、旅行が集中します）、連休、閑散期、オーナーが2週間だけ打つ販促。だから部屋タイプは料金ルールを持ちます。それぞれが日付の範囲と、パーセントか店舗自身の通貨での定額で表した調整です。重要なのはルールがあること自体ではありません——どの予約システムにも何かしらあります——一覧に出る数字と、予約が課金される数字が、同じヘルパーから出てくることです。本物から遅れていく表示専用の価格計算は存在しません。
この機能の典型的な失敗は、検索結果を一つの経路が値付けし、会計を別の経路が値付けすることです。客は物件が同意していない価格を見せられ、そのあと別の金額を請求されます。ヘルパーを共有することで、その食い違いはテストで探すものではなく、構造上あり得ないものになります。販促のルールが効いているときは、カードに取り消し線付きの基本料金とバッジが出るので、客は安い数字だけでなく調整の大きさを見られます。
予約は、物件が承認するリクエストです
オンライン予約はチェックイン・チェックアウトの日付、宿泊者、電話番号を取り、物件の予約受信箱に届きます。オーナーが確定します。未確認の件数はコンソールのダッシュボードに数秒ごとに更新されるライブのバッジとして、ビジネスが答えるべき他のものと並んで出るので、誰かが開くのを覚えておかなければならないキューにはなりません。
ルームサービスの依頼も同じコンソールへ
滞在中、ゲストはアプリからルームサービスの依頼を送れて、それも同じコンソールに届きます。小さな機能ですが、小規模な物件の回り方に不釣り合いなほど効きます。代わりにあるのは、誰も出ない客室の電話か、フロントまで歩くことだからです。
予約は予約であって、前払いではありません。 フローが集めるのは日付、宿泊者、電話番号で、物件がそれを確定します。Korat は予約時にカードを取ることも、デポジットを預かることも、宿泊料を処理することもありません。精算は物件との間で行われます。
月次の請求も同じです。生成され、入居者に表示され、オーナーが立てる支払い済みフラグを持ちます。フラグはお金が届いたことを記録するのであって、お金を動かすわけではありません。
オーナーの客室グリッドとコンソール
コンソールは物件に4つのタイルを渡します。チェックイン・チェックアウトのできる客室グリッド、季節ルールを含む部屋タイプの管理、予約受信箱、そして月極賃貸。グリッドはフロント係が一日を過ごす画面で、稼働状況がひと目で分かり、それを変える2つの操作が置かれています。部屋タイプの管理は、料金・室数・設備・料金ルールを一度だけ編集する場所です。
レポート、顧客台帳、勤怠——どの業種にも付くタイル
その周りに、どの業種にも付くタイルが並びます。レポートは売上、件数、客単価、現金 / PromptPay / その他の内訳、売れ筋トップ5、7日間の売上グラフ、本日 / 7日 / 30日 / 全期間、レシート再印刷と共有可能なレシートのテキスト——税額票（タックスインボイス）は発行できません——発行できるのは VAT 登録事業者だけで、どの店の登録もこのシステムはまだ記録していないからです。顧客台帳は販売台帳からメモ、タグ、履歴、そして店舗が自店の通貨で自由に設定できるレートで貯まるポイントとともに組み上がります。平日に繰り返し来る出張客を相手にする物件では、その履歴こそが役に立つ部分です。人事は GPS と備考つきの出退勤打刻、休暇申請、シフトと給与——実労働分と1日8時間を超えた残業——お知らせとタスクを扱います。
月極テナント——検針値が請求になる
月極賃貸の側で、このモジュールはホテルのシステムに似るのをやめます。部屋タイプは自分の賃料と光熱費の設定を持ち、部屋は入居者と敷金を持ち、毎月オーナーが水道と電気の検針値を入力します。請求はその検針値から生成されます——検針値が入力で、請求が出力です。紙の上で計算して、あとから誰も検算できない合計だけを打ち込むのではありません。生成された請求には支払い済みフラグが付くので、未収の一覧は記憶ではなくクエリになります。
小さなアパートの運営でいちばん揉め事を生むのがここです。まさに、たいていノートで処理されているからです。検針値を契約と一緒に残せば、請求はそれが生まれた二つの数字までさかのぼれます。「今月なぜ高いのか」への答えとして、ゼロから計算し直すより優れています。
スタッフの権限と、客には見えないもの
コンソールへのアクセスは権限マトリクスで動きます。13のコア権限に、インストールしたモジュールが足すぶん。オーナー・マネージャー・ホール・キッチン・スタッフの役割プリセット。そして個人ごとの上書き。権限のないメンバーにはタイルが隠れ、何も持たないメンバーには、壊れて見える空白の画面ではなく「まだ権限がありません」と明示する画面が出ます。
Android アプリでは、これらの判定はクライアント側で走ります。同じマトリクスは has_capability(business_id, capability) としてデータベースにも存在し、行レベルセキュリティのポリシーが使い、サーバー側で展開されるので、サーバーが役割についてクライアントを信用することはありません。ただし、今日のコンソール全体がサーバー側で強制されていると言えば言い過ぎになるので、そうは言いません。
泊単位の部屋はこのページ、月単位の貸主と借主の契約はレンタルです。同じ建物でも同じ伝票ではありません。