トークスクリプトの作り方｜受電対応の分岐例とテンプレート

受電の台本を作ったものの、相手が想定と違う順番で話すと対応が止まる。必要な確認を重ねるうちに、同じ質問を繰り返してしまう。こうした問題は、丁寧な例文を一本につなぐだけでは解消しにくいものです。

トークスクリプトは、質問と返答の例に加え、相手の回答に応じて次に何をするかを決めた会話の設計書です。 受電では、用件を聞き、必要な情報をそろえ、回答・受付・引継ぎのどこで終えるかまで設計します。

この記事では、担当者への折り返し受付を例に、受電トークスクリプトの作り方を解説します。会話例は架空の窓口を想定した編集用のたたき台です。実際の窓口名、確認項目、担当者の権限に合わせて変更してください。

トークスクリプトとマニュアルの違い

電話対応マニュアルが「誰が、どの順序で仕事をするか」を定めるのに対し、トークスクリプトは「相手に何を聞き、その返答でどこへ進むか」を具体化します。

たとえば、担当者不在時に折り返しを受け付けるという業務ルールだけでは、相手が「電話ではなくメールがよい」と希望した場合の会話は決まりません。別の連絡方法を扱えるか、確認先はどこかも台本に必要です。

ただし、台本に書いたことで新しい業務権限が生まれるわけではありません。まず電話対応マニュアルで受付範囲を決め、その範囲を会話に落とし込みます。

作る前に決める四つのこと

対象とする用件

「問い合わせ全般」では広すぎます。「修理に関する相談を担当者へ取り次ぐ」「担当者不在時に折り返し希望を受け付ける」など、一つの入口から始めます。

対象外の用件も書きます。返金の承認や契約変更など、その場で判断できない内容を受付担当が約束しないようにします。

必要な情報

処理のために本当に必要な項目を決めます。氏名、連絡先、用件、連絡可能な時間帯などが候補ですが、すべての用件で同じ情報が必要とは限りません。

相手が最初に伝えた情報は、取得済みとして扱います。「先ほどお知らせいただいた番号へ折り返してよろしいでしょうか」と確認すれば、最初から数字を言い直してもらう必要を減らせます。

完了の条件

この台本で終えるのが「受付」なのか、「担当者との通話」なのかを明確にします。折り返し希望を記録した段階では、相談の解決や契約変更は終わっていません。

終了時に相手へ何を伝えるかも、完了条件とそろえます。「変更できました」と「変更希望を受け付けました」は別の案内です。

通常の会話から外れたときの出口

聞き取れない、情報が不足している、用件が複数ある、人との会話を希望する。そのような場合に、どこへ進むかを先に決めます。同じ質問を際限なく繰り返す構成にはしません。

台本は「質問・条件・案内・次の処理」で書く

例文だけを並べるより、判断条件と処理を横に置くと、台本の漏れを見つけやすくなります。

図1：会話の分岐を一行で設計する。説明用の例。実際の業務条件に合わせて調整。

「情報が取れたら次へ」と書く場合は、何をもって取れたとするかも明確にします。番号らしい文字列があるだけなのか、相手と復唱確認まで済んだのかで、使える情報が変わります。

受電から折り返し受付までの会話例

以下は、相談担当者が不在で、その場では回答を確約できない窓口の例です。担当者の戻り時刻や連絡期限が未確認という前提で作っています。

受付：お電話ありがとうございます。〇〇相談窓口です。

利用者：申し込んだ内容について確認したいのですが、担当の方はいらっしゃいますか。

受付：お申し込み内容のご確認ですね。担当者はただいま対応中です。折り返しをご希望でしょうか。

利用者：お願いします。午後は電話に出られません。

受付：午前中のご連絡をご希望ですね。担当者に希望を伝えますが、現時点では連絡時刻のお約束ができません。それでも折り返しをお受けしてよろしいでしょうか。

利用者：はい。

受付：お名前と、折り返し先のお電話番号をお願いします。

