マニュアルを整えても、キャンセルの可否をその都度、担当者に聞き直すことはないでしょうか。BtoC ECの事業・運営責任者に向けて、こうした個別調整がなぜ繰り返されるのかを整理します。

この記事のポイント

• 手順をそろえても、処理を進めてよい条件が曖昧なら、判断はそろいません。
• 販路や商品による必要な違いを残し、部門間では次の処理に進める条件をそろえます。
• 例外への対応が終わった後も、ルールを見直す責任が曖昧だと、同じ照会が繰り返されます。

業務標準化は、なぜマニュアルを作っても進まないのか？

手順書に「出荷前なら倉庫に停止を依頼する」と書いてあっても、「出荷前」の意味が違えば、同じ注文に同じ手順を適用できません。例えば、受注側が出荷指示を送る前、倉庫側が配送会社へ引き渡す前を指していれば、同じ注文でも停止依頼の対象かどうかで判断が分かれます。

手順を知らない場合は周知が役立ちます。手順を知っていても適用の可否を決められない場合は、どの状態をどの記録で確認するかを先にそろえる必要があります。

関連記事：BtoC ECに手作業が残る理由は？在庫・出荷・返品の確認から考える

販路・商品による違いは、どこまでそろえるべきか？

同じ条件で担当者によって結果が変わる判断は、共通化の候補です。一方、自社ECとモールで受付条件が違ったり、通常在庫品と受注生産品で変更できる段階が違ったりする場合は、その条件に応じて扱いを分けます。

条件別のルールは、担当者が処理時に条件を確認できて初めて使えます。個別の返品・キャンセルの可否は、各販路の取り決めや法令・契約上の条件に照らして判断します。

部門ごとの正しい対応が、全体では食い違う

CSがキャンセル依頼を受け付ける、倉庫が出荷を止める、経理が返金する。いずれも担当部門にとっては作業の完了ですが、注文全体では異なる段階です。例えば、CSが停止依頼を送った時点でキャンセル成立と伝えると、倉庫が出荷を止められなかった場合に案内と実際の処理が食い違います。倉庫が停止の可否を回答し、その結果を受けてCSが顧客に案内する、といった引き継ぎの条件をそろえます。

Shopifyの注文キャンセルに関する公式ヘルプにも、外部フルフィルメントサービス側で先に取消手続きが必要となる場合が示されています。受付画面の操作と委託先での処理結果を別々に確認する場面の一例です。

関連記事：BtoC ECの業務プロセスはどうつながる？販売準備から返品・返金までの全体像

例外を処理した後、ルールを更新する責任が抜け落ちる

例外対応を終えても、判断した理由が担当者の記憶やチャットに残るだけでは、次回も同じ照会が起きます。例えば、販促期間だけ倉庫の受付条件を変えた場合、終了後に元の条件へ戻す担当が曖昧だと、古い条件で顧客に案内しかねません。

個別案件の処理とは別に、誰がルールを見直すかを決めます。例外を認めた理由を残し、次回も使える条件か、一回限りの対応かを見直しの担当者が判断します。期限付きの変更では、適用が終わる時点と、通常の条件に戻す担当も決めておきます。

自社では、何を確かめて標準化の対象を選ぶか？

まず、同じ照会が繰り返されたり、顧客への誤案内につながったりした注文を一件選び、記録と担当者の説明から判断が分かれた箇所を確かめます。

• 適用条件：販路・商品・処理段階が違っていたなら、別の扱いにする理由を確認します。
• 判断材料：必要な情報が片方に届いていなかったなら、何をいつ渡すかを決めます。
• 決定権：条件も情報も同じなのに結論が分かれたなら、誰がどこまで判断できるかを合意します。
• 更新の責任：古いルールが使われていたなら、誰が更新し、現場がどこで最新版を確認するかを決めます。

システムで処理を支える場合も、先に判断条件と責任分担を合意しておくと、どこまでをシステムで扱うか決めやすくなります。

関連記事：BtoC EC業務のボトルネックはどこか？出荷遅延から見極める方法

おわりに

BtoC ECの業務標準化は、適用条件、部門間の完了条件、ルールの更新責任が曖昧だと進みません。まずは判断が分かれた一件から、残すべき違いと、関係者でそろえるべき判断を切り分けてください。

Yopazは、課題や目標の整理からシステムの導入・運用までを支援しています。キャンセル可否など、部門間で判断が分かれる業務について、判断に必要な情報や既存システムへの反映方法を整理したい場合は、Yopazへご相談ください。