テレアポのテストコールとは？依頼から本稼働までの流れと判断基準を解説

テストコールとは、本稼働の前に少量の架電を行い、リスト・スクリプト・ターゲットの設計が合っているかを確認する工程です。

テレアポ代行を依頼したあと、いきなり大量の電話がかけられるわけではありません。まずテストコールで反応を確かめ、改善したうえで本稼働に進みます。

この記事では、依頼から本稼働までの流れを順番に追いながら、テストコールで何を決め、何を見て、どう判断するかを解説します。

テストコールとは（テレアポ代行のどの工程か）

テストコールとは、本稼働の前に少量の架電を行い、リスト・スクリプト・ターゲットの設計が実際に通用するかを確かめる工程です。

テレアポ代行は、いきなり本番の架電から始まるわけではありません。準備を整えたあとに少量の架電で反応を確かめ、必要な修正を加えてから本稼働に進みます。テストコールはその「確かめる」部分にあたる工程で、社内では「テスト架電」と呼ぶこともあります。テレアポ代行とはという手段そのものを整理したい方や、テレアポとインサイドセールスの違いを確かめたい方は、あわせてお読みください。

なお、この記事で扱うのは営業電話のテスト架電です。電話機や回線が正しくつながるかを確かめる疎通確認のことではありません。

図：テレアポ代行の工程のうち、テストコールは準備と本稼働のあいだにある

テストコールと本稼働は何が違うのか

いちばんの違いは目的です。テストコールは設計の検証、本稼働はアポイントの獲得のために行います。

目的が違うため、見る指標も報告の頻度も変わります。テストコールでは接続率や断り理由といった「反応の傾向」を見て、本稼働ではアポ率や有効商談率といった「成果」を見ます。下の表が両者の違いです。

※件数と期間はグッドアポの実績にもとづく目安です。商材やターゲットの難易度によって増減します。

テストコールを行う3つの目的

目的は、設計の検証、改善すべき箇所の特定、本稼働に進めてよいかの判断の3つです。

1. リスト・スクリプト・ターゲットの設計が実際に通用するかを検証する
2. 架電先の反応から、改善すべき箇所を特定する
3. 本稼働に進めてよいかを判断する

3つ目が特に重要です。テストコールはアポイントを積み上げるための工程ではなく、このまま件数を増やしてよいかを見極めるための工程だと考えてください。

テストコールを省くと何が起きるか

省くと、どれだけ件数を増やしても成果につながらないアポイントばかりが増え、費用対効果が悪化します。

テレアポにおけるテストコールとは、少量のリストに試験的に架電し、反応を確認する工程です。この段階で、スクリプトがターゲットに合っているか、リストの選定が正しいか、断られる理由に偏りがないかといった重要な点を早期にチェックできます。

このステップを省くと、どれだけ件数を増やしても成果につながらないアポイントばかりが増えるため、費用対効果が悪化します。テストコールは「量より質」をつくるための起点なのです。

実際、初回のテストでスクリプトとリストの整合性を調整した結果、アポ率が1.5%から4.0%に改善した例もあります（保育向けの人材紹介の案件でのグッドアポの実績です）。外注でも成果を出すためには、数を回す前に見極めることが最初の一歩になります。

テストコールを行わずに本稼働へ入ることはあるのか

基本的にはありません。設計がすでに検証済みの場合にかぎり、省くことがあります。

具体的には、過去に同じ商材・同じターゲットで架電した実績があり、リストやスクリプトの設計が検証済みの場合です。裏を返せば、初めての商材やターゲットであれば、テストコールを経ずに本稼働へ進むことはないとお考えください。

依頼から本稼働までの流れ

依頼から本稼働までは、問い合わせ・提案・契約・ヒアリング・準備・テストコール・振り返り・本稼働の8工程で進みます。

どこで自社が動き、どこを代行会社に任せるのかが分かっていると、社内の準備をいつ始めればよいかの見当がつきます。ここでは工程の順番と期間の目安、それぞれの役割分担を整理します。

8つの工程を順番に追う

工程は問い合わせから始まり、契約・準備・テストコールを経て本稼働に入るという順番で進みます。

1. 問い合わせ
2. 提案・見積り
3. 契約
4. 初回ヒアリング
5. 準備（ターゲット設計・リスト作成・スクリプト作成）
6. テストコール（1〜4週間・100〜500件）
7. 振り返り・改善
8. 本稼働

