B2B SaaS パイロットを実施し、終了時に明確な判断を下すには

買い手の疑問に答えられる場合にだけパイロットを選ぶ

この製品が自社の業務に合うか判断するために、何を確認する必要がありますか、と尋ねます。たとえば、2 人の顧客担当者が、創業者による修正なしで必要な情報をそろえた顧客引き継ぎを作れるか、なら検証できます。単にプラットフォームを見てみたいという要望なら、まず評価範囲を話し合います。

パイロットは双方の仕事を増やします。デモで疑問が解消し、買い手が購入できる状態なら、追加評価は判断を遅らせるだけかもしれません。予算がない、あるいはデータ利用の条件が未承認という問題は、製品へのアクセスだけでは解決しません。

顧客探索やベータテストとの目的の違いを明確にする

パイロット、トライアル、概念実証という言葉の使い方は会社によって異なります。名称に頼らず、実施する作業を一緒に定義しましょう。このガイドのパイロットは、利用可能な製品を買い手の業務で評価し、購入判断で締めくくります。技術的な概念実証は、特定の連携や技術要件が実現できるか、という狭い範囲でも構いません。

デザインパートナーとの関係は、まだ学習と開発が必要な製品を形にするためのものです。ベータテストは初期の利用を観察し、問題を見つけるためのものです。どちらも商用のパイロットにつながり得ますが、意見、出席、熱意は購入を証明しません。それぞれの関係の目的と、期待する協力を明示します。

製品が誰のためのものかをまだ検討しているなら、末尾のデザインパートナーや顧客探索のガイドから始めてください。この計画は、見込みのある買い手がいて、現在の製品で既に試せる業務がある段階を対象にしています。

期間を数え始める前に開始条件を合意する

• 業務を一つに絞る：タスク、実行する人、対象外の作業を記します。全社ですべての機能を一度に評価しないようにします。
• 利用者と買い手を確認する：誰が試し、有用性を評価し、購入を承認するかを特定します。一人が複数の役割を担う場合も、推測せず確認します。
• 使える入力を用意する：実際の試行に必要な作業サンプル、アクセス権、許可を確認します。前提条件の未充足は、製品の失敗とは別に記録します。
• 比較基準を記録する：同種の作業を現在どう行っているか、時間、ミス、支援を含めて記録します。比較前に測定方法を決めます。
• 双方の対応余力を確認する：設定の担当者、提供できる支援量、対象外の個別開発を合意します。
• 日程を決める：通常業務の中で必要な観察ができるよう、開始日、中間確認日、判断日を設定します。14 日、30 日、90 日という一律の要件はありません。

ブリーフをコピーし、買い手と一緒に記入する

空欄の項目を自分の文書にコピーしてください。記入例には、架空の顧客引き継ぎ製品 HandoffKit と架空の代理店 Northstar Studio を使っています。例の組織、日付、数値、結果はすべて方法を示すために作ったもので、Soloop の顧客事例や推奨基準ではありません。

このブリーフは実施計画です。商取引やデータの取り扱いに関する条件は、適切な合意文書に別途記載してください。この表は契約書のひな型ではありません。小さい画面では、表を横にスクロールすると全列を読めます。

有料にするかと、支払いが何を示すかを決める

必要な作業と買い手の手順に応じて条件を選びます。大きな設定作業や専任の支援が必要なら、着手前に商業条件を話し合います。双方が時間を確保でき、学習の費用を負担できるなら、範囲を絞った無料評価が妥当な場合もあります。どちらの形でも、曖昧な問いや評価者の不在は解決しません。

含まれる作業、買い手の協力、終了後の扱い、その後の購入をどう検討するかを書きます。後の購入代金から試行料金を差し引くなら、それも明示します。他社のガイドにある大企業向け料金や期間を、自分の製品に適した条件としてそのまま採用しないでください。

試行料金、その後のサブスクリプション判断、継続利用は別々に記録します。評価への支払いが示すのはその取引であり、更新、定着、他社でも支援なしに使えることではありません。同様に、社内の推進者が続けたいと言っても、予算承認済みとは限りません。

創業者の支援も含め、実際の試行を記録する

