注文編集を受け付ける期間の設計：住所修正をどこまで認めるか
注文が入ったあとの住所修正を、買い物客自身の手で行えるようにするのは、問い合わせの削減という点で効果がはっきりした仕組みです。この仕組みで何ができるかは、注文後の住所修正をセルフサービスにする話で書いたとおりです。ただ、この仕組みにはセットで決めておくべきことがあります。「編集をいつまで受け付けるか」、つまり編集できる期間です。期間を決めずに「配送までずっと直せる」状態で運用すると、今度はストア側が困ることになる。この記事では、その期間をどう設計するかを、注文編集アプリ「ナオシ｜注文編集・注文変更・住所修正」をつくった本人が整理します。
なぜ編集期間を決めるのか
住所修正の受け付けを無制限に開放したときに起きることを、発送の流れに沿って並べます。
ピッキング中に修正が入る。 商品を棚から取り出している最中に住所が変わると、伝票の出し直しが発生します。作業のやり直しは小さいようで、繁忙期には積み上がります。
発送済みの荷物と編集がすれ違う。 さらに困るのが、配送業者に引き渡したあとの修正です。荷物は古い住所へ向かっており、手元にあるのは新しい住所。ここから先はストアだけではどうにもできず、転居や再配送の窓口を買い物客に案内するしかありません。届いた荷物が戻ってくれば、受け取り手の不在と同じコストが発生します。
つまり、出してしまった荷物に対する編集の着信は、問い合わせが来るよりたちが悪いのです。問い合わせなら「まだ間に合うか」をこちらで判断できますが、編集は依頼ではなく事実として届いてしまう。だからこそ、編集を受け付ける期間とは、単なる決め事ではなく、発送作業を守るための制御装置として設計する必要があります。期間とは、ストア側の作業と買い物客の自己修正の間に引く、一行の境界線です。
期間の長さの考え方
編集できる期間は、長ければいいわけでも短ければいいわけでもありません。基準にすべきは、自分のストアの発送リズムです。注文を受けてから、ピッキングをして、配送業者に渡すまでの流れ。この流れのどこで「住所を確定したいか」を決めれば、期間は自然に決まります。よくある形は次の3つです。
- 注文した日の終わりまで。 その日のうちに発送作業へ進むストア向き。夜に注文確認をして翌朝ピッキング、という流れなら、日をまたぐ前に住所を確定できます。
- 注文からN時間まで。 発送までに半日程度の猶予があるストア向き。「12時間」のように時間で区切るので、夜22時の注文でも翌朝10時まで編集可、という具合に注文時刻から起算されます。
- 毎日の決まった時刻まで。 集荷の締め時刻に合わせて区切る形。「15時までの注文分はその日のうちに発送」のような運営なら、15時を編集の締めと揃えるのが素直です。
一般論として、期間を短くするほど予想外の修正は減り、長くするほど問い合わせは減ります。 どちらに倒すかは、発送の速さと問い合わせ対応の余裕のバランスで決まります。ストアのタイプごとの例を、あくまで一例として挙げます。
当日発送のストア。 15時締めで当日発送するなら、編集も同じ15時までと揃えるのが迷いがありません。締め後の注文は翌営業日発送になるので、その分は翌日の締めまで編集可にすると釣り合います。
リード日数が1〜2日のストア。 ピッキングを翌日以降に行うなら、注文日の深夜まで、あるいは翌日の締め時刻まで編集を認める余裕があります。この余裕があると「注文直後に間違いに気づいた」ケースをほぼ吸収できます。
ギフトを送るストア。 注文者と受取人が違い、届け先の確認に時間がかかるケースがあります。発送の1日前まで編集を認めるなど、リード日数より少し長めに取ることで、宛名の間違いを送り手側で直せる窓口ができます。ただし長く取るぶん、発送予定の見える化とセットにしないと、いつ直されるか分からない不安がストア側に残ります。
決めておくべき境界のケース
期間を設けると、その境界線の扱いをあらかじめ決めておく必要があります。運用を始めてから初めて考えると、その場の判断がブレます。
境界の時刻ちょうどの修正。 「15時まで」と決めたとき、15時0分0秒の修正は受けるのか。この議論を人の目で行うのは不毛なので、機械的に扱うのが正解です。後で述べるとおり、期間の判定はアプリ側で行うべきで、境界の内側か外側かはアプリが判定します。ストア側は「15時ちょうど」のケースを個別に審査する必要はありません。
繁忙期の短縮。 年末年始のような繁忙期は、普段より編集期間を短くする判断が有効です。発送のバッファが詰まっている時期は、いつもより早い段階で住所を確定したい。期間の設定を見直せるかどうかは、繁忙期前の運用計画とセットで確認しておくと安心です。
何度も編集する買い物客。 期間内であれば住所を2度でも3度でも直したくなる買い物客はいます。これを止めるべきではありません。最終的にどの住所で確定したかが正しく記録されていれば、途中の紆余曲折は問題ではないからです。むしろ抑止するより、「何が変わったか」を見える形に残す方がストアの利益になります。この記録の話は次のセクションで書きます。
期間はアプリ側で守る
ここまでの話を実現するには、編集できる期間の判定を「見た目」ではなく仕組みとして守る必要があります。注文詳細ページの編集フォームを期間経過後に隠すだけでは、開いていたタブから送信される修正を止められません。遅い編集は、遅いなりに届いてしまう。
ナオシでは、編集できる期間はアプリの側で強制されます。期限を過ぎた編集は単純に受け付けられません。UIが編集画面を隠しているのではなく、サーバー側の判定で受け付けを拒否する作りなので、期限後の住所修正という事象そのものが発生しません。買い物客には期限が過ぎていることが伝わり、ストアには出してしまった荷物とすれ違う修正が届かない。境界線は、見えないところで確実に守られるのが正しい形です。
また、発送作業が始まった注文の編集を受付外にするという発想もあります。ピッキング以降は住所変更が起きない方が都合が良いので、作業の開始をもって編集を閉じる、という考え方です。期間だけでなく作業の進行も編集可否の条件にする、この方向性の保護は設計として自然だと私は考えています。
編集された記録が手元に残る
期間を設けて編集を受け付けるなら、もうひとつ必要なのは記録です。窓口を開けた以上、何が変わったかをストアが知らないままにしておくのは不安です。誰も気づかないうちに住所が差し替えられていた、では困ります。
ナオシでは、編集の履歴が注文ごとに残り、差分で確認できます。氏名・郵便番号・住所・建物名・部屋番号・電話番号・メールアドレスのどこが、何から何へ変わったか。期間内の修正であっても、黙って変わることはありません。配送伝票を出し直すような場面でも、「なぜ出し直すのか」の根拠が手元にあると、作業の判断が早いのです。
導入の案内
7日間の無料トライアルがあります。まずは自分のストアの発送リズム（注文からピッキングまでの間隔、集荷の締め時刻）を書き出し、それに合わせて編集できる期間を1つ決めて、テスト注文で期限前後の挙動を確かめるのがおすすめです。月額$5です。設定で困ったら、つくった本人が日本語で24時間以内に返信します。アプリの詳細はこちらから確認できます。