テレアポ組織向け KPIモニタリングダッシュボードの開発
テレアポ（電話によるアポイントメント獲得）チームの成果は、毎日数百件の架電履歴として積み上がる。架電数・アポ獲得率・案件ごとの転換率——数字は存在する。
問題は、それが「見える化」されていないことだ。
マネージャーはExcelを開き、今日の状況を手で集計する。アポインターは自分の達成率を把握できないまま次の架電に向かう。「誰が、どの案件で、今日どこまで届いているか」を瞬時に把握できるシステムを求める声は、どのテレアポ組織にも共通している。
数字はあった。つながっていなかっただけだ。
このクライアントのテレアポ組織は急速に拡大していた。アポインターが増え、案件が増え、担当者ごとの目標管理が属人化していた。「組織全体で何%達成しているか」と「誰がどの案件で今日何件こなしているか」——その両方を、同じシステムで見たい。それが要件の出発点だった。
もう一つの課題は、構造だった。クライアント→元請→中間2社→Linnoedgeという4社をまたぐ商流では、要件の確認1つで複数の承認ラインを通過する。「シンプルな追加要望」が、週単位の停滞を生む。その構造の中で、開発を遅らせないコミュニケーション設計が必要だった。
設計の出発点は「どこで見ても、速く動く」画面だった。
テレアポのアポインターは架電の合間にダッシュボードを確認する。2.5秒以上かかれば、それは「使えない」に等しい。SLAを2.5秒以内と定め、SQLクエリの最適化を最優先課題に置いた。
開発過程で、レスポンスタイムは2.69秒まで膨らんだ。0.19秒の差がSLA違反になる。インデックスの見直し、クエリの分割、キャッシュ戦略の再設計——「動く」から「使える」への最後の1マイルは、技術の詰めの作業だった。
ただ、一番難しかったのは「何を作らないか」を決めることだった。
当初の要件にはクロス集計機能が含まれていた。案件軸×担当者軸を組み合わせたマトリックス表示——ユーザーには便利に映る機能だ。だが実装工数は膨大で、5月末の納期に対してリスクが高すぎた。チームで協議し、クロス集計をスコープ外に戻した。「今必要なものを確実に届ける」——その判断が、プロジェクトを前に進めた。
「日軸」と「担当者軸」のタブで、自分が今日何件架電し、何件のアポイントを獲得し、案件ごとの達成率が何%かを即座に確認できる。次の架電に集中するための「現在地確認」が、10秒で完了する。
「全体軸」ではチーム全体の今日の達成状況を一覧できる。「案件軸」では、どの案件に工数が偏り、どの案件が達成率を下回っているかを把握できる。週次レビューに費やしていたExcel集計の時間が、不要になる。
「日軸」の月次トレンドビューでは、直近30日の日別アポ獲得数の推移と、月間ランキングを一画面で確認できる。「今月のチームがどう動いたか」が数字で可視化され、月次レポートをそのまま出力できる。
| Before | After | ||
|---|---|---|---|
| KPI確認 | Excelを手動で更新・集計 | → | ダッシュボードをリアルタイム参照 |
| 担当者の自己確認 | 上長に確認が必要 | → | 自分でタブを開いて即確認 |
| 案件別の偏り把握 | 週次のミーティングまで不明 | → | 「案件軸」タブで随時確認 |
| 応答時間 | 基準なし | → | SQL最適化でSLA 2.5秒以内に |