3PL カスタマーサービスAI Copilot 導入プレイブック:追跡対応、配送変更、異常報告で通話量を4割削減する実装方法

国際物流3PLを扱うあるクライアントの話だ。ピーク時の2ヶ月間、カスタマーサービス担当者は毎日600件の電話対応をしていた。我々は現場に3日間張り込んで、1件ずつ通話にタグを付けていった。結果は興味深かった。接近する半分の通話内容が、スタッフが口にする言葉がほぼ完全に同じなのだ——「確認させていただきます」「ご注文番号は」「既に配分センターに到着しています」。人間が座っているが、実は単なる照会システムの役割を果たしているに過ぎなかった。

これが我々のロジスティクス・カスタマーサービスAI導入のスタート地点だ。最初に「AI に何ができるか」を問うのではなく、先に「あなたのコール業務はどうなっているか」を問う。なぜなら3PLのカスタマーサービスは一般的なEC顧客サービスと異なるからだ。荷主(shipper)、配送先、プラットフォーム——三者が電話をかけてくる。聞かれることは高度に構造化されているが、複数のシステムにまたがっている——WMS、TMS、キャリアAPI、自社の注文データベース。通話量を削減できるかどうかは、これらのシステムをCopilotが一つの統合インターフェースで読み書きできるか否かにかかっている。

まずAIは置いておいて、通話業務を分析する

我々のやり方は、導入前に必ず2週間のコール業務調査を実施することだ。音声から逐語録、主題タグ、感情タグ、「この通話に人間が必要か否か」のタグを付ける。3PLのコール業務は通常こうしたカテゴリーに分かれるが、自動化の難易度はまったく異なる:

この表を展開すると、「4割削減」という目標はスローガンから実際に計算可能な数字へと変わる。追跡対応だけで8割の自動化を達成すれば、全体のコール量は既に3割程度削減される。そこに配送変更のうち構造が明確な半分を乗せれば、4割に達する。これは楽観的な見通しではなく、我々が2つの3PLプロジェクトで実際に達成した数値だ。

追跡対応はサービス点だが、サービス点でもミスは起きる

追跡対応が比較的簡単な理由は、読み取り専用だからだ——Copilotが照会して明確に説明さえできれば、システムのデータには一切触らないため、リスクが低い。我々のアプローチは、Copilotを3つのデータソースに直接接続させることだ。内部の注文データベースから番号と商品情報を取得、WMSから出庫状態を取得、キャリアAPIから最後の配送ルートの軌跡を取得。ユーザーがLINE、Webサイト、電話のいずれで「荷物はどこにあるか」と聞いてきても、システムは「昨日18:40に桃園分配センターに到着、明日午前中の配送予定、担当ドライバーはクロネコです」と返答する。

しかし我々が踏んだ地雷について、同業各位に先行事例として共有したい。キャリアの配送軌跡は時々更新が遅延する、あるいは状態コードの意味が一貫していない場合がある(例えば「配送中」という同じ表現でも、キャリアによって実際の意味が半日異なる)。初期版では我々はAIに状態コードをそのまま読み上げさせていたが、その結果、配送先が「配達完了」という誤った情報に導かれ、実は荷物がまだ車の上にあって、かえって苦情が増えてしまった。その後、我々はルール層を追加した——状態のタイムスタンプが一定の閾値を超えている、あるいは複数のソースデータが矛盾している場合、Copilotは自分で結論を下さず、代わりに「システムには…と表示されていますが、ドライバーに確認してからご返答させていただきます」と言って、同時にチケットを作成する。保守的であることは、自信を持って間違える よりも良い。

配送変更と異常報告:自動化の真の分岐点

配送変更から先は書き込み処理が入ってくる。ここが設計上最も注意を要するところだ。我々の原則は「出庫ノードを信号機として機能させる」ことだ。まだ商品が選別されていない段階なら、住所変更や配送時間帯変更をCopilotがTMSに直接書き込んで即座に反映させる。しかし一旦選別処理に入ったか、既に車に積まれたなら、あらゆる変更を人工対応に切り替える。なぜなら、この段階での変更は経路、送料、場合によっては返送に波及する可能性があるからだ。この線をどこに引くかは、運用チームと一緒に決める必要がある——エンジニアが単独で判断してはいけない。

異常報告が最も難しいが、それゆえ最も取り組む価値がある。難しい理由は責任判定と感情的な対応が必要だから。取り組む価値がある理由は、AIが案件を完全に解決できなくても、時間を要する「案件作成」というステップを完了させることができるからだ——破損写真、番号、商品、期待される処理方法を聞き取り、構造化されたチケットとして適切な人に渡す。カスタマーサービス担当者が引き継ぐ時点で、前の5分間の問答はもう省略されている。我々が計測したところ、この種の通話でも3～4割の自動化に留まっても、平均処理時間(AHT)は2割以上削減される。

人機分流:人員を排除することではない

導入後の成否を本当に決めるのは、Copilotの知能そのものではなく、エスカレーション設計だ。我々は各3PLプロジェクトに対して、人工対応への転送を決める3つの硬い基準を設ける。1つ目は、感情検知が明らかな不満を検出したら即座に転送する——AIに無理させない。2つ目は、同じ問題についてAIが2回往復しても解決できなければ転送する。3つ目は、金額、補償、契約に関わる一切は直接転送する。転送する際は、対話全体の背景コンテキストを一緒に引き継ぐことが重要だ。カスタマーサービス担当者が「ご注文番号を教えていただけますか」と改めて聞き直す必要がないように——このハンドオーバー体験がうまくいかないと、顧客は全体システムへの信頼を瞬時に失う。

本番稼働開始から1四半期後、そのクライアントのコール量は約43%削減された。カスタマーサービスチームはリストラせず、節約した人員を主動的な異常ケアに充てた。配送が遅延したら、荷主に主動的に電話し、相手が怒って電話してくるのを待たない。これが我々が見たいものだ。AIが反復的な業務を引き継ぎ、人間が人間にしかできない仕事をする。

我々がよく言う一言に立ち戻ろう。デモがきれいなだけではカウントされない、本番稼働して実際に使われることが真の数字だ。だからTentenでは、ロジスティクス・カスタマーサービスAI導入は常にモデルから始まるのではなく、まずあなたのコール業務に張り込み、自動化可能な比率を正確に計算し、その後カテゴリー毎に本番システムに接続する。エンジニアを現場に留めて、実際の利用率が本当に立ち上がるまで待つ。これは遅いやり方だが、本当に残る唯一のアプローチだ。