CHAPTER 01
作業開始・中断・終了報告
稼働の開始・中断・終了を Slack で正しく報告し、PMと認識を揃えるための必須業務です。
作業報告について
作業を始める際は、必ず該当案件の「作業報告」チャンネルに報告をしてください。報告なしで作業を開始することは、進捗確認や管理の観点で認識齟齬の原因となるため、原則NGです。
また、報告時は必ず大串にメンションを付けて提出してください。メンションがない場合、報告が埋もれて確認漏れにつながる可能性があるため、必須ルールとします。
加えて、作業報告で提出する時間は「架電時間」としてください。ここでいう架電時間とは、実際に架電を行っている時間を指します。
分析、リスト整理、事前準備などの作業は稼働開始前・終了後に実施し、作業報告に記載する時間 = 架電時間 となるよう、徹底をお願いいたします。
稼働時間の定義にばらつきが出ると、正確な実績把握や案件ごとの生産性分析が難しくなるため、「作業報告の時間 = 架電時間」で統一をお願いいたします。
注意点
・メッセージ送る際は左記のメッセージを送ってスレを立て、そのスレの中に「作業開始・中断・終了」の報告をすること
・各担当の状況を追いやすくするため／後からチェックしやすいように
作業開始時のスレッド名
○/○ 日次報告（名前）
作業開始報告テンプレ
＜作業開始報告＞
只今より、作業開始いたします！
架電時間 ：
架電時間帯：
目標架電数：
目標アポ数：
作業開始報告（例）
5分前には開始報告をあげて、開始まではスクリプトの読み込みなど事前準備をして、架電時間を有効的に使うこと
＜作業開始報告＞
只今より、作業開始いたします！
架電時間 ：7時間
架電時間帯：9:00-12:00、13:00-16:00、17:00-18:00
目標架電数：210件
目標アポ数：3件
作業中断報告テンプレ
＜作業中断報告＞
只今より、作業中断いたします！
○時に稼働再開します！
作業中断報告（例）
休憩入るときには必ず報告をあげること
＜作業中断報告＞
只今より、作業中断いたします！
13時に稼働再開します！
作業終了報告テンプレ
＜作業終了報告＞
本日の架電を終了いたします！
▼結果
架電時間：
架電数 ：
アポ数 ：
▼課題/解決策
課題①
→
解決策①
→
課題②
→
解決策②
→
▼報告/相談/質問
・
・
作業終了報告（例）
※APIとは「1時間あたりのアポ数」
API＝アポ数 ÷ 架電時間
API＝アポ数 ÷ 架電時間
＜作業終了報告＞
本日の架電を終了いたします！
▼結果
架電時間：7時間
架電数 ：213件
アポ数 ：4件
API ：0.57
▼本日の良かった点
・受付突破後、担当者へ繋がった際の第一声を簡潔にしたことで、序盤で話を切られにくくなった
・失注になりそうな場合に「一度情報収集としてでも」と着地を柔らかくしたことで、商談ハードルを下げてアポ獲得に繋げられた
・午前中に通電率が高い業種を優先して架電したことで、効率よく会話数を確保できた
▼課題/解決策
課題①
→担当者に繋がった際、サービス説明を丁寧にしようとして少し長くなり、相手が要件を掴む前に温度感が下がる場面があった。
解決策①
→冒頭15秒で伝える内容を「何の件か」「なぜ連絡したか」「どういう企業向けか」の3点に絞る。
課題②
→受付から担当者に取り次いでもらえる企業と、受付で止まる企業の差があったが、受付突破トークを状況別に使い分け切れていなかった。
解決策②
→受付突破トークを2〜3パターン準備し、相手の反応に応じて使い分ける。
▼報告/相談/質問
・本日は担当者接続後のアポ率は悪くなかったため、課題は通電数・接続数の最大化にあると感じています
・受付突破トークについて、成果が出ている型があれば共有いただきたいです
・不在先の再架電時間を明日からずらして検証したいため、優先順位の付け方に問題なければこのまま進めます
CHAPTER 02
架電リストの作成依頼
リスト依頼の出し方・記載項目をまとめています。空き時間を作らないために事前依頼を徹底しましょう。
リスト作成について
架電担当者に求めるのは、渡されたリストをそのまま消化することではありません。現場での反応をもとに、自ら必要なリスト条件を考え、オーダーし、PDCAを回しながら成果最大化を目指すことを求めています。
アポイント獲得は、営業力だけで決まるものではなく、リストの質によっても成果が大きく変わります。そのため、現場で架電している担当者自身がリスト改善に関与することは必須です。
リストは短期間で大量に作成できるため、「用意された件数をかけ切ること」が目的になってはいけません。
実際の反応を見て、ターゲットがズレている、反応が薄いと判断した場合は、早急に別条件でリストを依頼し、より成果の出る対象へ切り替えることが重要です。
限られた1日1日の稼働を無駄にしないためにも、常に反応を見ながら、スピード感を持ってリスト改善まで行う意識を持ってください。
依頼するタイミング
以下に当てはまる場合は、リスト作成依頼を行います。
- 現在のリスト残数が少ない
- 通電率が低すぎる
- ターゲット条件がズレている
- 反応の良い業種／規模が新たに見えてきた
- 新しい訴求軸で検証したい（成果状況によって要相談）
設定可能なセグメント
SalesNow等のリスト作成ツールで指定できるセグメント条件をベースに依頼してください。業種・売上・従業員数・地域・部署・決裁権など、複数条件を組み合わせることで精度を高められます。
依頼時のFMT
お世話になっております！
〜〜（リスト補充の理由）のため、リスト作成をお願いいたします！
【条件】
・業種 ：
・従業員：○〜○名
・規模 ：
・その他：
・件数 ：
・共有 ：
依頼時のFMT（例）
お世話になっております！
現在のリストで架電を進めたところ、反応が薄くターゲット条件の見直しが必要と判断したため、リスト作成をお願いいたします！
【条件】
・業種 ：人材、IT、コンサル
・従業員：50〜300名
・規模 ：中小〜中堅企業
・その他：採用を積極的に行っていそうな企業を優先／代表・人事責任者・採用責任者が対象
・件数 ：300件
注意点
- 「良いリストをお願いします」だけではNG。必ず条件を具体化すること
- 反応の良い条件が見えているなら、感覚ではなく数値ベースで依頼すること
- 件数だけを追って条件を広げすぎないこと
よくあるミス
- ターゲットが広すぎる
- 目的が不明で、検証にならないリストになる
- 仮説がない状態での依頼
CHAPTER 03
日次分析
毎日の架電結果を分析し、改善ポイントを発見するためのフローです。
分析について
架電業務において求められるのは、ただ架電件数をこなすことではなく、結果をもとに改善を繰り返すことです。そのため、分析は任意の振り返りではなく、成果を上げるための必須業務として捉えてください。
アポイントが取れた・取れなかったという結果だけで終わるのではなく、なぜその結果になったのかを分解し、次回以降の改善につなげることが重要です。
分析の際は、感覚で「なんとなく反応が悪かった」「リストが合わなかった気がする」と判断するのではなく、実際の反応・数値・現場感をもとに、課題を特定することを徹底してください。
特に確認すべき観点
- リストは適切だったか
- ターゲットは合っていたか
- 第一声や導入トークに問題はなかったか
- 受付突破の精度はどうだったか
- 接続後の訴求内容は刺さっていたか
- どの断り文句が多かったか
- どのセグメントの反応が良かったか／悪かったか
分析の出し方
分析の目的は、単なる報告ではありません。「課題を見つけること」ではなく、「次に何を変えるべきかを明確にすること」までが分析です。
分析を出す際は、結果 → 課題 → 改善案 の順で整理し、次回の架電に反映できる状態まで落とし込んでください。
成果が悪かった際に、単に「リストが悪かった」「反応が悪かった」で終わらせるのはNGです。そのような抽象的な結論では改善につながりません。
重要なのは、
- どの業種で反応が悪かったのか
- どの役職で接続しづらかったのか
- どのトーク部分で離脱されたのか
- どの切り返しが通用しなかったのか
まで具体化することです。
分析が浅いと、同じ失敗を繰り返します。逆に、分析ができていれば、架電の質・リストの質・スクリプトの質を継続的に改善できます。
弊社では、架電して終わりではなく、分析まで含めて架電業務と考えています。毎回の結果を次に活かす意識を持ち、必ず改善につながる分析を行ってください。
弊社では、架電して終わりではなく、分析まで含めて架電業務と考えています。毎回の結果を次に活かす意識を持ち、必ず改善につながる分析を行ってください。
悪い例
・反応が悪かったです
・受付突破できませんでした
・もっと頑張ります
良い例
・建設業は通電率は高い一方で、採用責任者接続後の温度感が低く、現行訴求との相性が弱い可能性がある
・従業員100名未満企業では代表接続率が高く、短い訴求の方が反応が良かった
・「資料だけほしい」が多発しており、商談化の価値訴求より情報提供の印象が強く出ている可能性がある
注意点
- 数字だけ並べて終わらない
- 感覚ではなく、できるだけ事実ベースで整理する
- 課題は1つずつなく、優先順位をつける
- 改善策は「誰が・何を・いつから」まで落とす
分析の共有方法
分析は、頭の中で考えて終わりにするものではなく、必ず言語化し、チームに共有することまで含めて実施してください。どれだけ現場で気づきがあっても、共有されなければ改善にはつながりません。そのため、分析は必ず以下いずれかの方法で共有することをルールとします。
① 毎日の作業終了報告で共有する
日々の架電の中で見えた課題や改善点は、その日の作業終了報告内で共有してください。特に、以下のような内容は日次での共有が必要です。
- 反応の良かった業種・役職・企業規模
- 反応の悪かったリスト条件
- 受付突破で詰まったポイント
- 担当者接続後に刺さった訴求
- 多かった断り文句
- 翌日すぐ修正すべき課題
日次で共有すべき内容を溜め込むと、改善のスピードが落ちます。その日中に共有すべき気づきは、必ず作業終了報告で出してください。
② MTG前に分析し、MTGで報告する
日々の反応を踏まえたうえで、週単位・一定期間単位で整理した内容については、MTG前に分析をまとめ、MTGの場で報告してください。MTGでは、単なる感想共有ではなく、以下を整理した状態で報告することを求めます。
- 数値結果
- 良かった点
- 課題
- 課題が起きた要因の仮説
- 次回以降の改善案
MTGの場でその場しのぎの感想を話すのではなく、事前に分析した内容をもとに、改善に繋がる報告を行うことが前提です。
CHAPTER 04
週次MTG
週次MTGに向けた準備と、振り返りで成果を最大化するための観点を解説します。
週次MTGについて
週次MTGは、単なる進捗共有の場ではありません。1週間の架電結果を振り返り、課題を整理し、次週の改善アクションを明確にするための場です。
そのため、週次MTGでは「頑張った」「反応が悪かった」といった感想ベースの共有ではなく、結果・要因・改善策まで整理したうえで参加することを前提とします。
週次MTGの目的は、現状報告をすることではなく、成果を上げるための判断と改善を行うことです。そのため、事前準備が不十分な状態で参加することはNGです。
週次MTGでの重要な考え方
週次MTGで最も重要なのは、うまくいかなかったことを報告することではなく、改善につながる形で共有することです。
結果が悪かった場合でも、要因が整理され、次の打ち手が明確であれば意味があります。一方で、結果だけを報告して終わるMTGには価値がありません。
また、良かった結果についても、「たまたま取れた」で終わらせず、なぜ取れたのかを言語化して再現性を高めることが必要です。
週次MTGは、毎週の結果を積み上げて改善の精度を上げるための時間です。ただ参加するのではなく、次週の成果を上げるための場として使う意識を持ってください。
報告FMT
【〜〜案件 ○/○〜○/○ 週次MTG】
#数値
・架電数：
・通電数：
・通電率：
・アポ数：
・アポ率：
・着座数：
・着座率：
・CPH ：
・API ：
#アジェンダ（擦り合わせたいこと/相談事項/共有/アイデア）
1.
2.
3.
4.
5.
#課題と解決策
課題①
└
解決策①
└
課題②
└
解決策②
└
各項目の記載ルール
▼ 数値
数値は、週次MTGの土台となる最重要項目です。感覚ではなく、必ず事実ベースで記載してください。
・架電数：その週に行った総架電数
・通電数：受付・担当者含め実際につながった件数
・通電率：架電数に対する通電数の割合
・アポ数：獲得できたアポイント数
・アポ率：架電数または通電数に対するアポ率
・着座数：実際に商談実施まで至った件数
・着座率：アポ数に対する着座数の割合
・CPH：1時間あたりの架電件数
・API：1時間あたりのアポ獲得数
・架電数：その週に行った総架電数
・通電数：受付・担当者含め実際につながった件数
・通電率：架電数に対する通電数の割合
・アポ数：獲得できたアポイント数
・アポ率：架電数または通電数に対するアポ率
・着座数：実際に商談実施まで至った件数
・着座率：アポ数に対する着座数の割合
・CPH：1時間あたりの架電件数
・API：1時間あたりのアポ獲得数
▼ アジェンダ
アジェンダには、MTG内で擦り合わせたいことを記載してください。ここは単なるメモではなく、MTGの時間を有効に使うための事前整理欄です。
記載すべき内容の例：
・反応が良かった業種を来週も優先すべきか
・特定の断り文句に対する切り返しを追加したい
・リスト条件を変更したい
・スクリプトの冒頭訴求を見直したい
・架電時間帯の見直しを相談したい
「特にありません」で終わるのではなく、現場で感じたことの中で、改善や意思決定が必要なものを必ず持ち込むことを意識してください。
記載すべき内容の例：
・反応が良かった業種を来週も優先すべきか
・特定の断り文句に対する切り返しを追加したい
・リスト条件を変更したい
・スクリプトの冒頭訴求を見直したい
・架電時間帯の見直しを相談したい
「特にありません」で終わるのではなく、現場で感じたことの中で、改善や意思決定が必要なものを必ず持ち込むことを意識してください。
▼ 課題と解決策
週次MTGでは、課題を出すだけでは不十分です。必ず解決策までセットで記載してください。
記載の考え方：
・課題は具体的に書く
・解決策は実行できる内容にする
・抽象的な表現で終わらせない
・「誰が見ても次の動きが分かる状態」で書く
記載の考え方：
・課題は具体的に書く
・解決策は実行できる内容にする
・抽象的な表現で終わらせない
・「誰が見ても次の動きが分かる状態」で書く
CHAPTER 05
スクリプト更新 / 切り返し集の更新
継続的な改善のためのスクリプト更新フロー。気づいた切り返しは即座に共有しましょう。
スクリプト更新／切り返し集の更新について
架電業務において、スクリプトや切り返し集は一度作って終わりではありません。実際の架電結果をもとに、継続的に改善し続ける前提のものです。
そのため、現場で架電していて違和感があった点や、反応が悪かった箇所、逆に反応が良かった言い回しについては、都度見直しを行い、スクリプト更新／切り返し集の更新につなげることを求めます。
「今あるものをそのまま使い続ける」のではなく、よりアポが取れる言い回しに改善していくことも、架電担当者の重要な役割です。
更新が必要なタイミングについて
以下のような場合は、スクリプトまたは切り返し集の更新を検討してください。
- 同じ箇所で何度も切られている
- 受付突破が明らかに弱い
- 担当者接続後の冒頭反応が悪い
- 同じ断り文句が頻発している
- 既存の切り返しでは返せないケースが増えている
- 特定の言い回しで反応が良かった
- 架電を通して、より自然で通りやすい表現が見えた
スクリプトや切り返し集に違和感があるのに放置すると、同じ失注を繰り返すことになります。現場で気づいた改善点は、そのままにせず、必ず更新候補として共有してください。
スクリプト更新で意識すべきこと
スクリプト更新の目的は、文面を綺麗にすることではありません。成果につながる表現へ改善することです。
そのため、更新時は以下の観点で考えてください。
- 第一声が長すぎないか
- 要件が分かりづらくなっていないか
- 売り込み感が強すぎないか
- 相手にとってのメリットが伝わっているか
- 自然な会話として成立しているか
- 実際の現場で使いやすいか
- 受付用、担当者用で言い回しが適切に分かれているか
単に言い回しを変えるのではなく、なぜ変えるのか、どの反応を改善したいのかを明確にしたうえで更新してください。
切り返し集の更新で意識すべきこと
切り返し集は、断り文句に対して無理やり押し返すためのものではありません。相手の反応を踏まえつつ、会話を前に進めるための型です。
そのため、よく出る断り文句や、実際に困ったケースについては、都度切り返し集に反映し、誰が対応しても一定水準で返せる状態を作る必要があります。
特に追加・更新すべき内容は以下です。
- 頻出する断り文句
- 既存の切り返しで対応しづらいケース
- 実際に通った切り返し
- 言い方を変えたことで反応が改善したもの
- 業種や役職ごとに有効だった返し方
切り返しは個人の感覚に頼るのではなく、チームで再現できる形に落とし込むことが重要です。
更新時の基本ルール
スクリプト更新／切り返し集の更新を行う際は、以下を意識してください。
- ① 感覚だけで変えない — 「なんとなく微妙だった」で変えるのではなく、どこで反応が悪かったのか、何が引っかかっているのかを整理したうえで更新してください。
- ② 変更理由を明確にする — なぜその文言を変えるのか分からない状態での更新はNGです。改善したいポイントと変更意図を明確にしてください。
- ③ 実際の現場で使える表現にする — 文章として綺麗でも、口頭で言いにくいものは意味がありません。実際に架電で自然に使える表現かどうかを必ず意識してください。
- ④ 良かった表現も必ず残す — 悪かった点だけでなく、反応が良かった言い回しも更新対象です。成果が出た表現は、個人の中で終わらせず必ず共有してください。
- ⑤ 更新して終わりにしない — 更新した内容は、実際に使ってみて再度反応を確認し、改善されたかどうかまで検証することが必要です。
共有・更新の進め方
現場で気づいた改善点については、以下の流れで進めてください。
- 1. 架電中に違和感や頻出反応を把握する
- 2. どの箇所に問題があるか整理する
- 3. 修正案を考える
- 4. 作業終了報告またはMTGで共有する
- 5. 必要に応じてスクリプト／切り返し集に反映する
- 6. 更新後の反応を再度確認する
気づく → 共有する → 更新する → 検証する
この流れを回すことが前提です。
この流れを回すことが前提です。
CHAPTER 06
音声修正
音声フィードバックを受けた時の対応と、改善サイクルの回し方です。
音声修正について
音声修正は、架電内容の良し悪しを感覚で判断するためのものではなく、実際の音声をもとに、成果につながる話し方へ改善していくための重要な業務です。
架電は、スクリプトが同じでも、話すスピード・トーン・間の取り方・語尾・抑揚によって結果が大きく変わります。そのため、内容だけでなく、話し方そのものを改善していく必要があります。
音声については、基本的にこちらで実際の音声を確認し、フィードバックを行います。そのため、フィードバックを受けた際は、単に確認して終わりではなく、次回以降の架電に必ず反映することを前提としてください。
音声修正の進め方
音声修正は、基本的に以下の流れで進行します。
- 1. 架電音声を確認する
- 2. こちらで内容を聞いたうえでフィードバックを行う
- 3. 修正すべきポイントを把握する
- 4. 次回以降の架電で修正内容を反映する
- 5. 再度音声を確認し、改善できているかを確認する
音声を提出して終わり、フィードバックを受けて終わりでは意味がありません。修正内容を実際の架電に反映し、改善できて初めて音声修正として成立します。
フィードバック時に確認する主なポイント
音声修正では、主に以下の観点でフィードバックを行います。
- 第一声の明るさ
- 話すスピード
- 声のトーン
- 抑揚の有無
- 語尾の強さ・弱さ
- 要件の伝わりやすさ
- 売り込み感の強さ
- 相手に被せず話せているか
- 受付突破時の自然さ
- 切り返し時の落ち着き
- 担当者接続後の入り方
- 全体として自信を持って話せているか
トーク内容が正しくても、話し方に問題があると、受付突破率や担当者接続後の反応は大きく落ちます。そのため、内容だけでなく、音声面の修正も必須です。
フィードバックを受けた後のルール
音声修正のフィードバックを受けた後は、必ず修正点を意識して次回以降の架電に反映してください。
特に、以下のような対応はNGです。
- フィードバックを読んで終わる
- どこを直すべきか整理しない
- 同じ指摘を繰り返し受ける
- 修正せず元の話し方のまま続ける
- 改善しようとする意識が見えない
音声修正は、指摘を受けるためのものではなく、成果を上げるために自分の話し方を改善するためのものです。フィードバックを受けた場合は、必ず次回の架電で改善を意識してください。