◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 繁忙期の滞留は、受付・在庫引当・納期回答・出荷指示の区間ごとの時刻差と未処理件数で場所を見分け、理由は担当者の聞き取りで補う。
- 設定で対応するか運用ルール・人員で対応するかは、負担・前提条件・確かめ方で比べ、設定の可否は自社システムの提供者資料で確かめる。
- 納期回答は引当済みの確定納期と見込みの目安に分けて伝え、ずれが出たときの連絡手順と順番を繁忙期前に決めておく。
- 電話・FAXの注文もWebと同じ受付台帳に載せ、優先順位は経路ではなく納品希望日の近さで決める。
- 設定でも運用でも足りない部分は、残った手作業を具体的に整理したうえで、改修・追加機能・別手段を費用と効く期間で比べる。
目次

Web受発注で繁忙期に注文が溜まるとき、まず受付から出荷手配のどこで止まっているかを見分ける
繁忙期に入ると、Webの注文が一気に増えます。
納期回答が次の日に持ち越され、「注文は届いているか」「いつ入るのか」という電話も増えます。
電話やFAXで来た注文をシステムへ打ち直す手も足りなくなります。
こうなると、システムの設定を変えるのか、人を増やすのか、受付ルールを見直すのかで迷いがちです。
手を打つ前に、まず受付・在庫引当・納期回答・出荷指示のどこで注文が止まっているかを、自社の注文データと担当者の聞き取りで見分けてください。
止まっている場所が分かれば、設定で変えられることと、締切・優先順位・分担として繁忙期前に決めておくことを分けて考えられます。
注文が止まる4つの段階
Webで受けた注文は、出荷されるまでにいくつかの作業を通ります。
ここでは、受注側の担当者が画面の上で行う作業を、受付・在庫引当・納期回答・出荷指示の4つの段階に分けて考えます。
受付は、届いた注文の品番・数量・納品先・希望日を確かめる段階です。
不明な点があれば取引先へ問い合わせて、処理できる状態にします。
在庫引当(ひきあて)は、その注文のために在庫を確保しておく段階です。
引当を受注した時点で行うか、出荷指示の時点で行うかは、会社の運用やシステムの設定によって異なります。
どちらを採っているかで、後の納期回答の確かさが変わります。
納期回答は、確保できた在庫や入荷予定をもとに、いつ届けられるかを取引先へ返す段階です。
出荷指示は、倉庫や配送の担当へ出荷を依頼し、手配を確定させる段階です。
どの段階も前の段階が終わらないと始められないため、一か所で止まると、その後ろはすべて待たされます。
この4つとは別に、どの段階にも入り込んでくる作業が取引先からの問い合わせ対応です。
「注文は届いているか」「いつ届くか」という電話が増えると、受付や回答の担当者はそのたびに手を止めます。
問い合わせの増加は原因というより、どこかの段階で回答が遅れている兆しです。
問い合わせの件数だけを見て電話番を増やすと、遅れている段階はそのまま残ってしまいます。
自社データと聞き取りで滞留を測る
どこで止まっているかを確かめるには、段階ごとの完了時刻の差を見ます。
注文の到着時刻、内容確認の完了時刻、引当の完了時刻、納期回答の送信時刻、出荷指示の時刻を並べてください。
どの区間が普段より長くなっているかを見れば、滞留している段階が浮かびます。
合計の処理時間だけを見ると、どこで待たされたのかが分かりません。
ここで気をつけたいのは、システムがこれらの時刻を記録しているか、記録していても画面で見られるだけか、データとして取り出して集計できるかは、製品ごとに違うことです。
注文履歴に日時が残っていることと、段階別の経過時間を集計する機能が備わっていることは別の話です。
取り出せるのが一部の時刻だけなら、取り出せる区間から見てください。
記録がない区間は、繁忙期の一部の日だけ担当者が手元の台帳に受け取った時刻と処理を終えた時刻を書き添えるといった方法で補えます。
段階ごとの未処理件数を、毎日決まった時刻に数えておく方法もあります。
時刻の差が取れなくても、受付待ち・引当待ち・回答待ちの件数がどこで積み上がっているかを見れば、滞留の場所はおおよそつかめます。
件数は多いのにすぐ減る段階と、件数は少ないのに残り続ける段階では、打つ手が異なります。
データから分かるのは、どこで待たされているかまでです。
なぜ待たされているのかは、担当者に聞かないと分かりません。
たとえば受付の区間が長い場合でも、品番の書き方が取引先ごとにばらばらで照合に手間取っているのか、納品先の住所が足りず確認の電話をかけているのかで、対策は変わります。
引当の区間が長い場合なら、別の拠点の在庫を電話で確かめているのか、入荷予定の情報がシステムに入っていないのかを聞き分けます。
原因を一つに絞れないとき
実際には、複数の区間が同時に長くなっていることもあります。
このとき、前の段階の遅れが後ろへ伝わっているだけなのか、それぞれの段階で別々に詰まっているのかを分けて見ます。
受付が遅れると、後ろの時刻もすべて後ろへずれます。
しかし区間ごとの差で見れば、引当や回答の区間そのものは普段と変わらないこともあります。
その場合、手を打つのは受付だけで足ります。
区間ごとに見ても複数の段階が長いなら、まず上流の段階から手を付けるのが一つの考え方です。
上流がほぐれると、下流に届く注文の量や届き方が変わり、下流の見え方も変わるからです。
もう一つは、問い合わせを最も多く生んでいる段階から始める考え方です。
どちらを選ぶかは、取引先からの催促がどこに集中しているかで決めてよいでしょう。
注文の種類で分けて見ると、原因が分かれることもあります。
たとえば施工現場への直送を指定した注文と、自社の倉庫や店舗で引き取る注文とでは、確認する項目も手配の段取りも違います。
全体の平均では見えなかった滞留が、片方の種類だけに偏っていることがあります。
取引先ごと、受付経路ごとに分けても同じです。
どうしても一つに絞れないときは、一度に複数の変更を入れないことです。
締切を変え、担当も入れ替え、設定も変えると、何が効いたのかが後から分からなくなります。
変更を一つずつ入れ、同じ時刻の差や未処理件数で前後を比べれば、次の繁忙期にも使える判断材料が残ります。
| 段階 | 比べる時刻 | 区間が長いときに聞くこと |
|---|---|---|
| 受付 | 注文の到着から内容確認の完了まで | 品番・数量・納品先・希望日のどこに不明点が多いか |
| 在庫引当 | 内容確認の完了から引当の完了まで | 在庫や入荷予定をどこで確かめているか |
| 納期回答 | 引当の完了から回答の送信まで | 回答文の作り方、承認の有無、担当の偏り |
| 出荷指示 | 回答の送信から出荷指示まで | 配送手配の締切、倉庫側の受け入れ状況 |
▼ 図の内容を文字で読む
- 受付
- 在庫引当
- 納期回答
- 出荷指示
Web受発注の設定で変えられることと、運用ルール・人員で決めることの分け方
設定で対応する候補
滞留している段階が分かったら、その段階に対して設定と運用のどちらで手を打つかを考えます。
設定で対応できる候補としては、次のようなものが考えられます。
いずれも、自社のシステムで実際に変えられるかどうかは製品ごとに異なります。
- 受付締切の表示:一定の時刻を過ぎた注文を翌営業日の受付として扱い、その旨を注文画面に示す
- 入力項目の必須化:品番・数量・納品先・希望日を入力しないと送信できないようにする
- 納期の自動回答や自動返信:注文を受け付けたこと、または目安の納期を自動で返す
- 在庫の表示:取引先が注文前に在庫の有無を画面で確かめられるようにする
- 担当者への通知:新着の注文や、一定時間処理されていない注文を担当者へ知らせる
受付の区間が長く、その理由が入力の不備による確認の電話なら、入力項目の必須化が候補になります。
品番や納品先が欠けた注文がそもそも届かなくなれば、受付担当が電話をかける回数は減ります。
ただし、品番の書き方が正しいかどうかまで画面で判定できるとは限りません。
照合の手間は残る可能性があります。
問い合わせの多くが「注文は届いているか」という確認なら、受付時の自動返信で減らせる余地があります。
一方、「いつ届くか」という問い合わせは、受付を知らせるだけでは減りません。
納期回答の段階そのものを早めるか、回答の出し方を変える必要があります。
回答の出し方は次の節で扱います。
運用ルールと人員で対応する候補
設定を変えなくても、決めごとと人の配置で動かせる部分は多くあります。
- 処理の優先順位:受付順で処理するのか、納品希望日の近い順にするのか
- 締切の運用:締切後に来た注文をどう扱い、例外を誰が判断するのか
- 担当の分け方:受付と回答を別の人が持つのか、取引先ごとに一人が通して持つのか
- 承認の流れ:納期回答や例外対応に上長の確認を挟むかどうか
- 臨時の担当者:どの段階の作業を任せ、どこから先は社員が判断するのか
納期回答の区間が長く、聞き取りで「回答を出す前に上長の確認を待っている」と分かったとします。
この場合、システムの設定を探す必要はありません。
在庫が引当済みの注文は担当者の判断で回答してよい、と決めるだけで待ち時間がなくなる可能性があります。
反対に、担当者の手が空いていても、引当の情報が画面に出てこないために回答できないのなら、運用ルールだけでは解決しません。
設定と運用を比べるときは、次の3つを見ておくと判断しやすくなります。
一つ目は負担です。
設定の変更は一度入れればすべての取引先に効きますが、テストや取引先への影響の確認が要ります。
運用ルールはすぐに変えられますが、守る人の負担が続きます。
二つ目は前提条件です。
設定ならその機能があること、運用なら人員と周知の時間があることが前提です。
三つ目は確かめ方です。
どちらを選んでも、前の節で見た時刻の差や未処理件数で効いたかどうかを見ます。
設定可否を提供者資料で確認する
設定で対応したい候補が決まったら、自社のシステムで本当にできるかを、提供者のマニュアルや仕様書、サポート窓口で確かめます。
同じ名前の機能でも、製品によって効く範囲が違うためです。
ここで聞く内容を前もって整理しておくと、あいまいな回答で終わらずに済みます。
- その機能が標準で備わっているか、追加の契約が要るか
- 管理画面から自社で切り替えられるか、提供者に作業を依頼する必要があるか
- 繁忙期だけ設定を変え、終わったら戻すことができるか
- 取引先ごとに設定を分けられるか、全取引先に一律で効くか
- 変更が反映されるまでの流れと、事前に試せる環境があるか
特に、全取引先に一律で効く設定には注意が必要です。
受付締切を早めれば、受注側は処理しやすくなります。
しかし、普段は遅い時刻に注文している取引先には不便が生じます。
設定でできると分かっても、取引先への周知と合わせて決める必要があります。
標準の設定では対応できないと分かった場合の考え方は、最後の節で扱います。
| 滞留している段階 | 設定側の候補 | 運用・人員側の候補 | 効いたかの確かめ方 |
|---|---|---|---|
| 受付 | 入力項目の必須化、受付締切の表示 | 締切後の注文の扱い、例外の判断者 | 到着から確認完了までの時刻差 |
| 在庫引当 | 在庫・入荷予定の表示 | 引当の担当と拠点間の確認手順 | 確認完了から引当完了までの時刻差 |
| 納期回答 | 自動回答・自動返信 | 優先順位、承認の要否、担当の分け方 | 引当完了から回答送信までの時刻差、問い合わせ件数 |
| 出荷指示 | 未処理注文の通知 | 配送手配の締切と倉庫との連絡 | 回答送信から出荷指示までの時刻差 |
▼ 図の内容を文字で読む
- 設定で対応する候補
- 入力項目の必須化
- 受付締切の表示
- 自動返信
- 未処理注文の通知
- 運用ルール・人員で対応する候補
- 処理の優先順位
- 承認の流れ
- 担当の分け方
- 臨時の担当者の範囲
- 提供者の資料で確かめること
- 標準で備わっているか、追加の契約が要るか
- 管理画面から自社で切り替えられるか
- 取引先ごとに設定を分けられるか
納期回答と在庫・引当のずれを繁忙期にどう扱うか
確定納期と目安の分け方
繁忙期に混乱を招きやすいのが、回答した納期と実際の出荷がずれることです。
画面上では在庫があると表示されていたのに、引当の時点では別の注文に先に確保されていた。
入荷予定を前提に回答したのに、入荷が遅れた。
注文が集中するほど、表示を見た時点と引当の時点の間に別の注文が入り込む余地は大きくなります。
このずれによる混乱を抑えるには、回答を二種類に分けて伝える方法があります。
一つは確定納期です。
在庫の引当が済み、出荷の手配に目処が立った注文に対して返します。
もう一つは目安です。
在庫表示や入荷予定をもとにした見込みで、変わる可能性があることを添えて返します。
取引先が届け日をもとに現場の段取りを組んでいる場合、確定か目安かが分かるだけで、どこまで予定を固めてよいかを判断できます。
二種類に分ける場合は、目安を確定へ切り替える条件と、切り替える人を決めておきます。
たとえば「引当が完了したら確定として再度連絡する」と決めれば、目安で回答した注文が確定の連絡を受けないまま残ることを防げます。
引当を受注時に行う運用なら、多くの注文は最初から確定で返せるかもしれません。
出荷指示の時点で引当を行う運用なら、最初の回答は目安になる注文が増えます。
自社の引当のタイミングによって、どちらの回答が中心になるかが変わります。
システムの納期欄が一つしかなく、確定と目安を区別して記録できないこともあります。
その場合は備考欄や状態の表示で区別できるかを確かめます。
区別できなければ、回答文の書き方で伝えるしかありません。
いきなり全注文に広げるのではなく、一部の取引先で試してみてください。
確定と目安の区別が実際に伝わっているか、「いつ届くか」の問い合わせが変わるかを見てから広げると安全です。
ずれが出た注文の連絡手順
ずれを完全になくすことは難しいため、ずれが出たときに誰が何をするかを先に決めておきます。
決めていないと、気づいた人が自分で電話をかけたり、誰も連絡しないまま当日を迎えたりします。
その結果、取引先からの問い合わせで初めて社内が把握する、ということが起きます。
手順は次のように組み立てられます。
まず、ずれに気づいた人がその注文の担当者へ知らせます。
担当者は、分納、代替品、別拠点からの出荷など、取引先へ示せる選択肢を確かめます。
そのうえで取引先へ連絡し、どの選択肢を選んだかと新しい納期をシステムや台帳に記録します。
連絡の期限は、社内で決めた時限までなど、具体的に定めておきます。
繁忙期には、ずれが同時に何件も出ることがあります。
そのときの連絡の順番も決めておきます。
納品希望日が近い注文ほど、取引先が段取りを組み直す時間が短くなります。
そのため、気づいた順ではなく納品希望日の近い順に連絡するのが一つの目安です。
記録を残しておけば、どの品目でずれが起きやすかったかを繁忙期の後に振り返る材料にもなります。
▼ 図の内容を文字で読む
- 確定納期
- 在庫の引当が済んでいる
- 出荷の手配に目処が立っている
- 目安
- 在庫表示や入荷予定をもとにした見込み
- 変わる可能性を添えて返す
- 目安を確定へ切り替える
- 引当が完了したら確定として再度連絡する
- 切り替える人を決めておく
電話・FAXが残る場合のWeb受発注との併用整理
受付台帳を一本化する
取引先のすべてがWebで注文するとは限りません。
電話やFAXでの注文が残っていると、受付の段階は二つの山に分かれます。
Webの注文はシステムの画面に並び、電話やFAXの注文は紙やメモに残ります。
担当者は二つを見比べながら処理の順番を決めることになり、どちらかの山を見落とす余地が生まれます。
もう一つ起きやすいのが、在庫の取り合いです。
電話で受けた注文をシステムへ入力する前に、同じ品目のWeb注文が引当を済ませてしまうことがあります。
電話の注文は口頭で在庫ありと伝えていたのに、入力した時点では在庫が残っていない、ということも起こりえます。
経路が分かれていること自体が、前の節で扱った納期のずれの原因になるわけです。
この二重の確認を減らすには、電話・FAXの注文もWebと同じ受付台帳に載せることです。
システムに受注側が代わりに入力できる機能があれば、受けた時点でそこへ入力します。
機能がなければ、すべての経路の注文が一覧で見える共有の台帳を作ります。
一本化すると、二つの山を見比べる確認と、在庫の取り合いによる回答のやり直しは減らせます。
一方で、電話やFAXの内容を打ち込む転記の手間と、打ち込んだ内容に誤りがないかの確認は残ります。
聞き違いや読み違いは、入力の前の段階で起きるためです。
経路ごとの締切と優先順位
台帳を一本化しても、経路ごとに締切と優先順位を決めておかないと、繁忙期には混乱します。
よくある迷いは、電話で急ぎと言われた注文を先に処理するかどうかです。
声をかけてきた取引先を優先し続けると、Webで早めに注文した取引先が後回しになります。
その結果、Webで注文しても早くならないという印象を与えてしまいます。
経路ではなく、納品希望日の近さで優先順位を決めるのが一つの考え方です。
どの経路で来ても同じ基準で並べれば、担当者が経路ごとに判断を変える必要がなくなります。
急ぎの例外を認めるなら、誰が判断するのかも決めておきます。
締切は、全経路で同じにするか、経路ごとに変えるかを決めます。
電話やFAXの注文には転記の時間がかかります。
そのため、Webと同じ締切にすると、締切間際に届いたFAXの処理が翌日にずれ込むことがあります。
経路ごとに締切を変えるなら、その理由を取引先へ説明できるようにしておきます。
取引先への周知
繁忙期のルールは、取引先が知らなければ機能しません。
周知では、繁忙期の締切、確定納期と目安の違い、急ぎの注文の扱い、問い合わせの窓口を伝えます。
Webでの注文をお願いしたい場合は、Webだと転記を経ずに台帳へ載るため回答に取りかかりやすい、という受注側の事情を具体的に説明します。
早くなると約束するのではなく、なぜそうお願いするのかを伝えるほうが、取引先にとっても判断しやすくなります。
Webでの注文がすぐには難しい取引先もいます。
そうした取引先には、FAXの書式を統一してもらう、品番の書き方をそろえてもらうなど、転記で迷う箇所を減らす頼み方もあります。
周知が効いたかどうかは、周知の前後で経路別の注文件数と、電話による問い合わせの件数を比べると分かります。
▼ 図の内容を文字で読む
- 電話・FAXの注文を受けた時点で入力する
- Webと同じ受付台帳に載せる
- 在庫引当と納期回答へ進む
繁忙期前に決める項目、期間中に見る指標、終了後の見直しと、システム対応の限界を見つけたときの選択
繁忙期前に決める項目
ここまでの切り分けを、繁忙期の前・最中・後の順に並べ直します。
前もって決めておくのは、次の項目です。
- 受付締切と、締切後の注文の扱い
- 処理の優先順位と、急ぎの例外を判断する人
- 段階ごとの担当の分け方と、臨時の担当者に任せる範囲
- 確定納期と目安の区別、目安を確定へ切り替える条件
- 納期のずれが出たときの連絡手順と期限
- 電話・FAXの注文を受付台帳へ載せる方法と、経路ごとの締切
- 取引先への周知の内容と時期
- 変更する設定と、そのテストの方法
設定の変更と取引先への周知は、繁忙期に入ってからでは間に合わないことがあります。
設定は試してから本番へ反映する時間が要りますし、周知は取引先が読んで社内に伝えるまでの時間が要ります。
決める順番としては、まず優先順位と担当の分け方を決めます。
それに合わせて設定と周知の内容を固めていくと、後から食い違いが出にくくなります。
期間中に見る指標
繁忙期の最中に見る指標は、多くしすぎないほうが続けられます。
段階別の滞留件数、回答の遅れた件数、問い合わせの件数、経路別の注文件数があれば、何が起きているかはおおよそ読み取れます。
大切なのは、指標を組み合わせて読むことです。
問い合わせが増え、同時に回答の遅れも増えているなら、納期回答の段階が詰まっている可能性が高いと考えられます。
問い合わせは増えているのに回答の遅れは増えていないなら、回答は出ているのに取引先に伝わっていないか、目安と確定の区別が分かりにくい可能性があります。
この場合は、回答の伝え方や画面の表示を見直します。
引当待ちの件数だけが積み上がっているなら、在庫の確認方法か入荷情報の取り込みを疑います。
問い合わせは件数だけでなく、内容でも分けて数えておくと役立ちます。
「届いているか」「いつ届くか」「内容を変えたい」のどれが多いかで、手を打つ段階が変わります。
電話を受けた人が一言の分類を残すだけでも、後から読み取れることは増えます。
終了後の振り返り
繁忙期が終わったら、事前に決めたことが守れたか、守れなかったならなぜかを振り返ります。
あわせて、期間中に起きた滞留を、設定で直せたもの、運用ルールや人員で直せたもの、どちらでも足りなかったものに分けます。
この分類が、次の繁忙期の準備の出発点になります。
振り返りでは、記録が取れなかった項目も書き残しておきます。
引当完了の時刻が記録されていなかった、問い合わせの内容を分類できなかった、といったことです。
次の繁忙期の前に、その時刻を記録する手段を用意するか、その区間は聞き取りで補うと決めておけます。
改修・追加機能・別手段の検討
振り返りで、設定でも運用でも足りなかった部分が残ることがあります。
その場合の選択肢は、大きく三つです。
システムを自社向けに改修する、提供者が用意している追加の機能を契約する、システムの外の手段で補う、のいずれかです。
外の手段とは、別の管理ツールで台帳を補ったり、特定の作業に人を充てたりすることです。
費用の面では、SaaS型(インターネット経由で利用するサービス型)のシステムでオプションを追加したり独自のカスタマイズを行ったりする場合は、別途費用がかかるという説明があります1。
これはある事業者の解説記事での説明であり、どの製品でも同じ条件とは限りません。
費用の有無や範囲は、自社の契約と提供者への見積もり依頼で確かめることになります。
検討を進める前に、振り返りの記録から、どの段階で、どの手作業が、どの程度残っているかを整理しておきます。
「繁忙期に回答が遅れる」というだけでは、提供者もどの機能が必要かを判断できません。
「電話・FAXの注文の転記と、その後の引当のやり直しに手がかかっている」まで具体的になれば、話が変わります。
代わりに入力する機能や在庫表示の改善が候補になるのか、運用で補うほうが合うのかを比べられるようになります。
繁忙期は一年の一部の期間です。
そのため、改修や追加の費用が、繁忙期だけの人員の手当てや運用の工夫と比べて見合うかも考えどころです。
通年で効く改善なら、繁忙期以外の作業も軽くなります。
繁忙期にしか効かない改善なら、期間限定で設定を切り替えられる手段や、人員で補う手段と並べて判断するほうが無理がありません。
▼ 図の内容を文字で読む
- 繁忙期前:優先順位・担当の分け方・設定・周知を決める
- 期間中:滞留件数・回答の遅れ・問い合わせ・経路別件数を見る
- 終了後:設定で直せたもの、運用で直せたもの、どちらでも足りないものに分ける
▼ 図の内容を文字で読む
- 問い合わせも回答の遅れも増えている
- 納期回答の段階が詰まっている可能性が高い
- 問い合わせだけ増えている
- 回答の伝え方を見直す
- 目安と確定の画面表示を見直す
- 引当待ちの件数だけが積み上がっている
- 在庫の確認方法を疑う
- 入荷情報の取り込みを疑う
どの段階で注文が止まっているかが見えても、自社のシステムの設定でどこまで変えられ、どこから運用ルールで補うかは、仕様と業務の流れを並べて見ないと判断しにくいところです。
いまの設定と注文の流れを一緒に見ながら、滞留している段階ごとに、設定の見直しで扱えそうな部分と、締切や分担として決める部分を整理するきっかけにできます。無料相談で要件を整理する
要点の整理
| 軸 | 基準 |
|---|---|
| 滞留の場所 | 受付・在庫引当・納期回答・出荷指示の区間ごとの時刻差と未処理件数で見る |
| 滞留の理由 | 時刻の差では分からないため、担当者の聞き取りで補う |
| 設定か運用か | 負担・前提条件・確かめ方で比べ、設定の可否は提供者の資料で確かめる |
| 納期の伝え方 | 引当済みの確定納期と、見込みの目安を分けて伝える |
| 電話・FAXとの併用 | 全経路を一つの受付台帳に載せ、優先順位は経路ではなく納品希望日で決める |
| 期間中の指標 | 滞留件数・回答遅れ・問い合わせ・経路別件数を組み合わせて読む |
| 限界が見えたとき | 残った手作業を具体的に整理し、改修・追加機能・別手段を費用と効く期間で比べる |
繁忙期の振り返りで設定でも運用でも足りない部分が残ったとき、改修・追加機能・別手段のどれが自社に合うかは、残っている手作業の中身によって変わります。 振り返りの記録をもとに、どの段階のどの作業が残っているかを具体的にし、どの手段を比べればよいか、提供者へ何を確かめればよいかを整理できます。
よくある質問
繁忙期の前、いつ頃から準備を始めればよいですか。
決まった時期はありませんが、繁忙期の始まりから逆算して決めるのが現実的です。
逆算の材料になるのは、設定の変更を試して本番へ反映するまでの期間と、取引先へ周知して先方の社内に伝わるまでの期間です。
前回の繁忙期の振り返りで、記録が取れなかった時刻や分類できなかった問い合わせがあった場合は、記録の手段を用意する時間も加えてください。
電話・FAXの注文をWebへ誘導するとき、取引先にどう伝えればよいですか。
Webに変えてほしいとだけ伝えるより、受注側の事情を具体的に説明するほうが伝わります。
たとえば、Webの注文は転記を経ずに受付台帳へ載るため回答に取りかかりやすいこと、繁忙期の締切や確定納期と目安の違いをあわせて伝えます。
早くなると約束するのは避けてください。
Webが難しい取引先には、FAXの書式や品番の書き方をそろえてもらうなど、転記の迷いを減らすお願いに切り替える方法もあります。
納期回答を自動化すると、どんな注文で問題が出やすいですか。
自動の回答は、画面上の在庫や入荷予定の情報をもとに出ることが多いと考えられます。
そのため、その情報と実際の引当の状態が離れやすい注文で、ずれが出やすくなります。
たとえば、同じ品目に注文が集中している場合、入荷予定を前提にしている場合、別の拠点の在庫を使う場合などです。
自動の回答を目安として伝え、引当が済んだ時点で確定として連絡し直す運用にすると、取引先がどこまで予定を固めてよいかを判断しやすくなります。
自社のシステムが何をもとに回答を出しているかは、提供者の資料で確かめてください。
繁忙期だけ臨時の担当者を置く場合、Web受発注の権限や教育で何を決めればよいですか。
まず、どの段階の作業を任せるかを決めます。
受付の内容確認や電話・FAXの転記は任せ、納期回答や例外の判断は社員が行う、といった分け方です。
そのうえで、任せる作業に必要な画面だけを操作できる権限を用意できるかを、システムの仕様で確かめます。
教育では、操作手順に加えて、優先順位の基準と、迷ったときに誰へ聞くかを伝えておくと、判断待ちで手が止まることを減らせます。
在庫表示を取引先に見せている場合、引当のずれが出たときの連絡はどうすればよいですか。
在庫表示を見て注文した取引先は、在庫があるものと受け止めています。
そのため、ずれが出たときは早めの連絡が欠かせません。
連絡の手順は、本文で示したように、担当者が分納・代替品・別拠点出荷などの選択肢を確かめ、納品希望日の近い注文から取引先へ伝える形が基本です。
あわせて、画面の在庫表示は注文時点の見込みであり、引当の時点で変わることがある、と事前に周知しておくと、ずれが出たときの受け止め方が変わります。
画像の出典元
- A businessman in a suit reviewing data charts at his office desk./Photo by RDNE Stock project on Pexels