Ne construisez pas, intégrez - Un guide d'intégration CRM

Disons que vous travaillez pour une startup qui vend des robots dans tous les secteurs. Vous recevez les commandes de divers clients, et une équipe d'exploitation évalue les commandes et travaille avec des fournisseurs tiers pour offrir à vos clients le bon robot.

Construire le MVP était stressant mais aussi très amusant. Vos investisseurs sont excités et vous inondent d'argent. La phase suivante commence. Vous avez besoin de plus de visibilité sur la rentabilité et vous souhaitez acquérir des clients plus importants qui ont besoin d'une facturation plus sophistiquée. Dans le même temps, vous disposez d'une feuille de route de produits assez sophistiquée pour permettre la vente de robots à marge plus élevée. Les ressources sont rares, mais vous devez toujours vous assurer que l'entreprise continue de fonctionner.

Comme souvent prêché pour les petites entreprises, se concentrer sur les choses dans lesquelles vous êtes doué est une excellente règle de base. Mais qu'en est-il de tous les domaines qui assurent le fonctionnement quotidien de votre entreprise ? Vous ne souhaitez certainement pas créer un système de gestion de la relation client (CRM) ou un système comptable. Après tout, il existe de nombreux produits qui résolvent tous les problèmes. Mais comment ces systèmes fonctionneront-ils avec votre système de commande existant ?

C'est là que l'intégration tierce est utile. Alors, plongeons-nous et voyons si nous pouvons éviter certains pièges courants.

Intégration CRM

Que vous fassiez des ventes à faible contact (marketing de contenu, publicités sur les réseaux sociaux ou newsletters) ou des ventes à fort contact (appels à froid, participation à des conférences ou suivi de clients existants par téléphone), un système CRM peut vous donner beaucoup de visibilité sur la façon dont vous vous débrouillez avec les clients existants et sur votre capacité à convaincre de nouveaux clients.

Souvent, la sélection d'un système CRM est principalement laissée au service des ventes et du marketing. En général, il n'y a rien de mal à cela. Après tout, ces personnes savent le mieux comment augmenter leurs revenus et ont besoin du meilleur support disponible. Mais même le meilleur logiciel ne vaut rien s'il ne fonctionne pas correctement avec votre système de commande de robots.

Incluez votre département technique dans la décision

Qu'il s'agisse du CTO ou d'un ingénieur dédié, tenez-les au courant dès le début. Ils sont très susceptibles de vous donner plus d'informations sur la manière dont les deux systèmes fonctionneront ensemble à l'avenir.

Et un mot pour les ingénieurs : gardez l'esprit ouvert aux solutions tierces. Il est facile de les rejeter parce que leur API n'est pas la meilleure ou que leur interface utilisateur est laide. Cependant, il peut être très gratifiant de trouver des solutions élégantes autour des systèmes existants.

Néanmoins, il peut être utile de parler de quelques sujets avant de prendre une décision. Des sujets généraux tels que « Avons-nous besoin de cela ? » doit être adressé. Mais c'est aussi une bonne idée d'avoir déjà une idée de ce qu'est la portée. Une synchronisation bidirectionnelle est-elle nécessaire, ou le système tiers suivra-t-il simplement le système de commande ? Une fois que la portée est à l'écart, il doit également y avoir une discussion technique sur les détails de mise en œuvre tels que les webhooks ou l'évaluation des limites de l'API.

Avez-vous besoin d'une intégration personnalisée ?

En ce qui concerne l'intégration, il n'est pas surprenant qu'il existe déjà des plates-formes qui promettent de résoudre certains des problèmes que vous êtes susceptibles de rencontrer. Actuellement, Zapier et IFTTT sont les plus prometteurs.

Selon le problème que vous essayez de résoudre, votre système de commande de robots peut même ne pas être impliqué dans l'intégration. Supposons que vous gérez les abonnés de votre newsletter avec un système CRM tel que Salesforce ou HubSpot et que vous souhaitiez simplement un moyen plus pratique de les contacter via un fournisseur de services de messagerie tel que Mailchimp, Zapier propose des tonnes d'intégrations existantes pour vous aider. À partir de ce moment, choisir un fournisseur disposant d'un connecteur Zapier est une bonne voie à suivre.

Et même s'il s'agit d'intégrer des données personnalisées (les robots commandés et leur prix), Zapier Webhooks peut servir d'intermédiaire pour votre intégration.

