注文例外の調整
例示ユースケースであり、顧客事例ではありません。
CRMと受注処理の情報から、停滞した注文の共有ビューを作ります。欠けている手順を特定し、権限を持つ担当者が承認するタスクを提案します。
課題
注文が止まると、顧客は営業に電話し、営業はオペレーションに電話し、オペレーションはERPを確認する。誰も全体像を持っておらず、実際に何ができるかを確認する前に約束がなされてしまう。
現在の進め方
停滞した注文は、顧客が苦情を言うか、レポートが実行されたときに気づかれます。営業の誰かがCRMを確認し、オペレーションの誰かがERPで注文と配送の状況を確認し、二人がチャットで情報を突き合わせます。対応は口頭で合意され、その人がたまたま使っているシステムで追跡されます。
シナリオを見る
簡単な概要
ワークフローの例示です。字幕付き。
文字起こし
- ある注文がCRMでは出荷済み、ERPでは保留と表示されています。顧客から電話が入り、三つのチームが同じ事実をメールで追いかけ始めます。
- ワークフローは営業と納品の状況を集め、欠けているステップとその責任者を特定し、調整のためのタスクを提案します。
- 権限を持つ責任者が注文変更と顧客への約束を承認します。結果は両方のシステムに記録されます。
- 測定するのは解決時間と例外あたりの手作業の回数です。例示ユースケースです。貴社のケースについてご相談ください。
詳細なシナリオ
例示シナリオ。 架空の注文一件に、三つの異なる答え。共有された情報と指名された責任者が、システムをまたぐ例外を、調整された一つの次のステップに変えます。 1:14
文字起こし
- 顧客が、注文はどこかと尋ねます。営業から見ると出荷済み、納品チームから見ると保留中です。サービスには、どちらの説明もありません。
- 各チームが同じ事実を追いかけ始めます。メッセージは増えていきますが、調整された次のステップを担う人は、まだいません。
- 調整のワークフローが、許可された営業と納品の情報を一つにまとめます。どちらのステータスが正しいかを推測せず、食い違いを明らかにします。
- 欠けている確認とその責任者を特定し、例外の解決に必要なタスクを提案します。
- 注文の変更や顧客への約束は、権限を持つ責任者が承認します。顧客への連絡には、検証済みの判断が反映されます。
- 結果は両方のシステムに記録されます。測定するのは、解決までの時間と例外あたりの手作業の回数です。最初につなぐべきは、どの引き継ぎでしょうか？
- [エンドカード] 最初につなぐべきは、どの引き継ぎですか？ システムをまたぐワークフローについて相談する. qxorbit.ai/ja/contact
- 例示ユースケースであり、顧客事例ではありません。
提案するワークフロー
- 想定されるステータス遷移を逃した注文を検出する
- CRM上の約束、ERPの注文と納品の状況、未解決のケースを集める
- 欠けている、または失敗したステップと、その責任者を特定する
- 営業とオペレーションにまたがる一連のタスクを提案する
- 提案する注文変更や顧客への約束を、権限を持つ責任者の承認のために提示する
- 結果をCRMとERPの両方のレコードに記録する
人が判断を担う箇所
- 注文変更や顧客への約束は、権限を持つ責任者が承認する
- タスクの提案は、受け入れられる前に営業とオペレーションの双方に見える
- 自動検出は注文データを変更しない。検知してルーティングするだけである
プラットフォームの対応付けは、この構想を評価しうる環境を示すものです。実際の実装は、設定、ライセンス、API、データ、権限によって異なります。効果は定性的に記載しており、数値による主張には文書化されたベースラインが必要です。