Koratこの整理券は、印刷したら店側の記憶に頼るだけの紙切れではない——客と店の両方が同じ状態を見ている一行のデータだ。1回のスキャンで1枚の整理券が発行され、待ちグループと人数が紐づく。スタッフは空いている窓口から次の番号を呼び、すべての状態変化は同じデータベースを通る。従業員一人の頭の中にあるホワイトボードではない。
整理券の受け取り方——セルフスキャンかスタッフ発行
店は複数の待ちグループを持てる（注文の受け取り、返品対応、特定の窓口など）。グループごとに、客が自分でQRコードを読むか、スタッフが代わりに発行するかを選べる。整理券には名前・連絡先・人数を記録できる。すべての整理券はその店自身の営業日に属していて、端末の時計の日付ではない——深夜をまたいで営業する店では、機器の時刻から日付を推測すると、意図とは違う待ち行列の板になってしまう。サーバーがその店の「今日」が何日かを答えられない場合、画面は読み込み失敗と表示する。実際に並んでいる人がいるのに空の板を推測して見せることはしない。
自分の順番を確認する
整理券を受け取った客は、自分の番号・グループ・現在の状態を見られる。順番の数字は画面を開いたまま10秒ごとに更新される——秒単位でリアルタイムに動くカウンターではない。だが実際に自分の番が来た瞬間、どの窓口に行けばいいかを知らせるプッシュ通知が即座に届く。だから待っている間ずっと画面を見つめていなくていい。
店側——呼び出し、状態の移動、連続無応答の上限
スタッフは自分が担当する窓口から次の整理券を呼ぶ。客が聞き取れなかった場合は同じ番号を再度呼べるし、間違って呼んでしまったらすぐ取り消せる。各待ちグループは、何回呼んでも応答がなければ「無応答」とみなすかの上限（no_show_limit）を設定できる。これにより列全体が、二度と聞きに来ない一枚の整理券に足止めされることを防ぐ。発行・呼び出し・状態変更・終了——すべての書き込みは権限を自分で検証するサーバー側の関数を通る。整理券テーブル自体には直接書き込む権限が一切なく、システムの誰も知らない整理券が存在することはあり得ない。
席に着いて注文し会計まで済ませるお客さまには飲食のテーブルQRのほうが向いています。時間を先に決めて待たずに来てほしいならサービスの予約です。
待ち行列のグループ、窓口、そして従業員が呼び出しに使う画面は、すべてビジネスコンソールで設定します。呼ぶ人が今日出勤かどうかはマイ職場のシフト表から来ます。
車で来られるお客さまの敷地内の駐車券は別の話で、駐車場にあります。番号を取ったついでに物を買ってもらうならネットショップ側です。
保存した画面のスクリーンショットのQRコードは使えない——目の前の実物の看板から読み取る必要がある。 このトークンはそのグループの現在の発行ラウンドに紐づいており、何度でも再利用できる固定コードではない。
整理券の紙に印刷されたリンク（koratland.com/queue?...）からも同じ画面が開く——アプリなしでもブラウザで自分の順番を確認できる。