受注生産をしているなら、頭の中に数字があるはずです。1日12個のケーキ。土曜日のケータリング40食。バレンタインの花束60束。それは好みではなく、実際にある手の数、オーブンの数、時間の数です。
そこで1日あたりの注文数を制限できるアプリを見つけ、12に設定します。そして1か月後には、また電話で注文を受けています。
理由はこうです。
2つの異なる日付
お客様が月曜日に、金曜日受け取りのケーキを注文したとします。この注文には2つの日付がついています。注文が入った月曜日と、実物が存在していなければならない金曜日です。
ほとんどの注文制限ツールは月曜日を数えます。制約が「今日どれだけの注文をさばきたいか」なら、それは正しい日です。遅れを取り戻している店や、朝に50件の通知を受けたくない個人作家にはそれが合います。
しかし制約がキッチンなら、月曜日は何も教えてくれません。上限があるのは金曜日です。そして金曜日が来たときには、注文は数日前に、1件2件ずつ、どれも静かに見えた日々のうちに受け付けられています。
結果として両方の悪いところが残ります。月曜日は問題なさそうに見えるので注文は止まりません。金曜日は受けすぎになり、それに気づくのは木曜の夜です。
その1週間は実際にこうなる
1日12個のデコレーションケーキが上限のベーカリーで、注文日ベースの上限を12に設定した場合を考えます。
| 注文が入った日 | 受けた注文 | うち金曜分 | 金曜の実際の合計 |
|---|---|---|---|
| 月曜 | 4 | 3 | 3 |
| 火曜 | 5 | 4 | 7 |
| 水曜 | 3 | 3 | 10 |
| 木曜 | 6 | 5 | 15 |
どの日も12という上限を超えていません。どの日も余裕があるように見えました。それでも金曜日は3個超過しており、ストア側は誰もそれに気づきませんでした。ストア側は金曜日を数えていなかったからです。
これが問題の形であり、「1日あたり上限を設定しましょう」という助言が役に立たない理由です。上限は有効でした。ただ、向いている日付が違っただけです。
スプレッドシートの段階
私たちが話す事業者の多くは、これを同じ方法で解決しています。そしてそれはいつもスプレッドシートの一種です。
週ごとのタブ。生産日ごとの行。注文が入るたびに手で更新する数字。たいていは夜に、たいてい記憶を頼りに。機能はします——「毎日あなた自身が必ず正確であること」を要求するものが機能する、という意味では。
問題はスプレッドシートが間違うことではありません。ストアがその存在を知らないことです。スプレッドシートは金曜が満枠だと言っているのに、サイトは金曜を売り続けます。そこで商品ページに注記を足します。「金曜日のご注文は制限される場合があります。追ってご連絡します」——こうしてあなたは、すでに分かっていたことについて返金し、謝ることになります。
あるいは別の道を選び、その商品をオンラインで売るのをやめます。つまり制約が、販売チャネルそのものを奪ったということです。
作業が発生する日を数える
解決策はより良いスプレッドシートではありません。もう一方の日付を数えることです。
「1日12個」が受け取る日の12個を意味するなら、すべてが噛み合います。月曜に入った金曜分の注文は金曜に数えられます。木曜の夜に入った金曜分の注文も同じ金曜に数えられ、それが13件目なら通りません。
頭の中の数字と、ストアが実際に強制する数字が同じ数字になります。誰も何かを更新し忘れる心配がありません。
これが OrderRules で今できることです。Advanced プランで配送日を有効にすれば、どの商品の1日あたり上限も、注文日ではなくお客様が選んだ配送日で数えられます。商品側の1つの設定です。1日あたり上限の集計基準 — 注文日か配送日か。
| 注文日 | 配送日 | |
|---|---|---|
| 守るもの | 今日の自分の時間 | その日の生産量 |
| 数える対象 | 注文が入った日 | 納品期限の日 |
| 向く場面 | 遅れの解消、ローンチ、流量調整 | 受注生産、仕込み日、配送ルート |
| 上の表の金曜日 | 発動しない | 12で止まる |
見た目より効く4つの詳細
バリエーションは別々に数えます。 中サイズと大サイズのケーキは同じ手間ではなく、両方にまとめて1つの数字を当てても、数字がないのと大差ありません。同じ商品に中10個・大14個と設定すれば、それぞれ独立して上限がかかります。独自の上限がないバリエーションは商品の上限に従います。
受取と配送はキャパシティを共有します。 10は10です。お客様が取りに来るか届けてもらうかは、オーブンには関係ありません。だから上限にも関係ありません。配送と並行して店舗受取を提供している場合、ふつうはこれが望ましい挙動です。共有の上限こそがキッチンの実態に合っています。
お客様はチェックアウトではなくカレンダーで止まります。 日付を選ぶとき、その日の残り枠数が見えます。カートの内容が入りきらない日付は、そもそも選択できません。選んで気持ちを固めた後にチェックアウトで断られるのは、最初からその日付を出さないよりも悪い体験です。しかも土曜日に誘導できていれば失わなかったかもしれない売上を失っています。
キャンセルは枠を戻します。 金曜の注文がキャンセルされれば、金曜はもう1件受けられます。当たり前のことですが、あえて書きます。減る一方のキャパシティは静かな漏れであり、最後には「満枠ではないのに満枠の日」を生むからです。
数字はいくつに設定すべきか
理論上の最大値を入れたくなります。2つの理由でやめておきましょう。
1つめは、最大値が「何も問題が起きない日」を前提にしていることです。急な欠員もオーブンの故障も、見積りの2倍かかるウェディングケーキもない日です。最大値ぴったりの上限は、良い日にだけ正しい上限です。
2つめは、この記事の最後で説明する同時実行のわずかな隙間です。上限6の日付なら、1枠の余裕は売上1件のコストで、上限を超えうる唯一のシナリオを消せます。上限60の日付なら、それはノイズです。数字が小さいほど、余裕の価値は上がります。
実践的な出発点：口に出して言う数字より少し低く設定し、2週間動かして、実際にどの日付が埋まったかを見ます。控えめすぎた上限を上げるのは気持ちのいい問題です。ひどい土曜日のあとで下げるのは、そうではありません。
同じ制約の別の形
ケーキは最も分かりやすい例ですが、唯一の例ではありません。
- ケータリングは、予約がいつ入ったかに関係なく、土曜日が抱えられるイベント数が決まっています——Shopify をケータリング・イベント業に使うを参照。
- フラワーショップにはバレンタインと母の日があり、上限は注文が入る数週間前から「手」と「花材」で決まっています。
- 受注生産・小ロットの作り手は在庫ではなくキャパシティを売っており、それ自体が1つの運用技術です——受注生産のリードタイムと生産上限で扱っています。
- 事前注文を受けるレストランはランチ営業に数字があり、受取と配送の両方がそこを削ります。
- 家具・大型商品はオーブンではなく配送班が制約で、上限は実質「1台のトラックが回れる訪問件数」の話です——家具ブランドのための Shopifyを参照。
制約が1日単位ではなく枠単位なら——10時〜12時の枠で4件まで——それは別の設定です。配送キャパシティ上限は、商品ではなく配送可否ルール側で日付ごと・枠ごとに上限をかけます。両方は併用でき、両方が必要なストアも少なくありません。
リードタイムと締め切りとの関係
配送日ごとの上限が答えるのは「何件まで」です。隣接する2つの設定は「そもそもどの日を提示できるか」に答え、上限より先に動きます。
リードタイムは近すぎる日付を除きます。デコレーションケーキに3日必要なら、金曜日は水曜の時点で選択できなくなります。金曜にどれだけ枠が残っていても関係ありません。最良ケースではなく、実際の製作時間で設定してください。
注文の締め切り時間は「今日」がどこで終わるかを決めます。生産リストを14時に確定するなら、14時15分の翌日分の注文は実際には翌々日分の注文です。注文の締め切り時間はそれを明示し、リストを読む人の判断に委ねずに済みます。
処理の順序は知っておく価値があります。リードタイムと締め切りがお客様に見せる日付を決め、配送日ごとの上限が各日付がまだ受けられる件数を決めます。日付はどちらの理由でもカレンダーから消えますし、お客様に表示されるメッセージもそれに応じて変わります。
商品ページに配送予定日も表示している場合、その予定日は同じリードタイム計算の表示です。いつ届くかを伝えるのが予定日で、その日付がまだ空いているかを決めるのがこれらの上限です。
注文日のほうが正しい場面
はっきり書いておきます。配送日での集計は「より良い選択肢」ではなく「もう一つの選択肢」です。
上限が「何件受けたいか」を表しているなら——人手不足のあいだ絞る、ローンチに上限をかける、新商品の数量を扱える範囲に収める——注文日が正しい基準であり、それは以前からそうでした。それは流入する仕事に対するレート制限で、流入する仕事は来た日に来ます。その場面では、注文日で数える1日あたりの注文上限が正しい道具です。
問うべきは「その数字は何を守るのか」です。今日の自分の時間を守るなら注文日。その日の生産量を守るなら配送日です。
どちらの場合も、週次・月次の上限は注文日で数えられ続けます。変わるのは1日あたり上限だけです。「今週」は期間ですが、「金曜日」は特定のキッチンがある特定の1日だからです。
設定方法
すでに配送日を有効にしているなら、作業は1分ほどです。
- 商品から商品を開く
- 1日あたり上限の集計基準で配送日を選ぶ
- 1日あたりの数量を設定する（商品単位、またはバリエーション単位）
- 保存する
先に複数の商品を選んでおけば、すべてに適用されます。CSV のエクスポート・インポートでも引き継がれるので、カタログ全体を一度に設定できます。
その後、商品テーブルには上限をかけた各商品について、使用率のパーセンテージではなく、もっとも余裕のない今後の日付が表示されます（11/14(金) · 9/10）。パーセンテージでは意味をなさないからです。ここでの使用状況は単一の数値ではなく、今後の日付ごとに1つずつある時系列です。来週の土曜が空きゼロでも、今日時点の表示は0%になりえます。
正直な限界
これができないことが1つあります。あとで気づかれるより、先に書いておきます。
同じ秒に、同じ日付で、残り1枠のところをチェックアウトした2人のお客様が、両方とも通ることがあります。チェックアウトの検証は予約済みの内容のスナップショットを読むだけで、在庫のようにロックをかけられません。実際には、残り1枠の日付でほぼ同時のチェックアウトが必要なので、まれです。しかし不可能ではありません。そうでないと謳うアプリは、プラットフォームが提供していないものを謳っています。
だからこそ、上で書いた「余裕を残す」助言は小さい上限では守る価値があります。数字を超えうる唯一のケースを、安く消す方法です。
このしくみが実際にやってくれるのは、ストアと生産スケジュールを、あなたが両方を管理しなくても同じものにすることです。ほとんどの日、ほとんどの週において、それがオンラインで売れるかどうかの差になります。
次に読む
- 配送日ごとの上限 — バリエーション、CSV、キャンセルを含む設定ドキュメント
- 配送日の設定を始める — この設定が表示される前提
- 商品ごとの上限 — 基準が変わる対象の1日あたり上限
- 配送キャパシティ上限 — 配送可否ルール側の日付別・枠別の上限
配送日ごとの上限は Advanced プランの機能で、配送日の有効化が必要です。ドキュメントを見る →