概要
Rattleは、Salesforce-Slack間の双方向ブリッジです。担当者はSlackからネイティブのインタラクティブフォームでSalesforceを更新でき、RevOpsはApexを書かずにSalesforceイベントを起点としたSlack駆動のワークフローを構築できます。担当者はSalesforceへのコンテキストスイッチをやめ、RevOpsは担当者への更新催促をやめられます。CRM更新時の摩擦がデータ品質のボトルネックになっているGTMチームで採用されています。
RevOpsスタックで採用される理由
- CRM更新の摩擦を発生源で解消。 担当者がSalesforceを更新しないのは、Salesforceが摩擦そのものだからです。Rattleは担当者がすでに常駐しているSlack上で更新を完結させます。
- ノーコードのワークフロー。 RevOpsがSlackトリガーのSalesforceワークフローをビジュアルに構築でき、「管理者にチケットを切る」サイクルを置き換えます。
- リアルタイムの案件アラート。 新規商談、ステージ変更、失注などを、適切なSlackチャネルにアクションボタン付きでプッシュ。担当者はチャネル内で直接更新します。
価格の実態
Rattleはカスタム見積もりで、公開価格はありません。ミッドマーケット導入(Salesforce-Slackを使う担当者100〜500名)では年間25,000〜80,000ドル。エンタープライズ導入では80,000〜250,000ドル超。ユーザー数とオートメーション数に応じて価格がスケールします。
最適なケース
- 担当者50〜500名規模のB2B SaaSのGTMチームで、Salesforceデータ品質が慢性的な課題となっているケース。
- Slackファーストの組織(Microsoft Teamsでも動作しますが、Slackの方が相性は良い)。
- Salesforce管理者・開発者の人員を抱え込まずに、プロセス自動化を進めたいRevOpsチーム。
代替案との比較
- vs Salesforceの公式Slack統合(Slack買収後のネイティブ機能)。 ネイティブは無料・基本機能のみで、徐々に改善されています。予算が厳しく、ユースケースが単純な通知のみであればネイティブを。ネイティブが扱えない実行可能なワークフロー(更新、承認)が必要ならRattleを選びます。
- vs Troops(Salesforceに買収後、提供終了)。 直接の歴史的競合。ほぼRattleかSalesforceネイティブ統合へ移行済みです。
- vs Salesforce Flow + Apex。 FlowとApexで、Rattleがやることのほとんどは実現可能です。ただし管理者・開発者の工数というコストがかかります。リソースがあるなら自社構築、なければRattleを選びます。
- vs 現状(担当者が思い出したときにSalesforceを更新)。 これがデフォルトであり、予測精度の不正確さの源です。
注意点
- ワークフロー氾濫のリスク。 簡単に作れるワークフローは増殖し、誰も所有していないSlack駆動ワークフローが数百件積み上がるという結末を迎えます。対策: Rattleのオーナーを指定し、四半期ごとにアクティブなワークフローを監査して陳腐化したものを削除する。
- 大規模では1席あたりのコストが膨らむ。 対策: 担当者500名超の規模では、全員にRattleが必要か、それともAE / SDRに限定すべきかを評価する。
- Slackチャネルのノイズリスク。 Rattleの通知はチャネルを埋め尽くし得ます。対策: 担当者ごとのDMやチームごとのチャネルにルーティングする。1つの「ファイアホース」チャネルを作る誘惑には抵抗する。
- Salesforceの権限の複雑さ。 Rattleのワークフローはユーザー権限で実行されるため、想定外の権限の相互作用がサイレントなワークフロー失敗として表面化します。対策: 各担当者のプロファイルでワークフローをテストする。管理者でテスト済みのワークフローが営業ユーザーのプロファイルで動くと決め込まない。