このうち4の初回ヒアリングから6のテストコール開始までは、グッドアポの場合1週間が目安です（社内標準）。各工程で自社と代行会社がそれぞれ何をするかは、下の表のとおりです。

表のとおり、自社側にも各工程でやることがあります。丸投げでは進まないと考えておくほうが安全です。費用がどの工程で発生するのかを先に把握しておきたい方は、テレアポ代行の費用相場をご覧ください。

契約前に決まっていないと先へ進めないこと

契約前に必要なのは、ターゲット（業界・規模）の大枠と、商材の概要の2つです。

この2つが決まっていないと、代行会社は提案書も見積りも出せません。逆に言えば、この段階で細かいターゲット設計やスクリプトまで固めておく必要はなく、詳細は契約後のヒアリングで詰めていきます。契約期間や解約の条件も先に確認しておきたい方はテレアポ代行の契約期間を、代行会社を選ぶ段階で何を見るかはテレアポ外注のチェックポイントをあわせてご覧ください。

問い合わせから初回架電までは、どれくらいかかるのか

契約後のヒアリングからテストコール開始までは最短1週間です。ただし全体の期間は一律には言えません。

問い合わせから契約までにかかる期間は、自社側の社内検討や稟議にどれだけ時間がかかるかで変わるためです。「必ず○日で始まります」と言える性質のものではありません。逆に言えば、社内の意思決定を早く進められれば、その分だけ着手も早くなります。

なお、ここで挙げた期間の数字のうち、ヒアリングからテストコール開始まで1週間はグッドアポの社内標準、テストコール100〜500件・1〜4週間はグッドアポの実績にもとづく数字です。

テストコールの前に決めること

開始前に決めるのは、ターゲット・訴求・リスト・スクリプト・商談の受け手・目標の6項目です。

この6つには決める順番があります。前の項目が決まっていないと次が決められない関係になっているためです。なお、ここで扱うのは「何を決めるか」であり、リストやスクリプトの作り方そのものは別の記事で解説しています。

決める順番と、決まっていないと起きること

ターゲットを起点に、訴求、リスト、スクリプト、商談体制、目標の順で決めていきます。

表の1と2は自社にしか決められない部分です。3以降は代行会社と一緒に詰めていく形になります。作り方そのものを知りたい方は、テレアポリストの作り方とリストの質と見極め方、テレアポのトークスクリプト、ターゲット選定をそれぞれご覧ください。

「アポイントとして数える条件」は契約時に決める

アポイントの成立条件は、基本的に契約の時点で着座ベースを基準に決めます。

テストコール前の時点ではその条件のまま進めますが、テスト段階で難易度が分かってきたり、自社側の要望が出てきたりした場合には、条件を変えることもあります。

この条件を決めずに始めると、代行会社と自社のあいだでアポイントの成立・不成立の認識がずれます。費用や成果の判定でもめる原因になるため、あいまいなまま進めないでください。

リストは自社が用意するのか、代行会社が用意するのか

どちらの形でも進められます。自社が用意した場合は基本的にそのまま使います。

代行会社が用意する場合は、ヒアリングで定義したターゲットにもとづいてリストを作成します。いずれの場合も、既存顧客や取引先など架電してはいけない企業があれば、NGリストを別途共有していただく形になります。ここが漏れていると、既存のお客様に営業電話をかけてしまう事故につながります。

準備が足りないまま始まると、どうなるのか

成果が伴わないまま件数だけが消化されていきます。アポイントが取れても商談で噛み合いません。

実際にあったのは、なぜその企業にアタックするのかが明確でないまま、発注いただいた企業のご担当者が以前いた業界だからという理由だけでターゲットを選んで始めたケースです。アポイントは取れたものの、成約には至りませんでした。ターゲットを選んだ根拠が弱いと、数字の上ではアポイントが取れていても商談が噛み合わないというリスクがあります。

テストコールの進め方（件数・期間・体制）

件数と期間に固定の基準はなく、1つの施策あたり50〜100件を目安に積み上げて判断します。

「何件かければテストコールが終わる」という決まった数字はありません。何を検証したいかによって必要な件数が変わるためです。ここでは件数の考え方と、期間中の体制・報告について説明します。

件数は「1施策あたり50〜100件」から考える

リストとスクリプトの適性をはかるには、1つの施策あたりおおよそ50〜100件が目安になります。

