Présentation
Rattle est le pont bidirectionnel Salesforce-Slack qui permet aux commerciaux de mettre à jour Salesforce depuis Slack via des formulaires interactifs natifs — et qui permet aux RevOps de construire des workflows pilotés depuis Slack sur des événements Salesforce sans écrire d’Apex. Les commerciaux arrêtent de basculer vers Salesforce ; les RevOps arrêtent de courir après les commerciaux pour les mises à jour. Utilisé par les équipes GTM dont la friction de mise à jour CRM est le goulot d’étranglement de la qualité des données.
Pourquoi il figure dans les stacks RevOps
- La friction de mise à jour CRM, traitée à la source. Les commerciaux ne mettent pas à jour Salesforce parce que Salesforce, c’est de la friction. Rattle permet à la mise à jour de se faire dans Slack, là où le commercial vit déjà.
- Workflow sans code. Les RevOps construisent visuellement des workflows Salesforce déclenchés depuis Slack ; remplace le cycle « ticket à l’admin ».
- Alertes deals en temps réel. Nouvelle opportunité, changement d’étape, deal perdu — poussées dans le bon canal Slack avec des boutons d’action. Le commercial met à jour directement dans le canal.
Réalité tarifaire
Rattle est sur devis ; pas de tarification publique. Les déploiements mid-market (100 à 500 commerciaux utilisateurs Salesforce-Slack) atterrissent entre 25 K$ et 80 K$ par an. Les déploiements entreprise entre 80 K$ et 250 K$+. La tarification évolue selon le nombre d’utilisateurs et le nombre d’automatisations.
Pour qui
- Équipes GTM SaaS B2B de 50 à 500 commerciaux où la qualité des données Salesforce est le problème chronique.
- Organisations Slack-first (Microsoft Teams fonctionne mais Slack est le meilleur fit).
- Équipes RevOps qui veulent l’automatisation des process sans s’engager dans des effectifs admin / développeur Salesforce.
Face aux alternatives
- vs intégration native Salesforce-Slack (depuis l’acquisition de Slack). La native est gratuite, basique, et s’améliore avec le temps. Choisissez la native si le budget est serré et que le cas d’usage se limite à des notifications simples. Choisissez Rattle pour des workflows actionnables (mises à jour, approbations) que la native ne gère pas.
- vs Troops (racheté par Salesforce, sunset). Concurrent historique direct ; majoritairement migré vers Rattle ou vers le natif Salesforce-Slack.
- vs Salesforce Flow + Apex. Flow + Apex peut faire l’essentiel de ce que fait Rattle — au prix de temps admin/développeur. Choisissez le build sur mesure si vous avez la bande passante ; choisissez Rattle sinon.
- vs statu quo (les commerciaux mettent à jour Salesforce quand ils y pensent). Le défaut, et la source d’inexactitude des forecasts.
Points de vigilance
- Risque d’explosion de workflows. Des workflows faciles à construire se multiplient ; l’équipe se retrouve avec des centaines de workflows pilotés depuis Slack que personne ne possède. Garde-fou : désigner un owner Rattle ; audit trimestriel des workflows actifs avec suppression de ceux qui sont obsolètes.
- Le coût par siège grimpe sur de gros effectifs. Garde-fou : à 500+ commerciaux, évaluer si tous les commerciaux ont besoin de Rattle ou seulement les AE / SDR.
- Risque de bruit dans les canaux Slack. Les notifications Rattle peuvent submerger les canaux. Garde-fou : router vers des DM par commercial ou des canaux par équipe ; résister à l’envie de créer un canal-déversoir unique.
- Complexité des permissions Salesforce. Les workflows Rattle s’exécutent sous les permissions de l’utilisateur ; les interactions de permissions surprenantes apparaissent comme des échecs silencieux de workflow. Garde-fou : tester les workflows sous le profil de chaque commercial ; ne pas supposer que les workflows testés par un admin fonctionnent pour des profils sales-user.