「まずは無料で試させてください」。その一言で商談が前に進んだ気がして、意気揚々とアカウントを発行した。ところが2週間後、管理画面のログイン履歴は初日で止まっている。期間終了が近づいて「いかがでしたか」と連絡すると、返ってくるのは「すみません、バタバタしていて……正直、うちには合わなかったかもしれません」。評価された記憶すらないまま、案件は静かに閉じる。心当たりがあるなら、それは製品が負けたのではない。
結論から言う。トライアルやPoCが失敗する原因は、機能でも価格でもなく設計の不在だ。渡してから考えるのではなく、始める前に4点を決めておく。成功基準・評価者・期間と範囲・振り返りの場。この4つを相手と一緒に確定させるだけで、試用期間は消耗戦から受注への階段に変わる。
この記事では、なぜ使われないまま終わるのかという構造、始める前に決める4点、巻き込むべき3者、そして設計書と中間フォローをAIに作らせるプロンプトまでを一気に示す。読み終えるころには、トライアルは渡して待つものではなく、相手と一緒に走るものに変わっているはずだ。
前提の確認として、PoCとは概念実証のことだ。難しく聞こえるが、要は本格導入の前に小さく試して「うちの現場で本当に使えるか」を確かめる試験導入・お試し利用を指す。無料トライアルも、範囲を限定した有料の先行導入も、この記事では同じ設計思想で扱う。以下、まとめてトライアルと呼ぶ。
なぜトライアルは使われないまま終わるのか?
使われない理由は、相手の熱意が足りないからではない。日常業務の中に使う理由と使う時間が用意されていないからだ。裏を返せば、原因のほとんどは営業側が設計で潰せる。
現場で起きている症状を分解すると、原因は4つに収束する。
| 現場で起きること | 本当の原因 | 放置した結果 |
|---|---|---|
| 初日に触って、それ以降ログインがない | 現場に使う理由がない。既存のやり方で今日の仕事は回る | 新ツールが余計な一手間として扱われ、避けられる |
| 「誰か使ってる?」と社内で顔を見合わせる | 評価する人が決まっていない。全員のものは誰のものでもない | 責任の所在がなく、感想を語れる人が一人もいない |
| 「来週やります」が3回続く | 締切のない仕事は最後に回る。営業も情報システムも自分の数字が先 | 期間だけが消費され、検証が始まらない |
| 「便利そうだけど、劇的でもない」で止まる | 成功の定義が曖昧。比較する基準がない | なんとなく微妙が結論になり、現状維持が勝つ |
とくに厄介なのは4行目だ。人は変化のコストを実際より大きく見積もる。基準がなければ、多少の便利さは「今のやり方を変えるほどではない」と処理される。だから成功基準を先に決めることは、相手を縛るための手続きではなく、相手が正しく判断できるようにするための親切なのだ。
もう一つ言い添えておく。「まず試してみましょう」は営業側にとって都合のいい言葉である。断られたわけではないので、その日の商談は前に進んだ気になれる。だが実態は、判断を先送りする合意をしたにすぎない。トライアルの開始は進捗ではなく仕切り直しであると捉えたい。この認識がないまま渡した試用期間は、ほぼ確実に自然消滅する。
始める前に決める4点とは何か?
決めるべきは、成功基準・評価者・期間と範囲・振り返りの場だ。順番も重要で、上から順に決める。しかもこれは営業側が一人で決めるものではなく、相手と口に出して合意するものである。
| # | 決めること | 具体的に何を決めるか | 決めないとどうなるか |
|---|---|---|---|
| 1 | 成功基準 | 何がどうなったら導入と判断するか。数値または「できた・できない」で判定できる形にする | 終了後に「なんとなく微妙でした」で片づけられ、反論する材料が残らない |
| 2 | 評価者 | 誰が実際に使い、誰が導入を判断するか。氏名と人数まで確定させる | アカウントを配っただけで誰も責任を持たず、感想が一つも集まらない |
| 3 | 期間と範囲 | いつまで、どの業務・どのチームで試すか。対象外も明示する | 期間が曖昧なまま延び、忙しさに埋もれて着手されない |
| 4 | 振り返りの場 | 終了後の会議を、開始時点で日程確定させる | 終了と同時に音信不通になり、追いかける側が悪者になる |
成功基準は「業務指標」と「利用率」の2階建てで置く
成功基準は1つでは足りない。業務がどう変わったかを測る指標と、そもそも使われたかを測る指標の両方を置く。前者だけだと、使われなかった場合に評価が成立しない。
たとえば商談記録の自動要約ツールなら、こうなる。業務指標は「1件あたりの記録作成時間を30分から10分に短縮する」。利用率の指標は「対象5名が4週間で週3回以上使う」。加えて定性の確認項目として「要約の内容を、修正なしでそのまま上司に共有できるか」を置く。3つとも、終了時に○×で答えられる。
有料の先行導入なら、費用も基準に含める。仮に1ユーザーあたり月額30ドル、日本円で約4,770円のツールを10名で1か月試すなら、投資は約4万7,700円だ。ここに対して「月20時間の削減が見込めるか」を並べれば、相手の稟議は自力で組み立てられるようになる。金額の話を避けたまま設計すると、最後に予算の壁で止まる。予算の在り処を角を立てずに探る手順は、予算を聞き出す質問の作り方にまとめている。
期間は「短く、狭く」。長い試用は熱を奪う
期間は長ければ有利、ではない。3か月のトライアルは、最初の2か月半が空白になるだけだ。原則は2週間から4週間、対象業務は1つに絞る。範囲を狭めると相手の心理的な負担が下がり、着手が早まる。「営業部全員で全業務を試す」は失敗の設計であり、「新規開拓チーム5名の訪問記録だけ」が成功の設計である。
振り返りの場は、開始前にカレンダーを押さえる
4点のうち、もっとも効果が大きく、もっとも実行されていないのがこれだ。キックオフの場で「では最終日の翌週、○月○日の15時に結果を確認する会をお願いします」と言って、その場で招待を送る。日程が入っていれば、相手の中に締切が生まれる。締切のない仕事が後回しにされるのは、相手の性格ではなく人間の性質だ。日程を先に置くことは、その性質への対策である。
誰を巻き込むべきか?
現場担当だけを相手にしたトライアルは、成功しても決裁に届かない。必要なのは、決裁者・情報システム・現場の3者だ。役割が違えば見ている論点も違う。
| 役割 | 見ている論点 | トライアル中に担ってもらう仕事 | 巻き込まないと起きること |
|---|---|---|---|
| 決裁者(部長・本部長など) | 投資に見合うか。全体の数字がどう動くか | 成功基準の承認と、終了後の意思決定 | 現場が絶賛しても「今期は予算がない」で終わる |
| 情報システム | セキュリティ・既存システムとの接続・運用負荷 | 初期設定と社内規定の確認 | 検証の終盤で規定違反が判明し、全部やり直しになる |
| 現場担当(評価者) | 自分の仕事が楽になるか。覚える手間 | 実際の利用と、使いにくさのフィードバック | 数字は出ても「現場が反対している」で止まる |
3者のうち、営業が最も接触しやすいのは現場担当で、最も避けがちなのが情報システムだ。だが導入直前に最大の障害となるのも情報システムである。キックオフに1名だけでも同席してもらい、確認事項を先に潰しておく。これは遠回りではなく最短距離だ。
そして決裁者である。トライアルの承認をもらった時点で「終了後の判断はどなたが最終決定されますか」と確認しておく。ここで相手が言葉に詰まるなら、その案件は決裁ルートが見えていない。誰が意思決定に関わっているかを構造的に洗い出す手順は、購買に関わる人を洗い出すマッピングの方法で詳しく扱っている。トライアルの設計より前に、この地図を持っておきたい。
なお、3者すべてに毎回同席を求める必要はない。キックオフと振り返り会の2回だけ揃えばよい。回数を絞って、そのかわり必ず出てもらう。ここは譲らない交渉ポイントである。
PoCの設計書と中間フォローはどうAIに作らせるか?
ここからは実践だ。4点を決めると言われても、白紙から書き起こすのは骨が折れる。商材と相手の状況を差し込めば、設計書のたたき台は数分で出る。1本目は開始前、2本目は期間の中盤で使う。
あなたはB2B営業の実務に詳しいコンサルタントだ。これから始めるPoC(試験導入)の設計書を作ってほしい。
# 前提
- 自社の商材: 〔例: 営業支援AIツール。商談記録の自動要約とCRMへの自動入力〕
- 相手企業: 〔例: 製造業・従業員450名。営業部12名。SFAは導入済みだが入力が定着していない〕
- ヒアリング済みの課題: 〔例: 商談後の記録が後回しになり、部長が案件状況をリアルタイムに把握できない〕
- 決裁者と評価者: 〔例: 決裁者は営業本部長。評価者は営業課長1名と営業担当3名。情報システム部から1名が設定を担当〕
- 期間と対象範囲: 〔例: 4週間/新規開拓チーム5名/訪問商談の記録業務のみ〕
- 有償か無償か: 〔例: 無償トライアル〕
# 出力してほしいもの
1. このPoCの目的を、相手の言葉づかいで1文にまとめる
2. 成功基準を3つ。すべて数値または「できた・できない」で判定できる形にする。うち1つは利用率(誰が何回使ったか)の基準にすること
3. 役割分担の表。列は「役割/担当/このPoCでやること/判断すること」とし、氏名欄は空欄でよい
4. 4週間のスケジュール(週単位)。キックオフ・初期設定・中間チェック・最終計測・振り返り会を必ず含める
5. 中間チェックで確認する項目のリスト
6. 振り返り会の議題(60分想定・時間配分つき)
7. このPoCが失敗する要因を3つと、その予防策
相手にそのまま送れる文体で、専門用語は最小限にすること。
出てきた設計書は、こちらの提案書ではなく相手との合意文書として使う。キックオフの冒頭で画面に映し、成功基準の数値をその場で相手に修正させる。相手が自分で書き換えた数字は、こちらが出した数字より何倍も強い。
2本目は、期間の中盤で使う。利用状況が鈍いと気づいた瞬間に手を打つためのプロンプトだ。半分が過ぎた時点で動けば、まだ立て直せる。
進行中のPoC(試験導入)で利用が伸びていない。テコ入れ策と声かけの文面を作ってほしい。
# 状況
- 商材と用途: 〔例: 商談記録の自動要約ツール。訪問後の記録作成に使う想定〕
- 期間と経過: 〔例: 4週間のうち2週間が経過〕
- 当初の成功基準: 〔例: 対象5名が週3回以上使い、記録作成時間を1件30分から10分に短縮する〕
- 実際の利用状況: 〔例: 5名中2名しか使っていない。利用は合計6回。1名は初日のみ〕
- 相手側で起きていること: 〔例: 月末の追い込みで全員が多忙。設定を担当していた情報システム部の担当者が異動した〕
# 出力してほしいもの
1. 利用が伸びていない原因の仮説を5つ。それぞれに「これを確かめるための質問」を1つ添える
2. 残り期間で打てるテコ入れ策を5つ。効果と手間の2軸で優先順位をつける
3. 評価者(現場担当)へ送るチャット文面。責める調子にせず、こちらの手間で解決する提案を必ず含める
4. 決裁者へ送るメール文面。中間報告として事実を共有し、期間延長か対象縮小の判断を仰ぐ形にする
5. このまま自然消滅させないために、今週こちらが取るべき行動を3つ
文面はいずれも200字以内。日本語のビジネスメールとして自然な表現にすること。
中間フォローの原則は一つ。相手の手間を増やす依頼をしないことだ。「使ってください」と督促するのではなく、「こちらで初期設定を代行します」「30分だけ画面共有で一緒に1件やりましょう」と、こちらが動く提案に変える。トライアルが止まる理由の大半は意欲ではなく着手コストなので、そこを肩代わりすれば動き出す。
終了後の振り返りはどう進めるか?
振り返り会は感想戦ではない。決めるための会議だ。進め方は3段で固定する。成功基準に対する結果を一緒に確認し、使われた理由と使われなかった理由を分解し、次の意思決定をその場で握る。
第1段は、成功基準への答え合わせである。開始前に合意した3つの基準を並べ、それぞれに○×をつける。ここで営業側が結果を代弁してはいけない。相手に読み上げてもらう。自分の口から「記録時間は30分から12分になりました」と言った相手は、その事実を社内で自分の実績として語り始める。
第2段は、事実の分解だ。使われなかった事実も、隠さず材料として扱う。誰が使えなかったのか、いつ止まったのか、何が引っかかったのか。ここを一緒に掘ると、多くの場合は製品の問題ではなく運用の問題が出てくる。そして運用の問題は、こちらの支援で解決できる領域だ。
| 結果のパターン | 解釈 | その場で提案する次の一手 |
|---|---|---|
| 基準を達成し、利用も定着した | 導入判断の材料が揃っている | 対象範囲を広げた本導入の見積と、稟議に使う結果サマリーを提示する |
| 効果は出たが、使ったのは一部の人だけ | 製品は機能したが、運用が個人依存 | 定着支援を含めた導入プランを提案し、範囲を絞って開始する |
| ほとんど使われなかった | 評価が成立していない。判断材料がない | 原因を1つに特定し、対象を1業務まで絞った短期の再試行を提案する |
| 使ったが効果が出なかった | 課題と機能が噛み合っていない | 見送りを受け入れ、条件が変わる時期と再検討のきっかけを合意しておく |
第3段は、意思決定である。振り返り会を「導入・条件付きの延長・見送り」の3択で終わらせる。この3つを会議の冒頭で明示しておくのが要点だ。選択肢を示さないまま感想を聞くと、相手は無害な第4の答え、つまり「社内で検討します」を選ぶ。決めてもらう会議だと最初に宣言しておけば、その場に決裁者が座っている意味が生まれる。
見送りも成果として扱う。理由と、条件が変わる時期を記録して次につなげる。曖昧に終わった案件は追いかけようがないが、理由の明確な見送りは半年後に戻ってくる。ここで踏み込みすぎて関係を壊さずに合意を取る言葉の選び方は、AIを使ったクロージングの型を参照してほしい。振り返り会は、実質的にクロージングの場である。
Next Action:今日やる3つ
- 進行中のトライアル案件をすべて書き出し、成功基準・評価者・期間と範囲・振り返り会の日程のうち、決まっていない項目に印をつける。1つでも空欄なら、その案件は失注予定だと考える。
- 上の1本目のプロンプトに、いま最も大きい案件の情報を差し込んで設計書のたたき台を作り、相手と合意する版に整える。
- 振り返り会の日程が入っていない案件について、今日のうちに日程調整の連絡を送る。開催は終了直後で、決裁者の同席を条件として添える。
トライアルは、渡した瞬間に相手の課題になるのではない。最後まで営業側の設計責任のもとにある。試して終わりにしないための仕込みは、始める前の30分で決まる。


コメント