報告書を待たずに、顧客が毎日何について電話してきているかがわかります。数百万人分の契約者データは自社のシステムの中だけにあります。
通信事業者・ISP · 10 / 12
通信事業者向けプライベートLLM
コールセンターの通話を要約し、ネットワークのチケットを検索し、契約者データから返信を下書きします。事業者自身のシステム上で動くので、数百万回線分のデータはどこにも出ていきません。
通信事業者・ISP 「コールセンターの通話は1日に数万件、ネットワークのチケットは技術者ごとに書き方がばらばら。AIに要約させたいが、契約者データは免許の条件でもPDPAでも外に出せない」
よくある課題
通信事業者には、1日に数万件のコールセンターの通話と、担当者によって短かったり長かったりする通話後のメモ、技術チームごとに書き方の違うネットワークチケットがたまります。ある地域で障害が起きると、NOC(ネットワーク監視センター)は同じことが以前にもあったかを自分たちで調べます。サービスチームは苦情が増えていると気づいていても、報告書にまとまるのは週末です。
契約者データは免許の条件とタイの個人情報保護法(PDPA)の対象で、他社のクラウドに出して分析することはできません。この量になると、外部の事業者にリクエスト単位で料金を払うのも割に合いません。そのためチームがAIを使えるのは名前を消したデータだけで、それでは実務にほとんど役立ちません。
解決の方法
1日の通話量に合わせた規模の言語モデルを、事業者のデータセンターのKubernetes上、または会社が管理するクラウドアカウントに導入し、いま使っているコンタクトセンター、課金、チケット管理の各システムにつなぎます。通話が終わるたびに、システムが問い合わせの理由、結果、未解決事項を要約してCRMに書き込みます。顧客がまた電話してくると、担当者は電話に出る前にその要約を見られます。
ネットワーク側では、NOCが「この交換局で以前にもこの症状が出たか」と入力すると、過去のチケットが当時の解決方法付きで出てきます。すべては自社のネットワーク内で動き、権限はチームと地域ごとに分かれます。個人情報は権限レベルに応じてマスキングし、すべての質問が監査ログに残るので、コンプライアンス部門とDPO(データ保護責任者)が確認できます。
請求額の調整、サービスの解約、技術者の現地派遣は、担当者とチームリーダーが判断します。システムの役割は要約、検索、下書きで、顧客に自分で何かを送ることはありません。
仕組みの流れ
- コールセンターの通話と通話後メモ
- ネットワークチケットと障害報告
- 課金システムとCRMの回線データ
- あらゆるチャネルからの苦情
- 権限に応じて個人情報をマスキング
- 全通話を要約し内容を分類
- 過去のチケットと解決方法を検索
- 担当者向けに返信を下書き
- 次の電話の前にCRMへ通話要約
- 過去の解決チケット付きでNOCへ回答
- ネットワークチームへ日次の苦情報告
- コンプライアンス部門向け監査ログ
導入前と導入後
導入で得られるもの
- 01
コールセンターの全通話を、問い合わせの理由、結果、未解決事項に要約する、事業者のデータセンター内のモデル
- 02
回線ごとのプラン、未払い残高、利用履歴を権限の範囲で読み、返信を下書きする担当者画面内のアシスタント
- 03
ネットワークのチケットと過去の障害報告を普段の言葉で検索し、NOCが以前に解決した同じ障害を見つける機能
- 04
苦情を毎日分類し、問い合わせが急に増えた地域をネットワークチームとサービスチームに通知
- 05
身分証番号や個人の利用データを権限レベルに応じてマスキングし、すべての質問を監査ログに記録
立場ごとのメリット
自社データセンターのKubernetesに通話量に合わせた規模で導入し、コンタクトセンターと課金システムにAPIで接続します。権限はActive Directoryに従い、すべての質問が監査ログに残ります。
コールセンターの担当者は長い通話後メモを書かずに済み、前回の用件を顧客に聞き直すこともなくなります。NOCも過去のチケットを1件ずつ読む必要がなくなります。
向いている業種
お使いのシステムと連携
開発プロセス
- 1
ヒアリング
要件・ユーザー・成功指標を定義し、着手前に範囲と価格を確定。
- 2
設計
UXとアーキテクチャを設計。プロトタイプ承認後に開発へ。
- 3
開発
AIで加速したスプリント。毎週デモ、シニアがレビュー。
- 4
テスト
合意した範囲に対してQA・セキュリティ・性能を検証。
- 5
公開・保守
本番リリース、チームトレーニング、月次保守プラン。