この後に、連絡先と用件を確認し、受付内容を記録します。「午前中を希望」と「午前中に連絡すると約束済み」を、同じ項目へ混ぜないことがポイントです。

実際には担当者と確認して期限を約束できる窓口もあります。その場合は、確認した期限を伝える台本にします。できないことを一律に断るのではなく、運用に合う返答を用意します。

相手の返答で、会話を分ける

「さっき伝えました」と言われた場合

図2：想定外の返答から、次の一手へ。本文の関係や手順を整理した図。

取得済みの項目を参照し、不足する内容だけを聞きます。情報が記録できていない場合は、そのことを曖昧にせず、必要な箇所の確認をお願いする言い方を用意します。

例：「失礼しました。お名前は〇〇様で伺っています。折り返し先の番号だけ確認させてください。」

「今日中でないと困る」と言われた場合

緊急度と希望を記録し、判断できる人へ渡します。台本だけで担当者の予定を埋めたり、対応期限を作ったりしないようにします。

例：「本日中のご連絡をご希望ですね。対応できるか責任者へ確認します。」

この言葉を使うには、実際に責任者へ確認できる経路が必要です。営業時間外など確認できない場合の案内も別に用意します。

用件が二つある場合

最初に両方を短く整理し、今回の受付で扱えるかを確認します。一つだけ処理して、残りが伝わったか分からないまま終えないようにします。

例：「お申し込み内容の確認と、お支払い方法の変更ですね。まずご相談内容を記録し、変更手続きについても担当者へ伝えます。」

聞き取れない・答えがない場合

質問を短くし、必要なら言い方を変えます。人の台本でもAIの台本でも、聞き直す対象を絞ることが重要です。

音声対話の標準仕様VoiceXMLでは、入力がない状態と、認識条件に合う入力が得られない状態を区別しています。W3C VoiceXML 2.0

AI用のシナリオでは、この区別を参考に、待つ・再案内する・人へ渡すなどの動きを決めます。何回で切り替えるかは、用件と試験結果に合わせて設定します。

編集して使える会話分岐テンプレート

【受電トークスクリプト】
対象用件：
この会話で終える範囲：
開始時の案内：
取得済みの情報：

質問ID：
相手に聞くこと：
この質問が必要な条件：
回答パターン：
  A 通常の回答 → 次の案内／処理：
  B 情報不足・曖昧 → 追加で確認すること：
  C 訂正・言い直し → 修正する項目／戻り先：
  D 対象外・有人希望 → 引継ぎ先／伝える内容：
  E 無入力・聞き取り失敗 → 再案内／切替条件：
参照してよい情報：
約束してよい範囲：
記録する項目：
終了時に伝える事実と次の対応：

質問IDはQ1、Q2など簡単な記号で構いません。改訂や試験で「どの質問で止まったか」を示せるようにすると、修正する箇所を共有しやすくなります。

読み合わせではなく、相手役を置いて試す

作成者が台本どおりに読むだけでは、想定外の返答を確認できません。相手役には用件と条件だけを渡し、自分の言葉で話してもらいます。

会話の自然さ、記録の正しさ、受付の完了を別々に確認します。話し方は自然でも、訂正前の電話番号が残っているなら修正が必要です。

質問を増やす前に、会話の状態を整理する

トークスクリプトを詳しくするとき、質問文をひたすら追加すると、すでに聞いた内容を再び尋ねる流れになりがちです。必要なのは質問の本数より、会話のどこまでが確定しているかを分かるようにすることです。用件、連絡先、希望条件、受付結果をそれぞれ区別すると、相手が順番どおりに話さなくても対応を組み立てられます。

たとえば予約変更の電話で、相手が最初に「明日の予約を金曜日に変えたい、名前は山田です」と話した場合を考えます。氏名、現在の予約日、変更希望日という三つの情報が一度に出ています。ただし、同じ氏名の予約があるか、金曜日のどの時間を希望するか、変更できるかはまだ分かりません。スクリプトでは、受け取った情報を保持し、不足している確認へ進む形にします。