En revanche, si vous envoyez déjà des données à un tiers, pourquoi ne pas les envoyer directement au système CRM ? Plus vous souhaitez synchroniser de données, plus une intégration directe sera utile.

Ce qui m'amène à mon prochain point.

Avez-vous besoin d'une synchronisation bidirectionnelle ?

Habituellement, une intégration commence par une exigence simple telle que Pouvons-nous intégrer tous nos clients dans notre système CRM ? , généralement associées aux valeurs des commandes de robots individuelles, ce qui facilite l'utilisation des outils de segmentation des clients.

Cependant, tôt ou tard, il se peut que les gens veuillent utiliser les outils de gestion des contacts qu'offre généralement une suite CRM. Celles-ci incluent des fonctionnalités telles que la déduplication, la modification des coordonnées avec les données des médias sociaux, la normalisation des adresses de livraison ou simplement la suppression d'anciens contacts.

La modification des contacts dans un système CRM signifiera très probablement que vous devrez modifier les coordonnées dans un autre système, c'est-à-dire que les modifications doivent aller dans les deux sens.

L'effort de mise en œuvre pour cela va bien au-delà d'une simple synchronisation unidirectionnelle, c'est donc un excellent point pour réfléchir à la façon dont vous souhaitez utiliser stratégiquement un nouveau système.

Comment serez-vous informé des modifications du CRM ?

Si vous décidez d'avoir une synchronisation bidirectionnelle, il y a une question de suivi : comment savez-vous que quelque chose a changé du côté du CRM ?

La plupart des fournisseurs de systèmes ont des outils pour cela, mais le meilleur pour les changements immédiats est les webhooks - essentiellement, un système de notification HTTP qui peut être configuré pour vous informer des changements pertinents (pour certains systèmes, même champ par champ) .

Si le système ne propose pas de webhooks, vérifiez au moins si vous pouvez obtenir une liste de toutes les entités qui ont été récemment mises à jour. De cette façon, vous n'avez pas à parcourir tous les contacts et offres uniquement pour mettre à jour vos propres données. Mais n'oubliez pas que vous devrez interroger le système à intervalles réguliers.

Dans ce cas, votre système de commande changerait encore et créerait des données via un appel API sur le système CRM. Mais toutes les modifications du système CRM seraient interrogées dans un intervalle défini.

Il convient de noter que les mises à jour seront limitées à cet intervalle et peuvent entraîner une incohérence temporaire des données. Par exemple, lorsque vous ne synchronisez qu'une fois par jour de votre système CRM à votre système de commande, les données que vous consultez dans votre système de commande peuvent dater de 24 heures.

Selon les fonctionnalités offertes par le système, la tâche d'intégration peut varier en complexité et en temps de mise en œuvre. Assurez-vous de vérifier ce que le système propose à l'avance et vérifiez le plan que vous avez l'intention d'acheter. Par exemple, certains systèmes CRM proposent des webhooks dans les niveaux les mieux rémunérés.

Un exemple ici est le CRM de HubSpot, qui propose des webhooks en général, mais la fonctionnalité de webhook n'est disponible que dans leur package Enterprise. Les outils de comptabilité Zoho Books proposeront cinq flux de travail automatisés (qui incluent des webhooks) dans leur niveau le plus bas.

Vos données sont-elles en bon état ?

Lorsqu'il s'agit de créer des ensembles de données dans un système externe, il est bon de savoir à quoi ressemblent les données dans votre propre système. Heureusement, il n'y a pas trop de façons différentes de présenter les contacts et les offres, mais un champ qui cause toujours des problèmes est le champ e-mail.

