タイの多くの店は、互いに口をきかない3つのシステムを動かしています。レジのための POS、注文のためのデリバリーアプリのタブレット、そしてシフトのためのグループチャット。客はその3つすべてで見知らぬ他人のままです。Korat があるのは、これが3つの問題ではないからです——違う椅子から見た、一つの注文です。
店を開けるのに1分ほど
ビジネスを作り、名前と住所と電話番号を入れ、業種を選ぶ。業種がどのモジュールを読み込むかを決めます。座って進める設定ウィザードはありませんし、最初の注文を受ける前に構成しておくものもありません。重要な設定——営業時間、デリバリー、PromptPay、カテゴリ——は、あとから戻ってこられるタブだからです。
ビジネスの削除は意図的に2回の確認を求めます。名前・住所・電話番号・説明の編集は一枚のシートで、変更は公開ページにすぐ反映されます。
飲食店——QR がセキュリティモデルのすべて
スタッフがテーブルを開けます。それがその一回の着席にだけ属するトークンを発行し、QR がそれを運びます。客はスキャンしてセッションに入り、注文します。テーブルが閉じればトークンも一緒に死にます。撮影された QR や、通りの先の友だちに転送された QR が役に立たないのはそのためです。
注文はそのまま厨房には行きません。厨房ディスプレイの確認待ちのキューに入り、人が一件ずつ承認するか却下します。この一手間が、QR メニューと、忙しい金曜日に動かしっぱなしにできるシステムとの違いです。営業時間にはラストオーダーの余裕時間があるので、アプリはまずテーブルに厨房が閉まると警告し、それから注文の受付を完全に止めます。
飲食モジュールの残りは普通の仕事です。写真・カテゴリ・提供可否・在庫・価格差付きのオプショングループ・セットを持つメニュー、カウントダウンと食べ残し課金のあるビュッフェのパッケージ、スタッフによる年齢確認を伴う酒類の関門、テーブル予約、配送料と指定受け取り時刻のあるデリバリー、そしてラベル付きの割引・預かりとお釣り・金額ぴったりの PromptPay QR を備えた会計。
物販、宿泊、クリニックも同じ扱いです
- 物販
- カウンターのレジ、保留 → 確定 → 梱包中 → 発送済み → 配達完了の5段階を持つオンライン注文コンソール、追跡番号、理由付きの却下、属性とバリエーションを持つ商品、そして残り少ない在庫の警告。
- 宿泊
- グリッド上でチェックイン・チェックアウトする客室、写真と1泊料金を持つ部屋タイプ、日付範囲ごとの季節・販促の料金ルール、予約受信箱、ルームサービスの依頼、そして敷金・水道と電気の検針値・生成される請求を扱う月極賃貸。
- サービスとクリニック
- 所要時間と価格を持つサービス、担当者を割り当てる予約、そして客が買って1回ずつ消化するコースや会員資格。クリニックでは画面が予約・患者・施術コースという語彙になります。
レポート、顧客、会員機能はどの業種にも付きます
本日・直近7日・直近30日・全期間の売上、注文件数、客単価。現金 / PromptPay / その他の内訳。売れ筋トップ5。そして7日間の売上棒グラフ。どのレシートも再印刷でき、テキストとして共有できます。税額票は発行できません:タイの歳入法典 86/13 条は発行を VAT 登録事業者に限っており、どの店の登録もこのシステムはまだ記録していないので、どの書類も VAT 行のない普通のレシートです。
顧客リストは販売台帳から自分で組み上がります——顧客を打ち込む必要はありません。それぞれが購入履歴、あなたのメモとタグ、あなたが自分の通貨で自由に設定するレートで貯まるポイント、あなたが決める最低購入額と特典、そして引き換えのボタンを持ちます。これは、デリバリーのプラットフォームが構造上あなたに渡せない部分です。あちらが顧客を持ち、あなたが受け取るのは注文だけだからです。
スタッフ——GPS 打刻、残業、そして誰が何を見てよいか
人事モジュールはどの業種でも同じです。スタッフは GPS と任意の備考を添えて出退勤を打刻します。休暇申請はコンソールで承認か却下をします。シフトは実労働分と1日8時間超の残業になり、時給か月給を当てて各メンバーの給与が計算されます。一般のスタッフは自分の給与だけを見て、オーナーとマネージャーは全員分を見ます。
権限はスイッチではなくマトリクスです。13のコア権限に、インストールしたモジュールが足すぶん。オーナー・マネージャー・ホール・キッチン・一般スタッフのプリセットに、人ごとの上書きが重なります。使えないタイルはグレーアウトするのではなく、そこにありません。まだ何も権限のないメンバーには、壊れて見える空のコンソールではなく「まだ権限がありません」という素直な画面が出ます。
どこで強制されているかをはっきりさせておきます。 アプリの中では、タイルを隠す権限判定は端末側で走ります。同じ権限マトリクスはデータベースにも has_capability(business_id, capability) として存在し、行レベルセキュリティのポリシーが使っています——だから役割プリセットはサーバー側で展開され、データベースが「誰がマネージャーか」についてアプリを信用することはありません。コンソールのすべての画面をサーバー側で強制する作業はまだ進行中です。どこまで進んだかはセキュリティのページに正確に書いてあります。
公開ページは製品の一部です
どのビジネスにもページがあります。カバー、ロゴ、ギャラリー、いま開いているか閉じているかまで出る営業時間、住所、電話番号、道順、フォローボタン、店へのチャットボタン、そして業種によって変わる行動ボタン——注文する、商品を見る、部屋を予約する、来店を予約する。フィードには店として投稿でき、その投稿は常に公開です。
そのページのレビューを書けるのは、客だったとデータベースが証明できる人だけです。店内で食べた、デリバリーを注文した、泊まった、サービスを使った、パッケージを買った。それ以外の人には、なぜ書くボタンがないのかを説明する鍵のカードが出ます。星の評価はデータベースのトリガーがレビューの行から再計算するもので、私たちを含め誰も入力できません。 どのレビューにも返信できます。