ここで言う1施策とは、リストとスクリプトの組み合わせ1通りのことです。たとえばリストを変えて同じスクリプトで試す、あるいはスクリプトを変えて同じリストで試すという進め方をすると、それぞれ50〜100件ずつ積み上がります。そのためテストコール全体では100〜500件になることが多いです。

商材やターゲットの難易度によっても増減します。ニーズが顕在化しやすい商材であれば少ない件数でも傾向が見えますが、ニッチなターゲットや課題が顕在化していない商材では、多めに架電しないと判断材料が揃いません。件数そのものの考え方はテレアポの架電数の目安で、つながりやすい時間帯についてはテレアポの時間帯で解説しています。

件数を増やす場合と、減らす場合

増やすのは反応の傾向がまだ見えないとき、減らすのは早い段階で明確な傾向が出たときです。

たとえば数十件の時点でアポイントが複数取れていれば、そのまま本稼働へ移行する判断もあります。逆に、施策の数（リストとスクリプトの組み合わせ）が増えれば、その分だけ全体の件数は増えていきます。

架電するのは誰か

案件ごとに担当のアポインターが架電します。自社側から担当者を指定することはできません。

代行会社を選ぶ段階では「誰がかけるのか」を気にされることが多いのですが、実際には担当者個人よりも、リストとスクリプトの設計、そして日々の改善が回っているかどうかのほうが結果を左右します。

期間中の報告と、途中で変えること

期間中は日次で結果を共有し、傾向を見てスクリプトやリストをその都度修正します。

日次で共有するのは、架電数・接続数・アポ数といった数字と、断り理由の傾向、そしてその傾向を受けての改善施策です。スクリプトの訴求が刺さっていない、あるいはリストのターゲットがずれていると判断した場合は、期間の途中でも変更します。判断はこの日次の共有の中で行います。

つまり、テストコールは決めた条件を最後までそのまま流す工程ではありません。走らせながら直していく工程だとお考えください。

テストコールの結果の読み方と判断基準

結果は受電率・担当者接続率・アポ率・断り理由の順に見て、どこで止まっているかを特定します。

アポイントが取れなかったときに「うまくいかなかった」で終わらせてしまうと、次に何を直せばよいかが分かりません。指標を順番に見ていくと、止まっている場所が1つに絞れます。

4つの指標を、この順番で見る

受電率、担当者接続率、アポ率、断り理由の傾向の順に見ていきます。上から順に確認します。

1. 受電率（そもそも電話がつながっているか）
2. 担当者接続率（ターゲットに届いているか）
3. アポ率（アポイントが取れているか）
4. 断り理由の傾向（どこで止まっているか）

この順番で見るのは、前の段階でつまずいていると後ろの数字が意味を持たなくなるためです。電話がつながっていないのにスクリプトを直しても、結果は変わりません。アポ率の水準そのものを知りたい方はテレアポの平均アポ率を、指標の設計の考え方はテレアポのKPI設計をご覧ください。

図：アポイントが取れないとき、どこで止まっているかを切り分ける順番

どこで止まっているかを切り分ける

受電率が低ければつながっていない、担当者接続率が低ければ聞いてもらえていない状態です。

アポ率だけが低い場合は、担当者までは届いているものの、話の中身で断られていることになります。「つながらない」「話を聞いてもらえない」「断られる」は、それぞれ打つ手がまったく違うため、混ぜて考えないことが大切です。

本稼働に進む・準備をやり直す・対象を変えるの分かれ目

判断はアポイントの数で行います。テストコールでアポイントが取れていれば本稼働に進みます。

取れていない場合は、先ほどの指標を順番に見てどこで止まっているかを確認します。改善の余地がある場合は準備をやり直し、ターゲット自体に反応がない場合は対象を変える判断になります。

アポイントが取れても商談が噛み合わない場合は、アポイントの成立条件そのものを見直す必要があります。商談化率を上げる代行会社の条件で詳しく解説しています。

数字をどう見るか

公開されている実績の数字は、そのまま自社に当てはまるものではないとお考えください。

たとえばグッドアポには、アポ率4.0%、そのアポイントからの成約率53%という実績がありますが、これは保育向けの人材紹介の案件での数字です。商材もターゲットも違えば、同じ水準にはなりません。数字を見るときは「何の案件の数字か」を必ず確認してください。

結果が悪かったときは、どう進めるのか

すぐに中止するのではなく、どこで止まっているかを分析し、改善して再度テストします。