Différents systèmes ont des idées différentes sur ce qu'est une adresse e-mail valide, et voici une alerte spoiler : vos clients peuvent vous avoir fourni des adresses e-mail invalides de toutes sortes. De nombreux systèmes CRM rejetteront la création d'un contact avec une adresse e-mail invalide (et bien sûr, le fournisseur CRM définit ce qui est valide et ce qui ne l'est pas).

Conseil : Si possible, synchronisez uniquement les adresses e-mail confirmées avec votre CRM. Cela vous évitera beaucoup de douleur à long terme.

Limites de l'API

Enfin, les limitations de l'API doivent être traitées le plus tôt possible.

En supposant qu'il existe une API (qui est fondamentalement indispensable pour toute intégration), il est avantageux d'examiner les limites de l'API. La plupart des startups peuvent faire face aux limites de base de l'API de la plupart des systèmes CRM. À titre d'exemple, HubSpot propose 250 000 appels d'API par période de 24 heures, même dans leur niveau gratuit. D'autre part, il limite également les appels à 10 par seconde (100 si vous utilisez OAuth). Le leader du marché, Salesforce, n'en autorise que 100 000 toutes les 24 heures, mais propose d'en acheter plus.

La plupart du temps, vous tomberez facilement dans ces limites, mais il y a une chose à considérer : qu'en est-il de votre course initiale ? Au début, vous pousserez beaucoup de contacts et de transactions vers votre CRM (et peut-être plusieurs fois en cas de problème). Par conséquent, vous pourriez atteindre la limite quotidienne de l'API.

Pour atténuer cela, vous pouvez tester avec un petit ensemble de données et augmenter lentement le nombre tout au long de la mise en œuvre pour rester dans la limite de l'API. Pour la migration initiale, planifiez-la sur plusieurs jours ou sur un week-end. Sinon, contactez le fournisseur et faites-lui part de vos intentions. Lorsque vous êtes dans la phase d'évaluation (et que vous n'avez pas encore payé pour le système), ils pourraient être disposés à augmenter un peu votre allocation API.

Implémentation CRM

Disons que vous êtes tous d'accord. Vous avez choisi un excellent outil CRM, et les ingénieurs sont convaincus qu'il peut être intégré assez facilement. Vous avez décidé de l'étendre pour ne pousser que les données des clients et les commandes de robots acceptées. Par conséquent, la synchronisation bidirectionnelle n'est pas nécessaire et les changements d'adresse ne seront gérés que dans votre propre système de commande.

Il reste encore quelques bonnes pratiques à suivre pendant la phase de mise en œuvre.

Tout essayer dans un environnement de test

Dans la plupart des cas, le système CRM ne sera utilisé qu'une fois votre intégration terminée et prête à l'emploi. Pour ce cas d'utilisation, il peut sembler intéressant de n'utiliser que le système de production pendant le développement. Après tout, il n'y a aucune donnée de production que vous pourriez affecter. Une fois le développement terminé, vous supprimerez simplement toutes les données de test que vous avez créées, exécuterez une migration initiale et dirigerez votre système de commande vers cet environnement.

Il y a quelques problèmes avec cette approche :

1. Vous ne faites que donner un coup de pied dans la boîte. Même si votre mise en service se passe bien, tôt ou tard, il y aura une demande de fonctionnalité pour modifier une partie de votre intégration. Étant donné que la demande de fonctionnalité est suffisamment importante, vous aurez probablement besoin d'une autre phase de test. À ce stade, un système de test séparé est inévitable ; sinon, vous risquez de gâcher les données de production. Alors pourquoi attendre la configuration jusqu'à ce qu'on vous demande d'implémenter la première fonctionnalité ?

   

2. Vous vous retrouvez avec une configuration désordonnée. Il est très probable que votre système CRM ait besoin d'une sorte de configuration pour répondre aux besoins de votre système de commande. Les noms de statut peuvent devoir être ajustés, des champs personnalisés doivent généralement être créés, etc. Comme la plupart des développeurs devront s'habituer au système CRM, une configuration sera ajoutée qui n'est pas nécessaire à long terme. En réalité, cette configuration inutilisée n'est pas supprimée par la suite et peut même rester indéfiniment dans votre CRM. En forçant l'étape supplémentaire de répliquer la configuration du système de test vers la production, vous vous retrouverez très probablement avec une configuration plus mince sur votre système de production.
   
   Il convient de noter que cela peut également jouer en votre défaveur si vous oubliez de copier la configuration de votre test vers votre système de production, et vous vous retrouverez avec des erreurs de production.
   
   Bien qu'il existe certains systèmes CRM qui vous aideront à comparer et à copier des éléments de configuration, en général, il sera utile de noter vos configurations pour ne pas oublier les éléments cruciaux. La plupart des CRM fournissent une API à leur configuration, il est donc possible d'automatiser cette étape.

3. Vous courez un risque plus élevé de polluer les données de production. Imaginez une seconde deux développeurs travaillant sur une intégration. Vous avez déjà un système de mise en scène du système de commande du robot. Cette mise en scène est également connectée à votre CRM. Une fois votre intégration expédiée, vous devrez vous rappeler de déconnecter les trois systèmes, sinon vous risquez de créer des données de test sur votre (maintenant) CRM de production.

Tous ces problèmes peuvent être évités en développant dès le départ un système de test. La production n'est introduite qu'à la toute fin, juste avant que tout ne soit mis en ligne. De cette façon, vous vous retrouvez avec une configuration propre, ne courez pas le risque d'oublier de déconnecter les systèmes locaux et avez un avertissement lors de la mise en œuvre de nouvelles fonctionnalités.

Définir l'ID pour faire correspondre les entités

Maintenant, commençons à écrire le code d'intégration proprement dit. Prenons l'exemple de la synchronisation des contacts avec un système CRM. Vraisemblablement, vous devrez créer de nouveaux contacts et mettre à jour les contacts existants. Afin de distinguer une création d'une mise à jour, vous devez lier les deux entités. De cette façon, vous pouvez vérifier si le contact dans votre système existe sur le système externe.

Bien qu'il semble attrayant d'utiliser simplement l'adresse e-mail (après tout, il s'agit d'un identifiant commun pour un enregistrement de contact), il existe une solution plus générale : pour chaque enregistrement, vous vous synchronisez avec un système externe et un identifiant dans votre propre base de données.

Alors, modifiez votre table de contacts avec une colonne appelée crm_id ou external_id . Cette approche présente quelques avantages :

• Comme il s'agit d'un identifiant, il ne changera pas (contrairement à une adresse e-mail ou à un numéro de téléphone).
• Vous pouvez voir si vous devez créer ou mettre à jour l'entité sans effectuer d'abord un appel d'API (si le champ d'ID externe est vide, vous pouvez supposer que le contact n'existe pas).

Avant de:

Après:

Par exemple, supposons que vous êtes un développeur Ruby on Rails travaillant sur une application qui doit synchroniser les clients existants et nouveaux avec HubSpot.

Un exemple de code simplifié pourrait ressembler à ceci :

 class HubspotSync def sync(customer) hubspot_return = if customer.hubspot_id.present? update(customer, customer.hubspot_id) else create(customer) end customer.update(hubspot_id: hubspot_return['companyId']) end private def create(customer) response = HTTParpty.post("https://api.hubapi.com/companies/v2/companies", map(company)) handle_response(response) end def update(customer, hubspot_id) response = HTTParpty.put("https://api.hubapi.com/companies/v2/companies/#{hubspot_id}", map(company)) handle_response(response) end def handle_response(response) raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500 JSON.parse(response.body) end def map(company) # mapping code goes here { properties: [ name: 'name', value: company.name ] } end end

Remarquez comment nous profitons de l'enregistrement du companyId renvoyé par HubSpot. Non seulement cela nous aide à déterminer si nous voulons mettre à jour ou créer une entreprise sur HubSpot, mais nous pouvons également voir dans le tableau de la base de données quelles entités sont déjà synchronisées avec HubSpot et lesquelles sont toujours manquantes.

Quand il s'agit de cartographier les champs, optez pour le style libre

J'ai vu des projets où la mise en œuvre est précédée par la création d'une feuille de calcul Excel géante définissant quelles colonnes vont où dans le système CRM, avec des annotations sur la façon dont les données doivent être transformées.

En réalité, il n'y a que quelques façons de représenter les contacts et les transactions. Ainsi, au lieu de passer beaucoup de temps à réfléchir à la façon exacte dont vous voulez cartographier, pourquoi ne pas commencer par une expérience ? Donnez au développeur un peu d'espace pour comprendre le mappage, mais restez également en contact afin que les questions puissent se poser tôt.

Au moins pour les champs de contact généraux (nom, adresse e-mail, numéro de téléphone, adresse), le mappage sera très simple et les transformations sont généralement triviales.

En ce qui concerne la cartographie des statuts pour les transactions, un peu plus de communication est utile (parfois, le premier statut est appelé open , parfois new , et parfois, le modèle de statut ne correspond pas à 100 %, vous devrez donc regrouper les statuts ). Au lieu de trouver la solution parfaite, examinez vos données actuelles et voyez comment elles s'intégreraient le mieux au modèle de données du CRM. Après tout, vous êtes une entreprise agile, n'est-ce pas ?

Dans l'exemple ci-dessus, vous pouvez voir une méthode map qui convertit notre modèle Rails en un hachage régulier compris par HubSpot. Pour ce cas d'utilisation particulier, le seul élément synchronisé est le nom. Pour une utilisation plus avancée, vous voudrez probablement inclure plus de champs, mais pour un bon résultat, commencez par une supposition éclairée et communiquez souvent avec le côté commercial pour les détails.

Envisagez les tentatives

Passons au niveau plus technique : implémenter la synchronisation proprement dite entre votre système et le CRM. Il est presque certain que l'intégration aura lieu via une connexion HTTP. La plupart des systèmes fournissent une API HTTP et tous les langages de programmation vous permettront de passer très facilement des appels HTTP.

Malheureusement, peu importe combien d'argent vous dépensez pour un système CRM, il ne sera finalement pas accessible. Cela arrivera à un moment donné et vous ne pourrez rien y faire. Donc, autant en tenir compte lorsque vous développez votre intégration.

En pratique, cela signifie que chaque fois que vous appelez une API, assurez-vous que votre appel est réessayé en cas de problème (code d'état 500 de l'autre côté). L'implémentation de nouvelles tentatives est généralement fournie par des bibliothèques tierces de la langue de votre choix.

En plus de simplement réessayer, vous voudrez peut-être envisager de consigner ce qui s'est exactement passé. Recevoir une notification concernant une erreur déjà résolue lors de la première tentative peut être frustrant.

Ainsi, au lieu de spammer votre canal d'erreur avec des problèmes résolus, enregistrez toutes les appels avec le nombre de tentatives pour avoir une idée de la fiabilité du système - un système pour lequel vous venez de payer beaucoup d'argent.

Si nous prenons la classe que nous avons créée comme exemple et que nous restons dans le contexte de Ruby on Rails, nous pouvons simplement envelopper l'appel dans un ActiveJob et être à peu près certains que l'appel finira par réussir. La méthode handle_response une erreur en cas de code d'état inattendu, et ActiveJob tentera une nouvelle tentative avec un backoff exponentiel. Pour une solution plus avancée, vous devez également prendre en compte les codes d'état 4xx afin d'empêcher une nouvelle tentative et d'afficher un message d'erreur à la place.

 class HubspotSyncJob < ApplicationJob def perform(customer) HubspotSync.new.sync(customer) end End

Assurez-vous que le système est réellement utilisé

OK, supposons que vous ayez tout expédié. Vous êtes super fier de votre travail et le système est mis en ligne. Maintenant quoi? Ce n'est que le début. Parce que peu importe le nombre de tests que vous faites, il y aura toujours des bogues et des modifications demandées.

Le problème est que vous n'allez pas en savoir plus à moins que vous n'utilisiez réellement votre système. Et cela se produit pour toutes sortes de raisons : le service commercial est actuellement trop occupé pour commencer à l'utiliser, la stratégie a changé ou même de nouveaux systèmes sont déjà en cours d'évaluation.

Ainsi, afin d'éviter les problèmes potentiels à long terme, assurez-vous d'avoir éliminé tous les obstacles qui empêchaient l'utilisation du système en production. Communiquez souvent entre les équipes pour aligner les nouvelles exigences. Et si vous découvrez que le système ne fonctionnera tout simplement pas pour vous, désactivez l'intégration. Cela semble dur et peut sembler très frustrant, mais c'est moins frustrant que de devoir toujours résoudre les problèmes d'incohérence des données et de trouver des solutions de contournement.

Emballer

Au final, un projet d'intégration est un sacré projet, et il y a beaucoup de choses qui peuvent mal tourner. Ce n'est pas très populaire parmi les ingénieurs pour un certain nombre de raisons, mais il peut être gratifiant de voir qu'une implémentation a un impact positif sur la productivité des personnes assises à côté de vous.

Alors pour les ingénieurs, essayez de comprendre les besoins d'un système externe tel qu'un CRM ou un système de facturation en posant des questions concrètes telles que : En quoi ce produit va-t-il vous faciliter la vie ? Avez-vous pensé aux concurrents ? Pourquoi ne fonctionnent-ils pas ?

Pour toutes les autres personnes impliquées : faites intervenir les ingénieurs le plus tôt possible, faites-leur confiance lorsqu'ils signalent des lignes rouges et n'optez pas pour un plan bon marché lorsque vous pouvez voir que la mise en œuvre de l'intégration rendra les choses beaucoup plus difficiles dans le long terme.