本文へ移動
日系自動車メーカー — アジア太平洋地域統括会社

ディストリビューターからの部品問い合わせを適切な輸出元へ自動で振り分け

地域統括会社では、ディストリビューターから届く部品の問い合わせを担当者が1件ずつ適切な輸出元へ振り分け、誤って届いたものは転送していました。私たちはZendeskとAWSでポータルを構築し、地域統括会社のデータウェアハウスから振り分け先を照会し、各チケットを適切な輸出元グループと担当者に割り当てる仕組みを整えました。本番稼働後も改善を続けており、2025年6月から2026年5月までに7回の本番リリースを行っています。

37

3つの輸出元グループへ自動で振り分けるバイヤーコード数

7

2025年6月から2026年5月までの本番リリース回数

自動車・モビリティカスタマーサクセス基盤分析・ダッシュボードマネージドサービス複数のディストリビューター市場2024年 – 2026年読了目安 5分
顧客
日系自動車メーカーの地域統括会社(アフターセールス部品部門)
利用者
ディストリビューターのバイヤー(6アカウント、37バイヤーコード)と、3つの輸出元グループの担当者15名
範囲
要件定義・Zendeskの設定とカスタムアプリ・AWSの振り分けAPI・テスト・本番稼働・改善
期間
2024年11月に開始 → 2025年6月に本番稼働 → 2026年3月に改善リリース
体制
プロジェクトマネージャー、業務アナリスト、ソリューションアーキテクト、バックエンドエンジニア、テスター
4

1つのフォームで受け付ける問い合わせの種類(ETD、部品情報、物流品質の不具合報告、その他)

3

輸出元グループ。グループごとにチケットの表示と権限を設定

75

ETD問い合わせ1件でExcelから一括登録できる部品番号の上限(性能テストに基づき設定)

課題

問い合わせを1件ずつ人が読み、回答者を判断

地域統括会社には、ディストリビューターから部品に関する問い合わせが日常的に寄せられます。注文の出荷予定日(ETD)、部品番号の正誤、欠品や梱包の破損といった物流品質の不具合などです。どの問い合わせを3つの輸出元グループのどこが担当するかは、部品番号・注文番号・請求書番号と、問い合わせ元のディストリビューターによって決まります。

ポータルの第1段階では、ディストリビューターがオンラインで問い合わせを送れるようになっていました。しかし、輸出元の担当者は引き続き振り分け情報を手作業で確認し、チケットを自分で割り当て、誤って届いたチケットはメールで転送していました。

手作業による振り分け

担当者が問い合わせごとに回答者を調べ、誤って届いたものは転送していました。

複数の輸出元にまたがる問い合わせ

ETDの問い合わせには担当グループの異なる部品番号が多数含まれることがあり、回答を1つにまとめる必要がありました。

対応状況が見えない

初回回答待ちのチケットや、長期間未解決のチケットを一貫して把握する方法がありませんでした。

アプローチ

地域統括会社が持つ振り分けデータを活用し、現場の業務に沿ったポータルを構築

ディストリビューター向けのヘルプセンター、問い合わせフォーム、輸出元の作業画面はZendeskで提供しています。ディストリビューターが問い合わせを送信すると、地域統括会社のAWSアカウント上のサーバーレスAPIが、別のパートナーが構築・運用するデータウェアハウスの振り分けAPIを呼び出します。そのうえで、Zendeskに設定した各輸出元のスキルに基づき、チケットを適切な輸出元グループと担当者に割り当てます。部品番号に誤りがある場合や添付ファイルが不足している場合は、チケットを取り消し、理由を説明するメールを送ります。ディストリビューターはすぐに修正して再送信できます。

複数部品のETD問い合わせでは、ディストリビューターのExcelファイルを輸出元ごとに分割し、それぞれの輸出元のチケットに添付します。回答は地域統括会社のチームが1つにまとめて返信します。

ZENDESK 地域統括会社・AWS パートナーが管理 ディストリビューターヘルプセンター・問い合わせ チケット作成部品・注文・請求書番号 グループ・担当者を割当輸出元のスキルで判定 3つの輸出元グループ回答・リマインド Explore + CSV地域統括会社向けKPI DynamoDBログはCloudWatch API Gateway + Lambda検証・振り分け・分割 振り分けAPIデータウェアハウス・部品別
ディストリビューターが操作するのはZendeskのヘルプセンターだけです。地域統括会社のAWSアカウント上のサーバーレスAPIが、データウェアハウスの振り分けAPIを呼び出してチケットを割り当てます。複数部品のETD問い合わせでは、Excelファイルを輸出元ごとに分割します。

