Koratネットショップの仕組みがあるのは、チャットのスレッドで店をやっている売り手が、いつか必ず注文を一件取りこぼすからです。スレッドに代わるものは意図的に地味です。検索とカテゴリ絞り込みのあるカタログ、タップの前に在庫を見せる商品ページ、どの店のものか曖昧にならないカート、そして遷移のたびに通知が飛ぶ5つの名前付き状態を進む注文。
商品ページ——バリエーション、在庫、割引をタップの前に
商品には写真、説明、在庫、そして値引きできる価格があります。セール価格は取り消し線の入った元の価格と割引率のバッジとともに並ぶので、値引きの大きさがほのめかしではなく読み取れます。品切れのときは、それが写真の上に描かれます。会計の段階で発覚するのではありません。これはアプリ全体が守っているルールに従っています。タップの結果を変えるものは、タップの前に見えていなければならない。ボタンが、次の画面で断られることを約束してはいけません。
バリエーションは一つずつ入力するのではなく、属性から生成されます。売り手は軸——サイズ、色、その商品が実際に変化する何か——を宣言し、その組み合わせがそれぞれ在庫を持つバリエーションになります。これで、よくある壊れ方がデータに入りません。同じシャツを別々に3件登録してしまい、まとめて集計できず、在庫数が3つのうち一つだけ正しい、という状態です。
カートは一つの店のもの
カートは一店舗ぶんです。別の売り手の商品を追加しようとすると、いま入っているものを消していいか尋ねます。4つのビジネスをまたぐ買い物かごを黙って組み上げたりはしません。これは機能の欠如ではなく設計上の拒否です。複数店舗のカートは、一つの会計、一つの送料計算、そして届かなかったときの一つの責任の所在を含意します。売り手が4つの独立した地元の商売で、配送の取り決めも4つあるなら、そのどれも存在しません。
カートは一店舗ぶん、意図的にそうしています。 店を切り替えるときはカートを空にしていいか尋ねます。複数の売り手にまたがるかごが誠実であるためには一つの会計が必要ですが、ここにマーケットプレイス全体の会計はありません。注文はつねに、買い手と一つのビジネスのあいだのものです。
送料はアプリが送る項目ではありません。注文が置かれたときにサーバーが店自身のレコードから読み、配達のときだけ適用されます。
会計——配達か受け取りか、そしてクライアントが決められない送料
会計は注文に実際に必要なことだけを尋ねます。配達か店頭受け取りか、名前、電話番号、住所、備考、支払い方法。店頭受け取りを選ぶと送料はゼロと表示されるのではなく、項目ごと消えます。二つは違うことを意味しますし、ゼロはバグに見えるからです。住所は既定を持つアドレス帳から来るので、2回目の注文で1回目の住所を打ち直す必要はありません。そしてそれはプロフィールと共有された一つのアドレス帳です。プロフィールの住所と配送先は同じ事実であり、二重に保存すればいずれ必ず食い違うからです。
送料そのものはサーバー側です。place_shop_order は businesses.delivery_fee をデータベースから読み、クライアントが送ってきた値を無視します。店内オーダーが全行を自分で値付けするのとまったく同じです。信用されたクライアントの項目は、セルフサービスの割引になります。お金はサーバーのものです。これは設定で切れる方針ではなく、数字がどこから来るかという話です。
5つの注文状態、追跡番号、両側に通知
注文は保留 → 確定 → 梱包中 → 発送済み → 配達完了と進み、キャンセルと却下が終端の分岐として付きます。買い手には単独の状態語ではなく進捗バーが見えるので、「梱包中」は続きのある並びの中の位置として読めます。発送の段階で追跡番号が付きます。同時に配送業者を、管理側が整備した一覧から選びます。各業者は追跡 URL のテンプレートを持っているので、店が入力した番号は買い手が開けるリンクになります。業者を指定せずに追跡番号だけを付けることはできません。どこの番号か分からなければ、リンクにはならないからです。
どちらの終わり方にも理由が付きます。客がキャンセルするときも、店が却下するときも理由を書き、その理由はチャットで流れ去るメッセージではなく注文と一緒に残ります。すべての遷移が両側に通知されます。通知のない注文フローは、店に注文を見落とさせ、買い手に憶測させるからです。
- 保留 — 注文された、店の返事待ち
- 確定 — 受け付けられ、店が引き受けた
- 梱包中 — 準備している
- 発送済み — 出た、追跡番号つき
- 配達完了 — 完了、そして買い手にレビュー資格が付く
売り手の側——店頭POS、オンライン注文、在庫
物販のビジネスにはコンソールのタイルが3つ付きます。対面販売のレジ、アプリ経由の注文をさばくオンライン注文コンソール、そして残り少ない在庫を警告する商品と在庫。ダッシュボードのバッジは数秒ごとに更新されるので、新しい注文は見つけられるのを待たずに自分から名乗ります。店頭の販売もアプリ経由の販売も、同じ台帳に書き込まれます。
両方の経路が一箇所に落ちるので、レポートはオンラインの一部ではなく商売の全体を扱います。売上、注文件数、客単価、現金 / PromptPay / その他の内訳、売れ筋トップ5、7日間の売上棒グラフ、そして本日 / 7日 / 30日 / 全期間の切り替え。レシートは再印刷でき、同じ記録から共有可能なレシートのテキストを作れます。税額票（タックスインボイス）は発行できません——発行できるのは VAT 登録事業者だけで、どの店の登録もこのシステムはまだ記録していないからです。顧客リストもその台帳から組み上がり、顧客ごとのメモとタグ、購入履歴、店舗が自店の通貨で自由に設定できるレートで貯まる会員ポイントが、設定できる最低購入額と特典に対して貯まります。
スタッフのアクセスは、役割プリセットと個人ごとの上書きを持つ権限マトリクスが管理します。販売員に、給与やレポートを渡さずに商品と注文だけを任せられます。同じマトリクスはデータベースにも has_capability(business_id, capability) として存在し、行レベルセキュリティのポリシーのためにサーバー側でプリセットを展開します。誰がどの役割かについて、サーバーはクライアントの言い分を信用しません。
商品レビューは実際に買った人だけが書けます
商品レビューは店舗のレビューとは別ですが、条件は同じです。取引したとプラットフォームが証明できる客だけが書けます。資格判定はデータベースのビューで、購入は、店内での食事・デリバリー注文・宿泊・サービス利用と並ぶ有資格の取引の一つです。それ以外の人には、失敗するボタンではなく、なぜ書くボタンがないのかを説明する鍵のカードが出ます。
星の評価は誰かが編集する保存値ではありません。データベースのトリガーがレビューの行から再計算するので、店カードの評価とページのレビューがずれることはありません。買い手は自分の最新のレビューを編集も削除もでき、再購入すれば古いものを残したまま新しいレビューを足せます。店は公開で返信できます。
売った機材をお客さまが資産台帳に登録すると、不具合のときの申し立ては売った店――つまりあなたの側に戻ってきます。