「検証はうまくいきました。ただ、もう少し確認したいので、もう一期間お願いできますか」
PoCを担当した営業なら、一度はこの言葉を聞いたことがあるのではないでしょうか。結果は悪くない。
担当者の反応も良い。それなのに、本導入の話は進まず、追加検証の要望だけが積み重なっていく。
この状況は、製品の力不足や顧客の意欲の問題として片付けられがちです。
しかし多くの場合、原因は別のところにあります。PoCが「終わる条件」は決めていても、「本導入を判断する条件」が決まっていないのです。
本記事では、営業の立場から、PoC開始前に合意しておくべき評価基準、検証中の変更管理、終了後に選択肢を整理する方法を解説します。
「まず試してみましょう」で始まった商談を、「何が分かれば導入を決められるか」が共有された商談に変えるための考え方をまとめました。
検証結果は悪くないのに、PoCが終わっても本導入の話が進まない。
追加の検証を求められ、当初の目的が分からないまま期間だけが延びている。
BtoBのIT・SaaS商談では、試すことには合意できても、その後に何を判断するかが決まっていない場合があります。
PoCは、実現可能性や適用可能性を限られた範囲で確かめる検証です。
本導入では、それに加えて、業務で継続して使えるか、担当や費用を確保できるかなどの判断が必要になります。
そのため、技術的に動いたという結果だけで、購入や全社展開が決まるとは限りません。
本記事では、営業の立場から、PoC開始前に決める評価基準、検証中の変更管理、終了後の判断の進め方を解説します。
PoCが本導入に進まない背景には、製品の力不足や顧客の意欲だけでは説明できない要因があります。ここでは、試す目的、成功条件、検証担当者と導入判断者のつながり、本導入時の運用、費用と導入範囲という五つの観点から主な原因を整理します。自社の商談がどこで止まっているかを確認する手がかりにしてください。
まず試してみるという合意だけで始めると、結果を見ても成功かどうかを判断できません。
新しい技術を知りたいのか、特定の業務に使えるか確かめたいのか、導入候補を絞りたいのかで、必要な検証が変わります。
目的が情報収集なら、それ自体は問題ではありません。
ただし、営業側だけが受注を前提として準備を進めると、期待がずれます。
開始時点で、今回の検証がどの判断につながるのかを合わせる必要があります。
当初は処理できればよいという話だったのに、終了時には別の業務や大量のデータへの対応まで求められることがあります。
必要な条件が検証を通じて明らかになることはありますが、評価範囲を更新しなければ、いつまで経っても完了できません。
当初の条件で確認できたことと、新しく検証すべきことを分けて扱いましょう。
現場の担当者が試用していても、予算や運用を判断する責任者が結果を確認する予定になっていない場合があります。
その状態では、検証レポートを渡しても、次にどこで検討するのかが決まりません。
誰が結果をまとめ、誰が導入の可否を判断し、どの場で確認するのかを整理します。
営業がすべての関係者に直接会うことだけが方法ではありません。
担当者を通じて必要な判断事項を確認し、結果が届く経路を合意することも重要です。
PoCでは詳しい担当者が支援して動かせても、通常業務では同じ体制を続けられないことがあります。
誰がデータを準備し、エラーを確認し、結果を業務へ反映するのかが未定なら、本導入は判断しにくくなります。
検証時だけの特別対応と、本導入後の標準的な作業を分けて示しましょう。
無料や小規模な検証に合意できても、本導入の費用や対象人数を検討していない場合があります。
最終見積もりを最初から確定する必要はありませんが、想定する規模と費用の考え方は共有しておきます。
検証終了後に初めて大きな費用が必要だと分かると、別の検討を最初から始めることになります。
PoCを本導入の判断につなげるには、何が分かれば導入を決められるかを開始前に顧客と合意しておくことが重要です。ここでは、解決したい業務課題の絞り込み、評価する項目と測定方法の決め方、合格・追加確認・見送りの条件の用意について説明します。あわせて、技術・業務・運用・費用に分けた評価項目の表、問い合わせ対応の検索支援を検証する仮例、時間削減を測るときに作業範囲をそろえる考え方も紹介します。
検証対象を広げすぎると、どの結果が重要なのか分かりにくくなります。
たとえば、社内文書の活用全体を改善するという目標より、問い合わせ担当が必要な規程を探す業務を対象にする方が確認しやすくなります。
対象とする利用者、データ、作業の始まりと終わりを整理します。
関連していても今回扱わない業務は、対象外として明記します。
精度が高い、使いやすいという表現だけでは、評価者によって結論が変わります。
何を一件として評価するか、誰が確認するか、どのデータを使うかを決めます。
人の判断が必要な項目では、正しいとする条件や、意見が分かれたときの確認方法も整理します。
検証後に都合のよいデータだけを選ばないよう、対象を選ぶ考え方を先に合意しましょう。
成功か失敗かの二択だけでは、一部の条件を満たした結果を扱いにくくなります。
想定範囲で本導入へ進める、対象を限定すれば進める、重要な未確認事項がある、現時点では見送るという選択肢を用意します。
追加確認する場合も、何を確認すれば結論を出せるのかを決めます。
延長すること自体を次の行動にしないことが大切です。
| 観点 | 確認する内容 | 判断のために残す情報 |
|---|---|---|
| 技術 | 想定条件で必要な処理ができるか | 対象データ、処理条件、成功と不成功の結果 |
| 業務 | 現在の作業に役立つか | 作業手順、確認や修正を含む負担、利用者の評価 |
| 運用 | 継続して利用できる体制があるか | 担当、例外対応、日常の作業、支援範囲 |
| 費用 | 想定範囲で費用を負担できるか | 利用規模、費用の前提、追加対応の条件 |
| 判断 | 導入の可否を決める経路があるか | 判断者、確認する場、必要な資料と予定 |
すべての項目をPoC内で実測する必要はありません。
実測できる項目、資料で確認する項目、本導入の前に別途確認する項目を分けておきます。
未確認であることを明示できれば、そのまま導入へ進めると誤解されることを防げます。
以下は評価設計を説明するための仮例であり、実際の製品性能や導入実績を示すものではありません。
社内規程を探す作業について、検索支援サービスが使えるか確かめる場面を考えます。
対象は、よくある問い合わせと、判断が難しい問い合わせを含めて選びます。
簡単な質問だけで構成すると、実業務で困る条件を確認できないためです。
評価では、必要な規程へ到達できたか、誤った情報を示していないか、担当者の確認や修正にどれだけ作業が必要かを分けて見ます。
たとえば30件を評価し、24件で必要な情報へ到達できた場合、その評価集合における到達割合は24件÷30件×100で80％です。
ただし、この数値だけで全業務の80％に対応できるとは言えません。
選んだ質問の範囲、難易度、データの状態に限った結果であり、未評価の業務へそのまま広げないことが重要です。
また、残る6件に重大な誤案内が含まれるなら、単純な平均だけでは判断できません。
誤りの種類や影響を確認し、人の確認が必要な範囲を整理します。
合格とする割合や許容できない条件は、この例の数字を流用せず、対象業務の影響を踏まえて顧客と決めましょう。
処理時間が短くなっても、結果の確認や修正に時間がかかれば、業務全体では削減にならない場合があります。
比較する際は、入力準備、処理、確認、修正、最終的な完了までのどこを測るかをそろえます。
導入前はすべての作業、導入後は自動処理部分だけという測り方では、同じ条件の比較になりません。
担当者の慣れや案件の難易度にも影響されるため、対象条件を記録します。
少ない件数で得た時間差を、そのまま全社の年間削減額として断定しないようにしましょう。
将来の試算を示す場合は、対象件数、利用割合、確認工数などの仮定を明示し、実測と分けて扱います。
PoCの検証中には、追加要望や途中で見つかった制約によって、当初の条件が変わることがあります。ここでは、追加要望と今回の範囲の関係の確認、途中結果の共有、データ不足と効果がない結果の区別について解説します。
別部署でも使いたい、対象データを増やしたいという要望は、新しい可能性でもあります。
ただし、そのまま現在のPoCに組み込むと、検証条件や終了日が変わります。
当初の目的に必要な変更なのか、本導入後や次の検証で扱う内容なのかを分けて相談します。
追加する場合は、評価項目、必要工数、期限、判断への影響を更新します。
終了直前まで課題を伏せると、顧客が対応を検討する時間を取れません。
途中で見つかった制約や、用意したデータでは確認できない項目を共有します。
途中経過は最終結果と混同しないよう、現時点の確認範囲であると明示します。
営業担当者は、技術担当者の結果を都合よく言い換えず、顧客の判断にどう影響するかを一緒に整理します。
必要なデータが揃わず評価できなかった場合、それは性能が低いという結果とは異なります。
一方で、評価できなかった項目を成功扱いにすることもできません。
未評価の理由と、評価を行うために必要な条件を記録します。
追加で確認する価値があるかは、その項目が導入判断にどれだけ重要かを基に判断しましょう。
終了報告は、検証結果を並べるだけでなく、顧客が次の判断に進むための資料として作ります。ここでは、成功した画面だけを並べない報告の考え方と、報告書に含める項目を紹介します。
報告書では、最初に合意した目的と対象範囲を示し、評価項目ごとに結果を整理します。
成功、不成功、未評価を分け、判断の根拠となる条件を残します。
よい結果だけでなく、制約や本導入前に解消すべき点を示すことが、顧客の検討を支えます。
この構成であれば、検証に参加していない責任者も、何が分かり、何が残っているかを追いやすくなります。
営業資料として見栄えを整える前に、合意した条件との対応が抜けていないかを確認しましょう。
PoCの終了後は、本導入するかしないかの二択ではなく、複数の選択肢から次の判断を選びます。ここでは、予定した範囲での本導入、対象を限定した導入、論点を絞った追加検証、保留または見送りの四つについて、それぞれ確認することを解説します。
必要な条件を満たし、運用体制と費用の確認も進められる場合は、具体的な導入計画へ移ります。
対象人数、開始に必要な準備、顧客と提供側の役割を整理します。
PoCで営業や技術担当が代行した作業についても、本導入では誰が担うかを確認します。
一部の業務では有効でも、すべてに広げるには課題がある場合、部署や用途を限定する選択肢があります。
限定した範囲で顧客の目的が達成できるか、残る業務との併用が可能かを確認します。
全社展開を約束したような説明をせず、今回導入する範囲と将来の検討を分けましょう。
追加検証が必要なら、導入判断を止めている項目を明確にします。
同じ条件で同じ作業を繰り返すだけでは、結論が変わらない可能性があります。
新しいデータ、異なる運用条件、必要な担当者の評価など、何を変えて確認するかを決めます。
追加分にも終了日と判断条件を設定します。
必須条件を満たせない、運用を担えない、現時点の優先順位が低い場合は、保留や見送りを選びます。
検証で導入しない理由が明らかになったことも、判断に必要な成果です。
保留の場合は、予算方針や運用体制など、何が変われば再開するかを記録します。
見送る場合も、確認済みの結果を残し、同じ条件の検証を繰り返さないようにします。
PoC後に本導入の検討が止まったときは、止まっている論点を顧客と一緒に整理することが大切です。ここでは、検証結果、運用、判断の進め方の三つについて、営業が確認するときの質問例を紹介します。
今回の結果のうち、導入判断に十分な項目と、追加確認が必要な項目を教えていただけますか。
当初の確認条件から、変更が必要になった点はありますか。
本導入した場合、日常の確認や例外対応はどの部署が担当する想定でしょうか。
現在の体制で難しい作業があれば、具体的に確認させてください。
次に結果を確認する場と、その際に必要な資料を教えていただけますか。
追加の検証が必要な場合、何を確認できれば判断に進めるでしょうか。
これらの質問は、顧客を急かして結論を迫るためではなく、止まっている論点を整理するために使います。
担当者が答えられない項目は、社内で確認するための形に整えましょう。
開始日と終了日だけでなく、当初の目的、判断条件、延長理由、終了後の状態を記録します。
PoCから本導入への割合を確認する場合は、開始時期や終了時期をそろえた案件群で、観察期間を定めます。
今月の本導入件数を今月のPoC開始件数で割るだけでは、違う案件群が混ざる可能性があります。
また、検討中、限定導入、見送りを区別し、未決着を自動的に失敗として扱わないようにします。
延長が多い場合は、技術的な課題なのか、開始前の目的が曖昧だったのか、判断会議が決まっていなかったのかを振り返ります。
件数を増やすだけでなく、導入判断に必要な情報を揃えられたかを確認することが重要です。
PoCから本導入に進まないときは、検証の成否だけでなく、目的、評価条件、運用、費用、判断の経路を確認しましょう。
開始前に確認表を作り、検証中の変更を記録し、終了後の選択肢まで合意しておくことで、次に整理すべき論点が見えやすくなります。
営業活動全体で、課題や導入方針を話し合える責任者との接点が不足している場合は、決裁者マッチングを検討する方法もあります。
接点づくりに関心がある場合は、onlystoryのサービス案内を確認してみてください。
PoC自体の評価条件や導入後の体制は、顧客と提供側で具体的に整理する必要があります。
まずは現在進行中のPoCについて、終了日に誰が何を判断する予定かを確認することから始めましょう。
オンリーストーリー代表 平野からのメッセージ
