AIコールセンターの要件定義で先に決めること

AIコールセンターの要件定義は、欲しい機能を並べる作業ではありません。一つの問い合わせについて、どの状態までAIが完了し、どの条件から人が引き継ぐかを決めます。外部システムが動かない場合と、結果を確認する方法まで書けば、各社へ同じ条件を渡せます。

最初からセンター全体を対象にすると、用件ごとの違いが機能一覧へ埋もれます。直近の通話から一つの用件を選び、正常時と例外時の終了状態を一枚にしてください。その一枚を比較表とデモ、見積もりの共通条件にします。

この記事では、候補製品を調べる前に作る要件定義票を扱います。会話設計やKPIの詳細は個別記事へ譲り、製品を足切りできる受け入れ条件までを決めます。

一つの対象用件と現在値を決める

対象は「問い合わせ対応」のような部門名ではなく、始まりと終わりを数えられる業務にします。「予約変更の電話を受け、本人確認後に予約システムへ変更を反映する」まで具体化すると、必要な会話と連携が見えます。

直近一か月から、件数と通話時間を確認します。最繁忙時間帯の同時入電も必要です。人が応対した現在の完了率と転送件数を記録します。再問い合わせと後処理時間も残せる場合は、導入後と同じ定義で測ります。

件数が多い用件でも、本人確認や個別判断の例外が多ければ最初の対象に向かない場合があります。AIコールセンター導入で決める自動化範囲を使ってください。案内と受付、システム処理、人の判断のどこまでを対象にするか先に分けます。

正しい完了と対象外を一文にする

要件には「AIが回答できる」ではなく、業務が終わった状態を書きます。予約変更なら、希望日時を聞いただけでは完了ではありません。変更結果がシステムへ登録され、利用者へ確定内容を伝え、履歴が残った状態を完了とします。

同じ用件でも、本人確認に失敗した場合や規定外の変更は人の判断が必要です。AIで完了する条件と、最初から対象にしない条件を一文の中で分けます。

予約番号と本人情報が一致し、変更可能な時間帯に空きがある場合は、予約を更新して確定内容を案内する。一致しない場合と規定外の依頼は処理せず、有人窓口へ引き継ぐ。

この文章を各社へ渡すと、「予約に対応」という機能名ではなく、同じ終了状態を実現できるか確認できます。対象外を明記すれば、自動完了率の分母も候補間でそろいます。

予約変更の要件票を記入する例

次は架空の点検予約を変更する例です。実在する顧客の予約を試験へ使わず、変更してよいテスト台帳を用意します。

この例で、台帳の変更に成功しても案内前に切断したら、業務全体は未完了です。一方、台帳が変わっていないのに「変更できました」と案内した場合は重大な誤りです。両方を単なる通話切断として扱わないようにします。

有人連携を不在時までつなげる

有人連携は転送先へ発信した時点で終わりません。担当者が用件と確認済み情報を受け取り、応対を続けられることが完了条件です。

人へ切り替える理由、転送先、渡す情報を決めます。担当者が応答しない場合は、折り返し受付へ変えるのか、別のキューへ回すのかも必要です。営業時間外や混雑時に同じ転送処理を使うと、待機だけが長くなる場合があります。

Amazon Connect Customerのルーティング説明では、キューとルーティングプロファイルによって対象キューや優先度、チャネルごとの同時対応数を設定します。営業時間の設定もフローの分岐に利用できます。これは一つの実装例です。要件では営業時間と転送先の混雑、担当者不在を別の終了状態にしてください。

転送条件と引き継ぐ情報を詳しく決める場合は、AIコールセンターの有人転送と引き継ぎ設計へ進みます。

システム連携は失敗時の処理まで書く

CRMや予約システムと連携できるだけでは、業務要件になりません。どの時点で何を受け取り、どの項目を書き戻すかを決めます。タイムアウトや重複登録が起きた場合の終了状態も必要です。

Dialogflow CXのWebhook資料では、連携呼び出しを追うIDや失敗理由を確認できます。自社の試験でも、認証エラーと応答待ちの時間切れを分けます。時間切れでは相手側の更新が済んでいる場合があるため、未更新と決めつけません。

予約システムへの更新結果が不明なら、AIは完了と案内しません。受付番号を付けて確認待ちにし、担当者へタスクを残します。再送する場合は同じ受付を二重登録しない条件も書いてください。

連携要件は、APIの有無ではなく「利用者へ何を案内して通話を終えるか」までつなげると、障害時の手作業と責任者を比較できます。

通常時と繁忙時の容量を分ける

月間件数だけでは、必要な同時処理数を決められません。最繁忙の三十分に何件入り、平均で何分利用するかを確認します。AIが処理する通話と人へ転送した後の回線も分けます。

通常時には待ち時間が短くても、繁忙時にAIまたは有人キューの上限へ達する場合があります。要件定義票には通常月と繁忙月を置き、同時通話の上限を超えた電話の扱いを書きます。待機、折り返し受付、別窓口への案内は別の要件です。