リストやスクリプトの改善で対処できる場合は、修正したうえでテストを再実施します。ターゲット自体に反応がない場合は、対象の業界や規模を変えて再度テストします。

テストコールは、結果が悪くても改善の材料が手に入る工程です。「反応がなかった」という結果自体が、そのターゲットに時間をかけるべきでないという判断材料になります。やって無駄になることはありません。

本稼働への移行と、その後の報告・改善

本稼働では同じ施策への架電件数が増え、報告が週1回の定例を軸にした形へ移ります。

テストコールで設計が固まったあとは、検証から獲得へと目的が切り替わります。ここでは何が変わり、何が変わらないのかを整理します。

本稼働で変わること、変わらないこと

変わるのは架電件数と報告の形です。架電する体制そのものに変わりはありません。

施策がはまれば、同じリストへの架電件数を増やして継続していくため、1つの施策あたりの件数は必然的に増えます。一方で報告は、週1回の定例で1週間ぶんの数字と傾向を共有する形へ移行することが多いです。本稼働に入ると、商談の振り返りを通じて成約率を高めていく段階に移るためです。

報告の頻度と、載る内容

報告は日次の日報と週1回の定例の2つです。それぞれ載る内容が違います。

改善のサイクルもこの2つに沿って回ります。日次の日報で架電結果を確認し、週1回の定例で1週間ぶんの傾向を振り返って改善の方向を決めます。スクリプトやリストの修正は定例を待たず、日報の段階で必要と判断すれば随時行います。

自社から何を戻すと改善が早いのか

いちばん効くのは商談結果のフィードバックです。アポイントの取り方そのものを直せます。

アポイントが商談として成立したか、成約に至ったか、至らなかった場合はなぜかが戻ってくると、代行会社側はアポイントの取り方を修正できます。逆に、商談結果が戻ってこない案件では、そのアポイントの質が良いのか悪いのかを判断できないため、同じ取り方が続いてしまいます。

つまり、依頼したあとに自社側でやることは商談結果を戻すことだと考えてください。この往復が回るかどうかで、同じ費用をかけても結果が変わります。かけた費用がどう返ってくるかの考え方はテレアポの費用対効果で解説しています。

グッドアポでどのように支援しているかは、グッドアポのサービス案内をご覧ください。

テストコールと導入の流れに関するよくある質問

Q. テストコールだけ依頼できますか？

A. テストコールは最低利用期間に含まれる工程のため、テストコールだけを切り出してのご依頼は受けていません。テストコールの結果をもとに改善し、本稼働まで一貫して支援する形をとっています。

Q. テストコールの費用は本稼働と別ですか？

A. グッドアポでは別途費用はかかりません。テストコールは本稼働と同じ契約の中で行います。

Q. 結果が悪ければ中止できますか？

A. 結果が悪い場合でも、すぐに中止するのではなく、どこで止まっているかを分析し、リストやスクリプトを改善して再度テストする形で進めます。最初の結果だけで判断するのではなく、改善を回したうえで本稼働に進めるかを判断します。

Q. 自社の社名を出して架電するのですか？

A. はい、発注いただいた企業の社名を名乗って架電します。そのため、スクリプトの内容を事前に確認・承認しておくことが重要になります。

Q. 通話の録音は共有されますか？

A. ご要望に応じて録音も共有しています。実際にどのような架電が行われているかを確認したい場合は、いつでもご確認いただけます。

グッドアポは、テレアポ代行をコール単価＋成果報酬のハイブリッド型で提供しています。リストの設計からスクリプトの作成、架電、日次の報告までを一貫して担当し、テストコールの結果をもとに改善を回しながら本稼働へ進めます。

アポイントの数だけを追うのではなく、その後の商談で噛み合うかどうかまで見て設計することを大切にしています。

まとめ

テストコールは、少量の架電で設計が通用するかを確かめ、本稼働に進めてよいかを見極める工程です。

リスト・スクリプト・ターゲットの設計が実際に通用するかを検証し、改善したうえで本稼働に移行します。

結果が悪くても、どこで止まっているかが分かれば改善の方向は定まります。テストコールは結果が悪くても改善の材料が手に入る工程なので、やって無駄になることはありません。依頼したあとの流れが見えていれば、最初の一歩を踏み出しやすくなります。

• 費用を知りたい方 → テレアポ代行の費用相場
• 代行会社を比べたい方 → テレアポ外注のチェックポイント
• 自社の場合を相談したい方 → お問い合わせ