TL;DR(要約)
- 課題: Speeeでは、営業からCSへの引き継ぎがすべてテキストベースで行われていた。CSがフォーマットを送り、営業が記入し、CSが確認する。このラリーが1社あたり数十往復・約30分に及び、毎月の新規契約分が積み重なることで、CSが本来顧客に向き合うべき時間を大きく圧迫していた。
- 根本原因: 営業が書く議事録には個人の解釈が混ざり、引き継ぎまでの1〜2営業日で記憶も曖昧になっていた。CS側も受け取った情報の解釈に頼らざるをえず、実際に顧客と接すると事前情報と実態が食い違い、オンボーディングをやり直すケースも発生。共通する原因は「事実ベースで共有されていない」ことだった。
- 実施したこと: 全商談をtl;dvに記録し、録画と文字起こしという一次情報を基盤にした引き継ぎフローを構築。CSはAsk tl;dv AIに20種類以上の専用プロンプトを使って必要情報を抽出し、営業に確認してもらうだけで完結する仕組みに変えた。プロンプトは「早期に成果を出した顧客」の分析から逆算して設計し、チームに横展開している。
- 成果: 引き継ぎ工数が3分の2に削減。オンボーディング完了期間が23日短縮、機能継続利用率が15%向上。営業側も引き継ぎ時間の削減により1人あたり月7件の受注機会が増加した。
「事実ベースでさえ共有できていれば解決する。そこまで仮説が行き着いたので、tl;dvを導入しました」と語るのは、株式会社Speeeで自社SaaSのカスタマーサクセス(CS)を担う南 大貴氏だ。営業からCSへの引き継ぎだけで膨大な工数を費やしていた組織が、全商談の録画ログという「事実」を起点に変わり始めた。その実践の軌跡を聞いた。
企業紹介・背景
株式会社Speeeは2007年設立。企業へのマーケティングDXコンサルティングから、レガシー産業へのDX推進まで、24もの事業を展開する。南氏が所属するのはリフォームDX領域で、自社開発SaaS「Budii」(リフォーム業界向け営業支援ツール)のカスタマーサクセス第1号として、CS戦略からオペレーション設計も兼任する。
tl;dvを導入したきっかけは、営業からCSへの引き継ぎ課題だ。受注後の情報共有がテキストベースの往復に依存しており、工数と品質の両面でボトルネックが生じていた。この課題を構造的に解決する手段として、全商談の録画ログを基盤にする仕組みの構築に踏み切った。
導入前の課題:数十回のテキストラリーが日常だった
SpeeeのBudii事業は、マーケティング→インサイドセールス→フィールドセールス→カスタマーサクセス(CS)という、いわゆるザ・モデル型の組織体制を持つ。このモデルにおいてCSの成果を左右する最初の関門が、受注後の営業からCSへの引き継ぎだ。
導入前、引き継ぎはテキストベースで行われていた。営業から「受注しました」と連絡が来て、CSがフォーマットを送り、営業が記入し、CSが確認する——そのラリーが1社あたり数十回に及ぶことも珍しくなかった。
「フォーマットに『営業行為の可視化が導入目的です』と返ってきても、なぜ可視化したいのか、なぜ今できていないのかを我々は知りたいわけです。それを引き出すためにラリーを繰り返す。テキストベースでやっているのはかなり煩わしい。対面ミーティングをセットしたりもしていましたが、それでも1社あたり30分はかかっていました」
毎月コンスタントに新規契約が入るなか、1社あたり30分の引き継ぎが積み重なり、本来CSが顧客に向き合うべき時間が大きく圧迫されていた。
問題は工数だけでなく、質にもあった。各営業担当者が手書きで作る議事録は具体的すぎるか抽象的すぎるかに偏り、担当者ごとにばらつきが大きかった。結果、引き継ぎを受けたCSが顧客に接してみると事前情報と実態が食い違い、オンボーディングをやり直す事態も発生していた。
南氏はこの問題の根本を3点に整理した。営業の主観が混在すること。引き継ぎまでに1〜2営業日あくことで記憶が曖昧になること。受け手のCSも解釈に頼らざるをえないこと。そしてその共通点にたどり着いた。
「全部、事実ベースで共有されていないことが原因でした。逆に言えば、事実さえ共有できれば解決する。そこまで仮説が行き着いたので、tl;dvを導入しました」
なぜtl;dvを選んだのか
ツール選定の候補に挙がったのは、tl;dvと2つの国内サービス。
SpeeeのセキュリティガバナンスとしてAI学習にデータが使われる仕様のサービスは利用できないため、はじめに検討していた1社は利用が厳しかった。「AI学習を止めるにはエンタープライズプランが必要で、価格がかなり高くなってしまったんです。それで外れました」
次に検討していたサービスは、主軸が営業担当者の能力開発にあり、当時最も優先度が高かった引き継ぎの課題解決にはフィットしなかった。「引き継ぎや議事録の用途においては、文字起こしの精度も、情報の引き出しやすさも、tl;dvが一番良かったです。何より、Ask tl;dv AIの機能が決め手でした」
tl;dvに絞った後は、月額プランで3ヶ月のトライアルを行った。導入稟議を通すにあたっては、引き継ぎ工数の削減見込みを試算し、その分の営業リソースが商談に向かった場合の想定売上として提示した。ただし当時はAIツールが続々と登場していた時期でもあり、「本当にこれで効果が出るのか、もっと安いツールが出てくるのではないか」という懸念から、いきなり年間契約ではなく、まず仮説検証の期間として3ヶ月という判断になった。
3ヶ月の検証で成果を確認し、年間契約へ。さらにトライアルの結果が想定を上回ったことで、当初より規模の大きい体制へとライセンスを拡大した。
やったことはシンプルだった。全商談をtl;dvに記録する
「やったことは本当にシンプルで、全ての商談ログ基盤をtl;dvで構築する。それだけです」
数十往復のテキストラリーは消えた。営業が手書きで議事録を書く必要もなくなった。CSが欲しい情報を、欲しいタイミングで、事実に基づいて取り出せるようになった。
数十往復のテキストラリーは消えた。営業が手書きで議事録を書く必要もなくなった。CSが欲しい情報を、欲しいタイミングで、事実に基づいて取り出せるようになった。
Ask tl;dv AI:事実が残っているからこそ使える機能
この仕組みの核心にあるのが、tl;dvのAI機能だ。会議の録画と文字起こしという一次情報がそのまま保存されているからこそ、後から必要な情報を自由な切り口で引き出せる。
「テキストベースで作られた議事録には、書いた人の解釈が入ります。でも録画と文字起こしという事実が残っていれば、そこからAIが必要な情報だけを抽出してくれる。それが本当に大きい」
もっとも、ツールを導入しただけでチームに浸透したわけではなかった。オンボーディング当初は概念の説明が中心になり、メンバーが「これは便利だ」と実感するまでに時間がかかった。
南氏は自ら会議体ごとに異なるプロンプトを量産し、何度もチームに配り歩いた。
「実際に目の前で操作をしてみると『あ、これ便利じゃん』というのがイメージしやすくなる。概念より、まず手を動かしてもらうことが大事でした」
現在は20種類以上のプロンプトを使い分けている。新規商談の引き継ぎ用、定例会議用、解約リスクが高まった顧客向け——それぞれに特化したプロンプトが存在する。
プロンプト作成のプロセスも独自だ。まず「早期に成果を出した顧客」の要因を徹底的に分析する。「あの顧客がうまくいったのは、引き継ぎ時点でこの情報があったからだ」という視点で、本当に必要な情報を洗い出す。次に、その情報要件を生成AIに渡してプロンプトの初稿を生成させる。できた初稿をtl;dvで実際にテストし、十数回、時には数十回繰り返しながら精度を確認して調整する。ようやく納得できるプロンプトが完成したら、チームに横展開して保存する。
「プロンプトを作るのは最初かなりハードルが高かったです。でも1回作ってしまえば組織の資産になります。チームみんなで横展開できるように作っておくことが大事だと思っています」
南氏がプロンプト設計で重視するルールは4つある。
① 表現のブレを除去する フォントサイズや絵文字の有無まで指定して出力形式を統一する。毎回ばらついていると後続の処理がやりにくくなるため、ここは必ず指定が必要だ。
② 固有名詞は選択式で補完するtl;dvはAI学習を外部に使わない設計のため、会社名などの固有名詞の精度が下がることがある。あらかじめ選択肢として設定しておくことで、意図した内容が返ってきやすくなる。
③ 各項目は「三段活用」で記述させる 長い文章ではなく、短く・濃く・一定のフォーマットで情報が返ってくるよう構成する。読み手が素早くキャッチできる構造を設計しておく。
④根拠となる録音箇所も一緒に出力させる AIが判断の根拠にした発言のタイムスタンプも合わせて取得する。「顧客の感情温度みたいなものが文字だけではわからない場合に、録音を聞きに行ける。そこが一番大事だと思っています」
導入後の変化:CSだけでなく、営業も変わった
導入の効果は、CSと営業の両サイドに出た。
CSの引き継ぎ工数は、3分の2の削減に成功した。質の高い引き継ぎができるようになったことでオンボーディングのやり直しがなくなり、オンボーディング完了期間は23日短縮。機能の継続利用率も15%向上した。
営業側も変わった。これまで引き継ぎに割いていた時間が削減されたことで、その分を商談に充てられるようになり、1人あたりの月間受注機会が7件増加した。
「録画という事実ベースで引き継ぎを行うことで、CSが顧客に初めて接するときの解像度が格段に上がりました。『この人がこういうことを気にしていた』というのが最初の接触の前からわかっている。そこから始められるのは、オンボーディングの質に直結しています」
次の挑戦:tl;dvを「商談の先生」に。能力開発ツールへの進化
南氏が今後に向けて描いているのは、引き継ぎや議事録という枠を大きく超えた活用だ。
「最初はtl;dvを議事録ツールだと思っていました。でも使い続けていると、商談の先輩とか先生みたいなポジションに進化できるんじゃないかと気づきました」
現在検証中なのが、Claudeと組み合わせた「仮想上長」の仕組みだ。Claudeに上長の人格を形成させ、tl;dvに蓄積された商談データを定期的に自動で流し込む。すると、その上長が「この商談ではゴール設定の定量化が弱かった」「次はこのアクションを取れ」というフィードバックと次のアクションを自動で提示してくれる——そういう仕組みを計画している。
「人員不足が当たり前になった今、AIに任せる領域と、人でなければ価値を出せない領域を見極めることがこの時代を生き抜く鍵だと思っています。少ない人数で成果を出したいという企業こそ、tl;dvを導入してほしい。人にしかできないことに全リソースを割ける環境がつくれます」
「人員不足が当たり前になった今、AIに任せる領域と、人でなければ価値を出せない領域を見極めることがこの時代を生き抜く鍵だと思っています。少ない人数で成果を出したいという企業こそ、tl;dvを導入してほしい。人にしかできないことに全リソースを割ける環境がつくれます」
まとめ
Speeeにとってtl;dvは、「引き継ぎの課題を解決するツール」として始まった。しかしその本質は、商談という事実をそのままログとして残し、組織が必要なときに必要な情報を正確に引き出せる状態をつくることにある。
南氏がたどり着いた答えはシンプルだ。事実を記録し続けること。そこから、営業とCSが同じ情報をもとに動き、顧客が最短で成果を出せるプロセスが生まれる。そしてその先に、蓄積された商談データを起点とした組織全体の能力開発という、より大きな可能性が広がっている。
「引き継ぎとか議事録だけで終わらせない、いろんな可能性を秘めているのがtl;dvなのかなと思っています。そこの視野を持ちながら使っていただけると嬉しいです」という南氏の言葉は、ツールの枠を超えた活用を実践してきた者だからこそ持てるリアルな確信だ。