「現在分かっていること」「追加で確認すること」「担当者やシステムによる判断が必要なこと」を分けて書けば、質問と判断が混ざりません。「金曜日への変更をご希望ですね。ご希望の時間帯を教えてください」と進めることはできますが、空き状況を確認していない段階で「変更しました」と案内することはできません。

未確認・確認済み・訂正済みを区別する

情報項目には、値だけでなく確認の状態も持たせます。電話番号を聞き取っただけなのか、復唱して相手の確認を得たのかでは、折り返し先としての確かさが異なります。相手が途中で番号を訂正した場合は、古い番号と新しい番号を並べて担当者に選ばせるのではなく、どちらを使うかまで明示します。

紙のスクリプトでも、記入欄に「復唱確認」「訂正あり」のチェックを設ければ運用できます。AI向けの場合も、特定の管理画面の機能名から考える必要はありません。まず人が読んで判断できる状態の定義を作り、利用する仕組みで表現できるかを確認する順序が分かりやすいでしょう。

複数の用件と途中変更を扱う分岐を用意する

実際の電話では、一つの用件が終わる前に別の質問が入ります。「予約を変更したい。それと駐車場はありますか」という電話に対して、すべてを一つの分岐に詰め込むと、どちらが完了したか分からなくなります。関連する用件でも、案内で終わるものと手続きが必要なものは別に管理します。

この例なら「先に駐車場についてご案内し、その後、予約変更のご希望を確認します」と順序を伝える方法があります。一方、本人確認中に話題が変わった場合は、その確認をどこまで済ませたかを保持する必要があります。順序は業務に合わせて決めますが、途中で扱わなかった用件を終了前に確認する項目は共通して用意できます。

「やっぱり変更しない」を独立した分岐にする

取り消しの意思表示は、無回答や認識できない発言と同じ扱いにしません。変更内容の確認前であれば希望の取り下げとして処理できますが、すでに変更処理を行った後なら、元に戻せるかを改めて確認する必要があります。会話の段階によって対応が変わるため、取消分岐には「処理前」「処理中」「結果確認後」の区別を付けます。

外部システムの処理結果が不明なときは、取り消しが完了したとも、変更がされていないとも断定できません。相手には確認が必要な状態を伝え、担当者には操作内容と結果不明の状況を渡します。この分岐を先に書いておくと、現場で場当たり的な約束をすることを防げます。

直前の回答だけに依存しない

「それで大丈夫です」という返答は、何に同意したかによって意味が変わります。希望日の確認なのか、電話番号の確認なのか、手続き実行の同意なのかを区別しましょう。複数の条件を続けて読み上げてから一度だけ確認すると、一部だけに同意した可能性が残ります。取り違えると影響が大きい条件は、確認する対象が明確になるよう文を分けます。

分岐表を担当者が読める形に整える

分岐表には、条件と発話文だけでなく、確認する情報と次の行き先を載せます。すべての例外を長い一文に埋め込むより、条件を独立した行にする方が更新しやすくなります。以下は予約変更を想定した構成例であり、実際の受付条件は自社の運用に置き換えてください。

行き先を「適切に対応」とだけ書くと、担当者ごとの判断が残ります。「受付記録を保存して終了」「担当窓口へ接続」「結果を確認する担当に引き継ぐ」のように、次の作業が分かる表現にします。行き先に対応する手順が存在しない場合は、スクリプトではなく運用側の不足として修正します。

分岐には管理用の番号を付けておくと便利です。研修中に「この案内が分かりにくい」と伝えるより、「予約変更の確認後に進む分岐で、受付と完了の表現が混ざっている」と指定できる方が、修正内容を共有しやすくなります。番号は顧客向けに読み上げるためではなく、管理者と担当者の共通の参照先として使います。

