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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Amazon Connect Customerの問い合わせ属性は、通話ごとの情報をキーと値で保持し、フローや転送で利用する仕組みです。属性が存在しない場合はエラー分岐へ進むため、正常な値だけを前提にできないことも説明されています。

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

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

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

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

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

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

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

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

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

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

評価指標は製品画面の名称から選びません。Amazon Connect Customerの指標定義でも、放棄とAIからの引き継ぎ、後処理は別の指標です。自社では正しい業務完了を中心にし、再問い合わせと重大な誤りを別に追います。

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

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

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

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

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

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

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

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