音声とテキストのカスタマーサポートの違いは技術的な優劣ではなく、チャネルの違いである：お客様は電話をかけるのが習慣か、LINEやウェブサイトでやり取りするのが習慣か？ 適切なチャネルを選ばないと、どんなに優れたAIでも繋がることができない。本ページでは、両者のコスト構造、失敗パターン、および測定方法を比較しています。
| 対象 | 音声AIカスタマーサポート（電話） | テキストAIカスタマーサポートロボット（ウェブサイト/LINE） |
|---|---|---|
| インタラクティブなチャネル | 電話による接続と外部接続 | ウェブサイトのチャットボックス、LINE公式アカウント |
| 典型的な利用者 | 電話をかけるのが習慣、運転中や入力が難しい状況 | メッセージを送るのが習慣、非同期でのやり取り |
| コスト構造 | 構築＋通信回線＋音声認識合成＋モデル利用量 | 構築＋モデル利用量（通信回線と音声層を削減） |
| 統合ニーズ | PBX/SIP、代表番号、録音ポリシー、並行処理容量 | ウェブサイトまたはLINEへのアクセス、ナレッジベース、バックエンドAPI |
| 主要な失敗パターン | 認識の誤り、ノイズ、発音の誤り、通話の途切れ | 意図の誤認、モデルの誤認識、的外れ |
| 測定指標 | 接続成功率、フィールド取得率、オペレーターへの転送率 | 解決率、対話の回数、オペレーターへの転送率 |
| Falconの価格 | 顧客のニーズと環境の調査に基づいた見積もり | AI カスタマーサポート MVP：1 プロジェクト TWD 30,000 から |
両者は「ユーザーの理解、情報検索、動作実行」というプロセスを共通にしていますが、その入り口が異なります。音声チャットは電話を通じて、即時、入力不要、高齢者やモバイルユーザーにも対応できますが、1秒あたりのコストがかかり、誤った認識を修正する必要があります。テキストベースのチャットはウェブサイトやLINEを通じて、ゆっくりと返信でき、リンクや画像、会話履歴を保存できますが、電話で問い合わせる顧客には対応できません。したがって、最初の問題は常に「あなたの顧客は現在、どこから問い合わせていますか？」です。
文字ベースのカスタマーサポートのコスト構造は比較的シンプルです。初期構築費用と、APIの使用量による費用が主な構成要素となります。音声ベースのカスタマーサポートは、これに加えて以下の3つの要素が含まれます。; 通信事業者層（電話番号の月額料金、通話時間）; 音声認識・合成（音声データに基づいた課金）; 並行接続容量（同時通話回数によって、回線とサーバーの構成が決まる） そのため、当社の文字ベースのカスタマーサポートのMVPは、30,000 TWD（台湾ドル）という初期費用を設定しています。一方、音声ベースのプロジェクトは、まず環境を調査した上で、具体的な要件に基づいて見積もりを提示します。PBX、並行接続、録音などの要件を事前に把握せずに、安易な価格を提示することは稀です。
テキストベースのチャットの主なリスクは、理解の誤りです。意図の誤認、モデルの誤認識、的外れです。これらは、ナレッジベースの品質、回答の制限、オペレーターへの転送メカニズムによって対処できます。音声チャットは、これに加えて、音声に関するリスクも存在します。認識の誤り、背景の騒音、発音の誤り、通話の途切れです。そのため、音声チャットのプロセスには、重要なフィールドの確認、低い信頼度でのオペレーターへの転送、切断時の状態の保存が必要です。ベンダーを選ぶ際には、「聞き間違いが発生した場合に何が起こるか」を直接質問することが重要です。理想的な状況しか提示されない場合は、注意が必要です。
判断方法は非常に現実的です。現在の顧客対応の記録を調べてください。電話での問い合わせが多い場合、顧客は口頭でのコミュニケーションを好む（例：地域サービス、高齢者向け）、音声チャットを優先します。LINEやウェブサイトでの問い合わせが多い場合、問題は画像やテキストでの回答に適している（例：ECサイト、予約サービス）、テキストベースのチャットを優先します。両方を組み合わせる場合は、まず、問い合わせが多いチャネルから始め、プロセスの検証を行い、その後、もう一方のチャネルを拡張します。予算が限られている場合は、テキストベースのチャットがより低コストの導入点となります。なぜなら、通信事業者や音声処理の複雑さが少ないからです。
成熟なアーキテクチャは、音声とテキストを同一のシステムとして扱う、2つの入り口を提供するものです。具体的には、以下の2つの要素を共有します。; 知識ベースの共有（保守）; バックエンドの動作共有（注文の確認、工数の作成、担当者への割り当てなど、同一のAPIを使用）; チャット戦略の調整（音声は簡潔な口語、テキストはリンクを貼るなど、チャネルに合わせて調整） 私たちが公開しているGoGoChaの事例は、この考え方に基づいています。電話、ウェブサイト、LINEの3つの入り口が、同一のバックエンドシステムを通じて注文を受け取ります。どの入り口からでも構いませんが、重要なのは、バックエンドの設計段階で、複数のチャネルに対応できるようにしておくことです。これにより、後でやり直す手間を省くことができます。
