本題は Salesforce ではなかった。Foodji の実際の販売方法に合わせてオペレーティングモデルを再構築することだった。
技術的なベンダーではなく、深さを必要とした Salesforce プロジェクト
Foodji は Checkpoint が入る前にすでに Salesforce の旅を始めていました。前のパートナーは、プロジェクトが必要とする深さ、詳細、顧客ジャーニーの理解を提供できていませんでした。それが本当の問題でした — プラットフォームではなく。
Foodji のセールスモーションは、標準的な SaaS パイプラインよりも複雑です。同社は職場向けのフードソリューションを物理ユニット、ロケーションの複雑さ、運用の引き継ぎ、サブスクリプションの動態、更新、顧客ジャーニーにまたがる複数のステークホルダーと共に販売しています。
- 職場ロケーションに展開される物理ユニット — クリーンなソフトウェアのみの案件ではない
- 各サイトに独自の文脈とタイミングを持つマルチロケーション・アカウント
- セールス、デプロイメント、アカウント管理間の運用の引き継ぎ
- 初回販売の上に重なるサブスクリプションと更新の動態
- 案件ごとに異なる意思決定基準を持つ複数のステークホルダー
浅い Salesforce 導入はレコードを取得できます。Foodji がどう販売、クオリファイ、デプロイ、管理、拡大するかを正確に反映することはできません。Foodji は、入って顧客ジャーニーを適切に理解し、戦略とプロジェクトマネジメントの観点から導入を完全に管理する人を必要としていました。
技術的なクリーンアップではなく、オペレーティングモデルの問題として扱う
Checkpoint は、まずプロジェクトを Foodji の実際の顧客ジャーニーを中心に再アンカリングすることで、導入のオーナーシップを引き受けました。Pipedrive から Salesforce への移行は、より広範な運用層の再設計の一部となりました — 移行は目的そのものではなく、リセットの瞬間でした。
Discovery
顧客ジャーニーを運用面で詳細に再構築: リードがどう入ってくるか、アカウントとロケーションがどう関係するか、デプロイメントがタイムラインのどこに位置するか、更新と拡張がどう展開するか。既存の導入アプローチが Foodji の実際の販売方法をサポートするには浅すぎた箇所を特定。
Design
リード、アカウント、案件、ロケーション、Foodji ユニット、更新が Salesforce でどう表現されるべきかを明確化。セールスプロセス、システムアーキテクチャ、レポーティングロジックを整列させ、プラットフォームが商業モーションを支援するようにし — 戦うのではなく。クオリフィケーション、案件構造、更新/拡張モデルを指定。
Build
Pipedrive から Salesforce への移行を、リフト・アンド・シフトではなくリセットポイントとして実行。セールスプロセス、顧客ライフサイクル、オブジェクトモデル、運用の引き継ぎについて、より明確なビューを持って Salesforce へ移行。Foodji が Revenue 機能を実際に運用できる — 単に記録するだけでなく — システムを構築。
Launch
前のエンゲージメントには欠けていた構造とアカウンタビリティで導入のワークストリームを管理。再設計されたオブジェクトモデルにレポーティングを整列させ、ダッシュボードが Foodji の実際のクオリファイ、デプロイ、更新の方法を反映するようにし — 古い Pipedrive の形を新しいツールに押し込んだものではなく。
Optimize
Thorsten Schaar が VP Sales として参画したとき、関係は進化しました。Checkpoint はフラクショナル RevOps パートナーおよびシニアスパーリング機能として残りました — Foodji が社内のケイパビリティを欠いていたからではなく、Noah がすでにシステム、導入の歴史、すべての Salesforce 判断の背後にある商業的ロジックを理解していたから。
完成した実装ではなく、運用基盤
Foodji は完了した Salesforce ロールアウト以上のものを得ました。同社はより強力な Revenue オペレーティング基盤、システムの背後にある顧客ジャーニーを理解するパートナー、そして Thorsten がセールス組織を前進させるにつれて継続的なアドバイザリへのアクセスを得ました。
- 実際のビジネスモデルを反映する Salesforce — リード、アカウント、案件、ロケーション、ユニット、更新のロジックが、Foodji がどう販売、デプロイ、拡大するかを映し出す
- Pipedrive から Salesforce への移行をコピーではなくリセットとして — Salesforce への移行は、古い前提を保存するためではなく、セールスプロセスと運用の引き継ぎを明確化するために使われた
- プロジェクトマネジメントのオーナーシップとアカウンタビリティ — 前のエンゲージメントになかった、構造化され、ペース付けされ、責任を伴う導入ワークストリーム
- 新 VP Sales のためのシステムレベルの継続性 — Thorsten は、なぜ判断がなされたか、システムがどう進化できるかをすでに理解している人との関係を引き継いだ — ブラックボックスの導入ではなく
- シニア RevOps スパーリングパートナー — プロセス判断のための音響板、セールス Ops の優先順位への挑戦機能、毎回再オンボーディングを必要とせず重要な RevOps トピックを前進させられる信頼できる外部オペレーター
- 実行を超える持続的価値 — 元のプロジェクトは導入リカバリだったが、持続的価値はシステム履歴、RevOps の判断、商業的文脈を組み合わせた信頼できる運用パートナーシップだった
Checkpoint は、技術的な Salesforce パートナー以上のものが必要だったときに入ってきました。顧客ジャーニーを詳細に理解し、戦略的プロジェクトマネジメントの観点から導入のオーナーシップを引き受け、Foodji の実際の販売方法に合わせて Salesforce を機能させる支援ができる人が必要でした。
私が参画した後、Noah は信頼できるスパーリングパートナーになりました。これまでの経緯、システム、商業的な文脈を理解していたので、判断を問い直したいときや、重要な RevOps のテーマを前進させたいときには彼に頼ることができました。
VP Sales · Foodji
リカバリし、再構築し、改善し続けられる RevOps パートナーが必要ですか？
難航している実装は、ロールアウトを完了するだけでなくオペレーティングモデルをリセットする瞬間です。あなたのチームにとってそれがどう見えるかをお話ししましょう。
相談する