実際の試行ごとに 1 行記録します。タスク ID、日付、開始条件、完了の証拠、実作業時間、中断、支援の内容を残します。待ち時間と実作業時間は分けてください。確認した証拠を特定し、見積もりや記憶は本人の報告として区別します。

架空のパイロットでは、5 件とも必要情報を含む引き継ぎが受け手に届きます。ただし 1 件は、創業者がエクスポートを手動で修正して初めて成功しました。この短時間だが支援付きの試行を平均に含めると、製品が支援に依存していることを隠してしまいます。

合意した基準に照らして結果を読む

架空の全 5 件では、利用者の平均時間は 23.2 分です。（22 + 12 + 30 + 24 + 28）/ 5 で計算できます。24 分の目標以下に見えますが、目標は明確に独力で完了した作業を対象としていました。その平均は（22 + 30 + 24 + 28）/ 4 = 26 分なので、時間の基準は未達です。

独力での平均は、架空の比較基準 30 分より 4 分短く、このサンプルでは有用な観察です。ただし、選ばれた少数の作業であること、タスクの違い、試行中の学習があるため、この差を因果効果の推定値や他の顧客への約束として扱えません。

購入判断、限定した追加検証、または終了で締めくくる

最終会議では、感想を話す前に証拠を示します。評価者に記録が実体験を表しているか確認し、次に買い手へ、今どの判断ができるか尋ねます。製品の適合性と購入準備の状態は異なることがあるため、両方を見える状態にします。

架空のケースでは、創業者は重複入力をなくし、比較できる引き継ぎを再度試すことを提案します。まだ提案にすぎません。買い手は追加作業にも支出にも同意していないため、正確な結果は、初回評価は終了、時間基準は未達、追加評価と購入は未決定、となります。双方が明示的に変更しない限り、合意した初回アクセス期間を終了します。

• 買い手が提示された範囲と条件を選んだら、購入の手続きに進みます。実際の次の行動と担当を記録し、支払いは確認後にだけ完了と記します。
• 追加検証は、重要な未解決の問いがあり、双方が変更内容と新しい終了日に合意した場合に行います。予算がないだけで、無期限の無料支援を続ける理由にはなりません。
• 業務との相性が悪い、前提条件を満たせない、支援負担が提供可能な範囲を超える、または買い手が断った場合は終了します。学びは記録しますが、成約顧客とは呼ばないでください。

未解決の調査課題を一つ Soloop に持ち込む

自分でブリーフと評価表を使い、その後、公開情報で答えられる問いを特定します。たとえば、この種の代理店は顧客引き継ぎにどの代替手段を使い、どのような設定が必要か、という問いです。調査は範囲や追加質問の検討に役立ちますが、その顧客自身の業務は顧客に示してもらう必要があります。

コピー用ブリーフ：私の製品は［URL またはデモ］で、［役割と業務］を対象にしています。見込み顧客は［特定のタスク］を評価する必要があります。［公開情報の URL または範囲］を使って［一つの問い］を調べてください。関連する代替手段を比較し、出典リンクと確認日を添え、企業の主張、観察、不明点を分けてください。最後に、試行に合意する前に買い手へ確認すべき質問を挙げてください。

Soloop のマニュアルでは、市場・競合調査のレポートと、実際に収集された出典リンクが Tasks に保存されると説明しています。結果を開き、重要な判断に使う出典を確認してください。共有してよい資料だけを持ち込みます。パイロットの運営、利用証拠の収集、商業判断はあなたと買い手の仕事です。このガイドは、自動パイロット管理サービスの存在を示すものではありません。

下の Soloop へのリンクは公開の入口を開くだけで、このブリーフや顧客メモを転送しません。Soloop のワークスペースを開かなくても、記入済みの文書はそれ自体で有用です。

出典と限界

出典の確認日は 2026 年 10 月 7 日です。ブリーフ、試行記録、しきい値、計算、架空の評価結果は Soloop が独自に作成した編集上の例で、顧客調査で検証されたものではありません。タスクを選ぶ際は製品マニュアルを再確認し、例の日付や目標をそのまま採用せず、買い手の実際の業務に合わせてください。