テストでは「予定外の返答」を意図的に入れる

完成したスクリプトを順番どおりに読み合わせるだけでは、分岐の不足を見つけにくくなります。テスト役には、質問に先回りして答える、途中で訂正する、二つの用件をまとめて伝えるなど、実際に起こり得る返答を依頼します。目的は担当者を困らせることではなく、手順が支えられる範囲を確認することです。

図3：台本の検証は、会話と記録の両方で。本文の関係や手順を整理した図。

テスト結果には、会話が成立したかに加えて、記録の内容も残します。相手への案内が自然でも、引き継ぎ先に誤った日時が渡れば業務上は問題があります。発話、分岐、保存された情報、終了状態を一つのセットで確認すると、どこで修正すべきかを切り分けられます。

改訂時は「表現」と「業務判断」を分けて管理する

語尾を柔らかくする変更と、受付可能な条件を広げる変更では、必要な確認が違います。前者は伝わりやすさの確認が中心ですが、後者は担当部署の合意や関連手順の変更が必要です。変更履歴に理由と対象の分岐を残すことで、文章の修正に見える変更が業務範囲まで変えていないかを確認できます。

改訂版を共有するときは、全文だけでなく、変わった条件と現場への影響を添えます。「今後はこの用件を受け付ける」「この場合は折り返しを約束しない」といった行動の違いが分かる説明が役立ちます。旧版を参照できる端末や印刷物が残っていないかも確認しましょう。

運用開始後の改善では、質問が重複した箇所、相手が説明を求め直した箇所、担当者が手順外で補足した箇所を集めます。毎回その場で補っている説明は、スクリプトに不足している可能性があります。ただし、一度だけ起きた特殊な会話をすべて本文に足すと読みにくくなるため、共通の分岐として扱うか、補足例として残すかを決めて更新します。

分岐に入らなかった返答を記録する

どの条件にも合わない返答が出たときは、無理に近い選択肢へ当てはめず、確認し直すか担当者へ渡す経路を使います。記録には、想定していた質問と実際の返答、最終的に取った対応を残します。後から見直す際に、言い換えの不足なのか、新しい業務条件なのかを判断できます。

同じ返答が繰り返し現れるなら、質問文の意味が伝わっていない可能性もあります。返答の例を増やすだけでなく、質問が一度に複数のことを求めていないか、専門用語を使っていないかを点検します。分岐の追加と質問の改善を両方検討することで、スクリプトの複雑化を抑えられます。

変更した分岐は、研修で使う会話例にも反映します。手順書だけ新しくなり、練習で古い案内を繰り返す状態を避けましょう。現場からの指摘、修正内容、確認結果を結び付けて残すと、次の担当者にも変更の意図が伝わります。

よくある質問

台本は一字一句、読ませるものですか？

同意の確認や重要な条件など、表現を統一すべき箇所を定めます。それ以外は、要点と処理が変わらない範囲で相手に合わせられるようにすると、機械的な繰り返しを避けやすくなります。

営業電話の台本と共通化できますか？

挨拶や記録項目には共通部分がありますが、受電は相手の用件を受けるところから始まります。こちらから目的を伝える営業の架電とは分けて設計します。

AIなら、台本を作らなくてもよいのでは？

生成AIで表現を柔軟にしても、対応範囲、必要情報、処理権限、終了条件は必要です。文章を固定する範囲と、言い換えを許す範囲を分けて考えます。

一つの質問から、返答の違いを書き出す

最初から長い台本を完成させる必要はありません。「折り返しを希望するか」のような一つの質問について、通常の回答と、困りそうな回答を並べるところから始められます。

Daisybellへのご相談では、今の台本と、実際の会話で対応が止まりやすい場面をお聞かせください。

受電シナリオ・AI電話対応について相談する

あわせて読みたい

• 電話対応マニュアルの作り方
• ボイスボット導入の進め方
• IVRとは？AI IVR・ボイスボットとの違いと使い分け