BtoBサービスの導入期間を、契約からの一律日数で示さない方法

BtoBサービスの案内に「契約から一律○日で導入」と書きたくても、顧客によって利用者の準備や既存データの整理にかかる時間は違います。設定が終わった日と、現場が使い始める日も同じとは限りません。期間の数字を先に決めるより、どの状態を「導入」と呼び、誰のどの準備が次の工程に必要かを示す方が、検討者は自社の日程を考えやすくなります。

契約日と利用開始日の間にある工程を確かめる

まず導入担当へ、実際の案件で何を確認してから着手するかを聞きます。たとえば利用範囲の決定、顧客側の管理者と利用者の指定、既存データの整理、設定、試験、利用者への案内、利用開始です。すべてのサービスに同じ工程があるわけではありません。設定だけで始められるサービスと、データ移行や他システムとの接続を伴うサービスを分けて確認します。

Atlassianのクラウド移行案内では、評価、計画、準備、テスト、移行、ローンチを分け、試験でデータの整合性や利用者のアクセスを確認します。これは同社製品の移行例です。自社のホームページへ工程名をそのまま写すのではなく、提供しているサービスで必要な確認と順番を実績に照らして決めます。

期間を変える前提を、作業に結び付けて示す

「案件によって異なります」だけでは、何を伝えれば目安が出るか分かりません。利用する部署・人数、移すデータの種類と量、既存システムとの接続、承認・試験に参加する人を確認し、どの条件がどの工程に影響するかを説明します。Google Workspace Migrateの計画資料でも、移行の段階はデータの規模や複雑さ、利用者数、データの種類で変わるとしています。特定製品の例を、すべてのBtoBサービスの所要日数に置き換えないようにします。

データ移行が必要なら、「データをいただいてから設定」の一文で済ませず、何を準備し、何を照合するかを示します。同製品のデータ対応付けの説明には、移行する内容と移行元・移行先のIDを対応させる作業があります。自社サービスでもデータの形式や対応付けが必要なら、顧客が用意する資料と提供側が確認する内容を分けて書きます。移行が不要なサービスへこの工程を足す必要はありません。

サイトでは「何の期間か」を数字の隣に置く

導入実績から目安の期間を示せる場合は、起点と終点、含む作業、前提条件を数字の近くに書きます。「必要な情報の確認後、標準設定まで」「試験と承認を経て利用開始まで」では意味が違います。最短期間を載せるなら、その条件を満たした実例があり、例外や追加作業をどこで説明するかも確かめます。数字がまだ確認できないなら、工程と相談時に聞く条件を先に示し、架空の所要日数を埋めません。

案内は、サービスページに導入の大まかな流れを、詳しいページには顧客側と提供側の役割、データや接続の条件、試験と利用開始の確認方法を置くと読みやすくなります。相談フォームには「利用予定の部署」「移行したいデータの有無」のような、見積もりに本当に必要な情報だけを選びます。まだ決まっていない項目は「未定」と伝えられるようにし、問い合わせ前に仕様書を完成させる負担を求めません。

BämのIT・法人向けサービスのホームページ制作では、営業で説明している利用場面や導入の判断材料を、原稿と図に整理します。導入担当が確認した工程、顧客へ依頼する準備、実際に使い始めた時点の記録を見比べれば、期間の表現と相談の入口を現実の提供方法へ合わせられます。個別案件の導入日や成果は、ホームページだけで確約しません。