要件定義・設計

2024年11月 – 2025年1月
  • 2024年11月25日にキックオフ。役割、チケットのステータス、問い合わせフォーム、業務手順(SOP)、振り分けAPI、メールドメイン、担当者ビュー、KPIについて、1週間にわたり連日ワークショップを実施
  • 地域統括会社のセキュリティ・ネットワーク指針に沿ってAWS構成を設計
  • 2025年1月にデータウェアハウスのパートナーとAPI接続テストを実施

構築・テスト

2025年2月 – 5月
  • まず単一部品の問い合わせフロー、次に複数部品のExcelフローを構築
  • 輸出元とディストリビューターのバイヤーによるシステムテストと受入テスト
  • 2025年5月に1件あたり部品番号50–125件で性能テストを行い、上限を75件に設定

段階的な本番稼働

2025年6月 – 8月
  • 2025年6月6日、7月14日、8月6日にリリース
  • 稼働後、3つ目の輸出元グループへの振り分けを追加し、エラーメッセージをわかりやすく改善
  • 2025年8月の課題レビューで、想定外の振り分け結果の原因がデータウェアハウス側にあることを特定

改善

2025年9月 – 2026年6月
  • 2025年9月・10月に新しいバイヤーとメールドメインのルールを追加
  • 2026年3月26日の改善リリース:リマインドと自動クローズ、CSV出力用のカスタムアプリ、CC通知、Exploreの新しいグラフ、振り分けマトリクスと輸出元スキルの更新
  • 2026年5月に追加リリース。地域統括会社のチームとの定例会議を継続
成果

問い合わせは適切な担当者に届き、各案件の状況は地域統括会社が把握

導入前担当者が振り分け先を手作業で確認し、適切な担当者へメールを転送
解決策部品・注文・請求書番号とバイヤーコードで振り分けAPIを照会し、輸出元のスキルに基づいて割り当て
結果送信と同時に、適切な輸出元グループと担当者へチケットを割り当て
導入前多数の部品を含むETD問い合わせを分割し、各輸出元に個別に確認
解決策アップロードされたExcelを輸出元ごとに自動で分割し、各グループのチケットに添付
結果1件で部品番号75件まで問い合わせ可能。回答は1通にまとめて返信
導入前不備のある問い合わせは、人が読むまで発見できない
解決策振り分けデータによる入力チェック、自動取り消し、エラー内容を説明するメール
結果ディストリビューターは修正点をすぐに把握。取り消したチケットは3日後にクローズ
導入前未対応チケットのフォローは担当者の記憶頼み
解決策輸出元とバイヤーへのリマインド、7営業日応答がなければ自動クローズ
結果フォローを記憶ではなくルールで運用
導入前対応時間を一貫して把握する方法がない
解決策Zendesk Exploreのダッシュボードと、全チケットとコメント履歴のCSV出力
結果24時間以内の初回回答、回答・解決までのリードタイム、経過日数別の未解決チケットを月次KPIとして把握
振り分けのデータは、すでにデータウェアハウスにありました。私たちの役割は、ディストリビューターが送信ボタンを押した時点でそのデータを使い、回答できる担当者へ問い合わせを直接届けることです。そのうえで、利用者の要望をもとにポータルを改善し続けてきました。
プロジェクト責任者、平プロモート デジタル
今後の展開

小さな改善を定期的に

ポータルは現在、地域統括会社のチームとの定例会議で合意した小規模な改善を、定期的にリリースする段階に入っています。

プラットフォームとパートナー
Zendesk (Help Centercustom appsExplore)Amazon API GatewayAWS LambdaAmazon DynamoDBAmazon CloudFrontAmazon CloudWatchAmazon S3AWS Secrets ManagerAWS KMSData-warehouse routing API (partner-managed)

同様の課題をお持ちですか

課題を数行でお聞かせください。通常1週間以内に、具体的な最初の一歩をご提案します。