最大値は契約上の上限、技術上の上限、現在の設定値を分けて回答してもらいます。Amazon Connectのキュー容量による分岐も、キューの設定値と同時処理の上限を分けて扱います。「同時100通話に対応」でも、契約や転送先の条件が同じとは限りません。

営業時間も週の予定だけで決めません。祝日、臨時休業、障害時の閉鎖を反映する担当者と期限を置きます。時間外にAIが受け付けた用件を、翌営業日に誰が確認するかも必要です。

料金へ換算するときは、AIコールセンターの費用を業務量から見積もる方法を使います。席数と同時通話、AI処理、有人運用を同じ三条件へ移してください。

記録と評価方法を要件へ含める

通話が終わった後に結果を確かめられなければ、受け入れテストも運用改善もできません。通話結果、転送成否、処理結果をどこへ残すか決めます。録音と文字起こし、要約は必要な目的と閲覧者へ絞ります。

個人情報保護委員会のガイドライン通則編では、個人データの安全管理措置と従業者・委託先の監督を示しています。保存できる機能があっても、自社の要件は別に確定します。利用目的と保存期間、閲覧権限、削除方法を決めてください。

評価指標は製品画面の名称から選びません。自社では正しい業務完了を中心にし、再問い合わせと重大な誤りを別に追います。たとえば試験30件のうち20件が正しく自動完了し、6件が有人対応、3件が確認待ち、1件が誤った完了案内なら、自動完了は20÷30=66.7%です。21件とは数えず、誤った完了案内の1件を別に修正します。数字は架空の例で、業界の目標値ではありません。

要約が空欄の場合も確認します。Amazon Connectの通話後要約は生成中の状態と利用可能になった状態を分けて表示します。候補製品では未生成・生成失敗・利用可能をどう確認できるか尋ねてください。数字と否定表現を含む通話を使い、修正後の値がCRMへ渡るかまで見ます。

管理者だけのデモでは、権限の不足や過剰を見つけられません。オペレーターと品質管理者でもログインし、担当外の通話や録音の出力が制限されるかを確認します。外部AIへの送信先と再委託先、契約終了時に取り出せるデータと取得期限は書面で回答してもらいます。

測定票の作り方はAIコールセンターで追う指標の決め方で整理できます。要件定義の段階では、正しさを確認する画面と記録を候補製品から取得できるかを確かめてください。

受け入れ条件へ書き換える

「自然に会話できる」「簡単に連携できる」のような表現は、そのままでは合否を決められません。入力と期待する処理を決めます。終了状態と失敗時の処理も書いてください。

Amazon Connect Customerのテストとシミュレーションでは、期待する属性や体験を検証し、実際の経路が想定から外れた箇所を確認できます。候補製品に同じテスト機能がなくても、受け入れ条件は各社へ渡せます。正常と例外、失敗の通話シナリオに分けてください。

商談ではB-401を使い、まず正常な変更を実演します。次は本人確認を一項目不足させ、対象予約の詳細を回答しないことを確認します。最後に更新応答を返さない状態を試し、台帳を再照会してから処理を再開できるかを見ます。

追加試験では「22日ではなく23日」と訂正し、台帳と通知に23日が残るかを照合します。有人窓口を不在や満員にした試験も必要です。同時着信を再現できない場合は、負荷試験の前提と上限超過時のログを受け取り、未実演の項目を合格にしないでください。

各試験へ受付IDと設定版、期待値と実際の値を残します。重大な誤処理が一件でもあれば、平均点で埋めずに該当経路を修正します。修正した例だけでなく正常系も再試験し、変更による別の不具合を確かめます。

導入支援と障害対応の担当を決める

要件整理、会話作成、連携設定、試験、研修の各工程に、自社と提供会社の担当を置きます。「導入支援込み」という回答では、自社が何時間使うかは分かりません。設定変更の回数や対象外作業も見積もりへ明記してもらいます。

障害連絡の受付時間と一次回答の目標は、復旧保証と分けます。たとえば一次回答が1時間以内でも、電話の再開が1時間以内とは限りません。電話停止、転送失敗、CRM反映失敗、要約停止ごとに連絡先と暫定運用を決めてください。

見積もりは小規模開始・通常月・繁忙月の三条件でそろえます。回線とAI処理に加え、有人席や録音・解析の費用を確認します。構築費と運用支援費を分け、増枠の日数と追加料金も書面で確認します。実演結果、仕様書、見積もりが同じ対象業務を指している候補だけを最終比較へ進めます。

一枚の要件定義票へまとめる

要件定義票の最初には、対象用件と現在値を置きます。完了条件と対象外、有人連携、システム連携も必要です。さらに容量と記録、受け入れ条件を加えます。項目ごとに「必須」「選択」「将来」の優先度も付けてください。

必須条件を満たさない候補は、機能数の合計で救済しません。選択条件は費用と運用負荷を見て判断します。将来条件は今回の見積もりから外し、拡張時に再確認します。

最初の作業は、直近の問い合わせを二十件確認することです。件数の多い一つの用件を選び、正しい完了と人へ渡す条件を一文ずつ書いてください。その二文に通常時と失敗時の受け入れ条件を加え、AIコールセンター比較表の候補へ同じ要件定義票を渡します。