パートナーを巻き込むとは、仕事を振ることではない
ハイタッチCSMとして大型顧客を担当していると、社内だけでは完結しない提案が増えてきます。
既存環境の調査が必要になる。
データ移行や設定変更の見積もりが必要になる。
導入パートナーの知見が必要になる。
運用設計まで踏み込む必要がある。
自社だけでは、顧客に現実的な提案を出しきれない。
そういう場面で、CSMはパートナーを巻き込もうとします。
「現行環境を教えてください」
「工数を出してください」
「実装可否を確認してください」
「顧客向けに同席してください」
「提案資料を作ってください」
どれも必要な依頼です。
ただ、こうした依頼をしても、思うように進まないことがあります。返信が遅い。期待した粒度の回答が返ってこない。顧客向けのメッセージが揃わない。見積もりは出たが、提案としてつながらない。三者で会議をしても、結局それぞれが自分の担当範囲を話すだけで終わってしまう。
そのとき、つい「パートナーが動いてくれない」と感じてしまうことがあります。
でも、振り返ると原因は相手の動きの悪さだけではないことが多いです。
こちらが依頼しているのは作業であって、共同提案として成立する前提を設計できていない。
そこに問題があるのだと思います。
パートナーを巻き込むとは、自分の作業を外に投げることではありません。
顧客にとって現実的で一貫した提案を作るために、顧客の目的、提案主題、役割分担、責任分界点、双方の商業的メリット、顧客向けの共通メッセージを設計することです。
パートナーは情報提供者ではない
パートナーを巻き込むときに、無意識に相手を「情報提供者」として扱ってしまうことがあります。
現行環境を確認してほしい。
実装できるか見てほしい。
工数を出してほしい。
顧客の質問に答えてほしい。
もちろん、専門的な確認や見積もりはパートナーの重要な役割です。ただ、それだけを依頼していると、パートナーから見ると「なぜ自分たちが今この案件に入るのか」が見えづらくなります。
パートナーにも、動く理由が必要です。
顧客にとっての提案価値は何か。
自社にとっての関与意義は何か。
商業的なメリットはあるのか。
今回担うべき役割はどこまでか。
逆に、担わない範囲はどこか。
顧客に対して、共同で何を伝えるのか。
将来的な導入、運用、拡張の機会につながるのか。
ここが見えていない状態で「工数を出してください」と言っても、パートナーは動きにくい。
CSM側から見ると、顧客のために必要な依頼をしているつもりです。
しかし、パートナー側から見ると、自分たちの役割も、メリットも、提案上の位置づけも曖昧なまま、作業だけが降ってきているように見えることがあります。
共同提案にしたいのであれば、相手を単なる確認担当や見積もり担当として扱ってはいけない。
一緒に顧客価値を作る相手として、前提を揃える必要があります。
共同提案には、設計が必要である
パートナーに相談する前に、CSM側で整理しておくべきことがあります。
顧客が実現したいことは何か。
今回の提案の主題は何か。
顧客の現状課題は何か。
なぜ自社単独ではなく、パートナー連携が必要なのか。
自社が担う範囲はどこか。
パートナーに担ってほしい範囲はどこか。
パートナーにとっての商業的メリットは何か。
顧客に対して共同で何を提案するのか。
どの論点を誰が答えるのか。
どの論点を共同で整理するのか。
次回、顧客に何を判断してもらうのか。
これらが曖昧なままパートナーを呼ぶと、会議は単なる情報収集会になります。
「この環境はどうなっていますか」
「これはできますか」
「どれくらい工数がかかりますか」
「顧客にはどう説明しますか」
質問は進みます。
でも、提案は前に進みません。
なぜなら、顧客にとって何を実現するための共同提案なのかが定まっていないからです。
パートナーとの会議は、確認会ではなく設計会であるべきです。
顧客の目的を共有する。
現状Gapを整理する。
自社とパートナーの役割を分ける。
費用が発生するポイントを明確にする。
顧客に判断してもらう論点を決める。
双方にとっての次のメリットを確認する。
ここまでできて初めて、パートナーは「この案件で自分たちは何を担うのか」を理解できます。
巻き込みには順番がある
パートナーを巻き込むときに、いきなり顧客を含めた三者会議を設定したくなることがあります。
顧客も入れた方が話が早い。
その場で現行環境を確認できる。
パートナーから直接説明してもらえる。
自社が間に入らなくても済む。
たしかに、三者会議は有効です。
ただし、前提が揃っていない状態で三者会議をすると、かえって危険です。
自社は標準機能で進めたい。
パートナーは追加開発を前提に話している。
自社は小さくPoCから始めたい。
パートナーは全社展開前提で工数を見ている。
自社はライセンスや製品価値を見ている。
パートナーは実装費用だけを見ている。
こうしたズレが顧客の前で出ると、提案全体への信頼が下がります。
理想的な順番は、まず自社内で提案方針を揃えることです。
今回の提案目的は何か。
顧客に何を決めてもらうのか。
商業論点は何か。
パートナーに期待する役割は何か。
自社として譲れないメッセージは何か。
次に、パートナーと事前アライメントを行う。
顧客の目的、現行環境、実装論点、PoC範囲、導入ロードマップ、双方の役割分担をすり合わせる。
そのうえで、顧客を含む共同提案に進む。
社内アライン。
パートナーアライン。
顧客を含む共同提案。
この順番を飛ばすと、顧客の前で提案を作りながら話すことになります。
大型案件では、それでは危ない。
顧客の前に出る前に、少なくとも「何を共同で提案するのか」は揃えておく必要があります。
顧客から見て一枚岩に見えること
共同提案で大事なのは、顧客から見て一枚岩に見えることです。
これは、全員が同じことだけを話すという意味ではありません。
役割が違っていても、提案の方向性が揃っている状態です。
自社は製品仕様、標準機能、将来ロードマップ、ライセンス、設計レビューを担う。
パートナーは現行環境確認、データ整備、設定、実装、運用設計を担う。
顧客は業務方針、対象範囲、意思決定、データオーナーを決める。
この分担が明確であれば、顧客は提案の現実性を判断しやすくなります。
逆に、誰が何を担うのかが曖昧だと、顧客は不安になります。
この作業は誰がやるのか。
標準機能でできるのか、追加開発が必要なのか。
どこから費用が発生するのか。
どの範囲が今回の提案なのか。
どこから先は追加検討なのか。
問題が起きたとき、誰が責任を持つのか。
ここが曖昧な提案は、顧客から見ると進めづらい。
役割分担は、内部都合の整理ではありません。
顧客価値そのものです。
誰が何を担うのかが見えることで、顧客は「この提案は本当に進められそうか」を判断できます。
パートナーにも商業的メリットが必要
パートナー連携で忘れてはいけないのは、パートナーにも商業的メリットが必要だということです。
顧客のために協力してほしい。
自社の提案を支援してほしい。
今後のために一緒に動いてほしい。
そう思うのは自然です。
ただ、パートナーも事業会社です。
リソースには限りがあります。
動くからには、自社にとっての意味が必要です。
今回の案件に入ることで、導入支援につながるのか。
運用支援につながるのか。
追加開発やデータ整備の機会があるのか。
顧客との関係強化につながるのか。
将来的な横展開の可能性があるのか。
ここを設計せずに、「顧客のためなのでお願いします」だけでは続きません。
もちろん、顧客価値が最優先です。
ただし、共同提案を継続可能にするには、自社、パートナー、顧客の三者にとって意味がある形にする必要があります。
パートナーを巻き込むとは、相手に無理をお願いすることではありません。
顧客価値を中心に置きながら、双方の商業的メリットも成立する提案構造を作ることです。
CSMは、社内外のリソースが動ける状態を作る
CSMは、すべてを自分でやる人ではありません。
特にエンタープライズSaaSや業務系SaaSでは、CSM一人で顧客の課題を解ききることはできません。
Sales、製品担当、コンサルタント、サポート、導入パートナー、SIパートナー。
多くの関係者と連携しながら、顧客の意思決定を前に進める必要があります。
そのときにCSMが持つべきものは、顧客文脈です。
顧客は何を実現したいのか。
なぜ今そのテーマなのか。
現状どこで詰まっているのか。
誰が意思決定に関わるのか。
どのタイミングで判断が必要なのか。
顧客側の体制やリソースにはどんな制約があるのか。
この文脈をもとに、関係者ごとに動ける情報へ翻訳する。
Salesには、Commercial Contextを渡す。
製品担当には、確認すべき仕様論点を渡す。
パートナーには、現行環境・実装・運用設計の論点を渡す。
顧客には、判断材料と次のアクションを渡す。
これが、ハイタッチCSMの価値だと思います。
CSMは、顧客と社内の間にいるだけではありません。
顧客と社内外のリソースをつなぎ、全員が同じ方向に動ける状態を作る役割です。
最後に
パートナーを巻き込むとは、自分の作業を外に投げることではありません。
顧客にとって現実的で一貫した提案を作るために、顧客の目的、提案主題、役割分担、責任分界点、双方の商業的メリット、共通メッセージを設計することです。
パートナーは、情報提供者ではありません。
実装担当でも、工数見積担当でも、都合よく呼ぶ外部リソースでもありません。
顧客価値を一緒に作る相手です。
だからこそ、CSMは「何をお願いするか」だけでなく、「なぜ一緒に提案するのか」「誰が何を担うのか」「顧客に何を判断してもらうのか」まで設計する必要があります。
社内アライン。
パートナーアライン。
顧客を含む共同提案。
この順番を丁寧に踏むことで、共同提案は単なる作業分担ではなく、顧客の意思決定を前に進めるものになります。
CSMは、自分で全部を抱え込む人ではありません。
顧客文脈を軸に、社内外のリソースが動ける状態を作る人です。
パートナーを巻き込む力とは、お願いする力ではなく、共同で動ける状態を設計する力なのだと思います。
