Web受発注を取引先が使ってくれない時の現実解
Web受発注が定着しない理由を分け、FAX・電話を残したまま受注データを合流させる方法、入れ替え判断、導入前の確認項目を解説します。
Web受発注を導入しても、すべての取引先が同じ時期に利用を始めるとは限りません。店舗では注文時に共用パソコンを使えない、工場では担当者が紙の在庫表を見ながら注文する、本部承認が必要、商品を検索しても取引先の呼び方と一致しない、といった事情があります。未利用を取引先の意欲だけで説明すると、案内回数は増えても受注方法は変わりません。
受注側で重要なのは、Web利用を促す施策と、残ったFAX・電話を処理する設計を分けることです。Web、FAX、電話の入口が併存しても、登録前に一つの受注データへ合流できれば、出荷や請求は共通の流れへ渡せます。この記事では、使われない理由の確認、催促が機能しない構造、チャネル別の合流方法、システムを入れ替える条件を実務の順に整理します。
FAX受注の整理に使える資料
AI受注さんの仕組みと提供内容をまとめたサービス資料をご覧いただけます。
サービス資料をダウンロードWeb受発注の定着が進まない現実
定着を判断するときは、アカウント発行数や説明会の参加数だけを見ません。ログイン済み・商品を選べた・注文を確定できた・同じ取引先の別担当者も使えた・訂正注文を処理できた、という利用段階を分けます。登録済みでも、次の発注時にFAXへ戻っていれば、日常業務へは定着していません。
一社の中でも拠点や担当者によって利用状況が違います。本部はWebを承認していても、店舗の発注担当者へIDが届いていない場合があります。日中の追加注文だけ電話になる、通常商品はWebだが特注品はFAXになる、といった分かれ方もあります。会社単位の利用・未利用だけでは、残る受注作業を把握できません。
残作業を記録する
受注担当がWeb注文を印刷して別の画面へ入力しているなら、取引先がWebを使っても転記は残ります。反対に、FAXが残っていても受信後にデータ化され、Web注文と同じ形式で基幹システムへ渡せるなら、受注側の流れはそろえられます。評価項目をチャネル比率だけにせず、確認・転記・重複確認・問い合わせにかかる作業へ置きます。
使ってくれない取引先に共通する4つの理由
1．注文する場所に端末や個別アカウントがない
発注担当者が在庫棚や調理場で数量を確認し、その場のFAXで注文している場合、事務所のパソコンへ移動する手順が増えます。共用端末ではパスワードを保管できない、個人のスマートフォンを業務に使えない、メールアドレスが部署に一つしかないこともあります。利用環境を確認せずIDだけを追加しても、注文時の動線に入りません。
2．取引先の呼び方で商品を探せない
FAX注文書では、取引先独自の略称・規格・荷姿で商品が書かれています。Webの商品名が自社の正式名称だけなら、担当者は品番表や過去の注文を見直します。候補が多い。終売品が表示される。契約していない商品まで見える。こうした状態も選択を難しくします。取引先別の商品表示と履歴注文を確認します。
3．承認・締め・訂正の手順が合わない
注文前に店長の印をもらう。複数店舗分を本部がまとめる。締め時間後の追加を電話で伝える。取引先には、こうした注文確定までの手順があります。Web上で下書き・承認・複数納品先・訂正を扱えない場合、FAXの方が社内手順に合います。単に画面を説明するのではなく、注文を作る人・承認する人・送る人を確認します。
4．変更する利点より移行作業が先に見える
取引先から見ると、利用登録・パスワード管理・商品検索の学習が増える一方、現在のFAXでも注文は成立しています。受注側の入力負担を理由にしても、相手側の作業が減るとは限りません。受付完了を確認できる。注文履歴を再利用できる。訂正状況が分かる。実際に提供できる機能を、操作の場面で示します。提供できない利点は案内文へ足しません。
「催促する」で解決しようとすると失敗する理由
未利用先へ同じ案内を繰り返すと、連絡履歴は増えても障害は残ります。ログインできない取引先へ利用期限を再通知しても、端末やアカウントの問題は解けません。商品が見つからない取引先へ操作資料を送り直しても、商品マスタが変わらなければ次の注文もFAXになります。催促前に、止まった操作と担当者を記録します。
案内済みを対応済みにしない
管理表は、案内日ではなく、受領確認・登録・初回ログイン・初回注文・継続利用の状態を持たせます。未利用理由には、担当者不明・承認待ち・環境なし・操作不明・商品不明・機能不足・連絡不能を設定します。次の行動を、再案内・電話支援・営業確認・マスタ修正・例外継続に分けます。
利用を営業評価や取引条件と結び付ける場合は、受注担当の判断で進めません。取引先との契約、案内期間、注文を受けられない場合の影響を責任者が確認します。現場では、未利用の理由を集めて仕組みへ戻すことと、届いた注文を締め時間までに処理することを分けます。
残ったFAX・電話をどう処理するかが分岐点
Webを使わない取引先が残ること自体より、FAXと電話を別台帳で処理することが受注業務を分けます。Web注文は自動登録、FAXは手入力、電話は付箋。この状態では、処理済みの確認・締め時間・訂正の履歴がチャネルごとに異なります。担当者は複数の受信箱と紙を見回り、出荷側はどれが最新か確認する必要があります。
登録前の形式を統一する
取引先へ一つの入口を強制できない場合でも、社内の合流点は作れます。Web注文は項目データを取得し、FAXは画像から必要項目を抽出し、電話は担当者が共通入力画面へ記録します。すべてに、受付時刻・取引先・注文番号または識別情報・商品・数量・納品日・元の連絡を持たせます。
電話注文は聞き取り内容を復唱し、誰から受けたか、折り返し確認の有無まで記録対象です。FAXは再送と訂正版を区別し、元画像へ戻れるようにします。Webは取引先が確定した注文だけでなく、下書きや取消しの状態を取り込まないようにします。チャネル別の注意を処理した後、共通の受注一覧へ渡します。
未処理を見つける方法も、そろえる対象です。Webだけ通知があり、FAXは紙の山、電話は担当者のメモ。この状態では、締め時点の確認ができません。受付済み・内容確認中・取引先確認中・登録済み・出荷連携済みの状態を共通化し、締め時間前に未完了だけを確認します。
併用前提で受注フローを設計する
併用設計では、各チャネルをそのまま基幹システムへ入れず、確認済み受注データという合流ポイントを置きます。合流前にチャネル固有の処理を行い、合流後は同じ商品コード・数量単位・納品日形式・得意先コードを使います。これにより、出荷・請求・集計側は入口を意識せず同じデータを扱える形です。
| 受注チャネル | 受付方法 | 合流前の処理 | 共通の合流ポイント |
|---|---|---|---|
| Web受発注 | 確定注文データを取得 | 注文状態、商品コード、納品先を確認 | 確認済み受注データ |
| FAX | 紙または画像・PDFで受信 | 再送確認、項目抽出、商品・数量の照合 | 確認済み受注データ |
| 電話 | 共通入力画面へ聞き取り記録 | 復唱、発注者、折り返し、例外条件を確認 | 確認済み受注データ |
| メール | 本文・添付注文書を受信 | 添付漏れ、版、注文確定の意思を確認 | 確認済み受注データ |
重複と訂正をチャネル横断で確認する
Webで送った後にFAXで控えを送る取引先や、電話で訂正を伝える取引先があります。チャネル内だけで重複を探すと別注文になります。取引先・注文番号・注文日・納品日・明細を使って候補を示し、元の注文へ訂正を反映します。自動で同一と判断できない場合は、元データを並べた担当者の確認が必要です。
取引先別ルールには、通常の注文チャネル・緊急時の連絡・訂正方法・控えFAXの有無を記載します。受注担当の経験だけに置かず、営業が新しい注文方法を合意したときに更新します。併用を暫定対応と決める場合も、終了日と終了条件を残します。
システムを入れ替えるべきケース／入れ替えなくていいケース
入れ替えを検討するのは必要な処理を機能で表せないとき
複数納品先・取引先別商品・承認・訂正・締め時間・在庫表示など、利用に必要な処理が現行システムで扱えず、設定や運用でも補えない場合は入れ替えを検討します。確定注文を外部へ出せない。受注状態を取得できない。権限を拠点別に分けられない。こうした社内の合流設計を妨げる制約も対象です。
入れ替え前には、現行でできない操作を取引先の注文例で示します。「使われない」だけでは要件になりません。どの取引先が、どの注文で、どの画面や手順で止まり、代わりに何を使ったかを記録します。次のシステムでは、その操作をデモ用商品ではなく自社の商品・納品先で試します。
入れ替えなくてよいのは原因が運用とデータにあるとき
IDが担当者へ届いていない。商品マスタが不足している。説明が管理者だけに行われた。FAX注文の合流先がない。こうした原因は、システムを替えても繰り返します。アカウント配布・取引先別商品・初回注文支援・共通受注一覧を整え、現行機能で注文完了まで進めるかを確認します。
Web利用を全社目標にしていても、注文頻度が低い取引先や利用環境がない取引先は残せます。入れ替えの判断には、未利用社数だけでなく、残ったチャネルを処理する作業・機能不足で失う注文・データ連携の手直しも判断材料です。
導入前チェックリスト
新規導入でも入れ替えでも、取引先向け画面だけでなく、利用しない取引先を含む受注全体を確認します。次の項目を、自社の実際の取引先・商品・注文書・締め時間で試します。回答が未定の項目は、導入後に受注担当が個別判断する作業として残ります。
- 取引先の注文担当者が使える端末、メール、アカウントの条件を確認したか
- 取引先別の商品、価格条件、荷姿、納品先だけを適切に表示できるか
- 略称や過去の注文履歴から商品を選べるか
- 下書き、承認、確定、取消し、訂正の状態を区別できるか
- 締め時間後、欠品、代替品、特注品の連絡方法を決めたか
- Webを使わない取引先のFAX・電話・メールをどこへ合流させるか
- チャネルをまたぐ再送、控え、訂正、重複注文を確認できるか
- 確認済みデータを既存の受注・出荷・請求システムへ渡せるか
- 利用状況を会社だけでなく拠点・担当者・注文種類で確認できるか
- 問い合わせ、マスタ修正、例外承認の社内担当と期限を決めたか
- 未利用理由と次の対応日を記録する項目を用意したか
- 併用を終了する条件、または継続する例外の見直し日を決めたか
試行期間には、Webで完了した注文だけでなく、途中でFAXや電話へ戻った注文も確認対象です。戻った理由を機能・商品データ・権限・操作・取引先の社内手順に分けます。受注担当が出力後に列を直した場合も記録し、合流後のデータが既存システムで使える状態かを見ます。
Web受発注の定着に関するよくある質問
- Web受発注を使わない取引先へ何回案内すればよいですか？
- 回数だけを決めるのではなく、ログインできない、商品を探せない、承認手順に合わないなど未利用の理由を記録します。同じ案内を繰り返すより、理由ごとに操作支援、マスタ修正、FAX継続を判断します。
- FAXとWebを併用すると二重受注が増えませんか？
- 受付番号、取引先、注文日、納品日などを使って、チャネルが違っても同じ受注一覧へ合流させます。訂正や再送の扱いをそろえ、登録済みかを確認してから基幹システムへ渡す流れにします。
- 利用率が低い場合はシステムを入れ替えるべきですか？
- 未利用の原因が操作や商品マスタにあるのか、受注側の併用設計にあるのか、必要機能の不足にあるのかを分けます。現行機能で原因を解けない場合は入れ替えを検討し、運用で解ける場合は合流工程を先に直します。
Webへ移らないFAX注文を自社側でデータ化し、Web注文と同じ受注フローへ合流させる方法もあります。AI受注さんでは、FAXの元帳票を確認しながら商品・数量・納品日などを整え、既存システムへ渡すデータを作ります。