L’intégration téléphonie CRM et ERP consiste à faire circuler les données dans les deux sens entre vos appels et vos systèmes de gestion. À l’arrivée d’un appel, la téléphonie interroge votre CRM pour identifier le client et adapter le parcours ; à la fin, elle y consigne automatiquement l’appel, sa durée, son issue et, si vous le souhaitez, une transcription ou un résumé.
Résultat : des agents qui savent à qui ils parlent avant de décrocher, des SVI et voicebots capables de répondre avec des informations réelles, et un historique client complet sans ressaisie.
Ce que l’intégration permet concrètement
- Identification de l’appelant : rapprochement du numéro avec une fiche client, ou identification par numéro de dossier, de contrat ou de commande saisi au clavier ou dicté.
- Remontée de fiche (screen pop) : ouverture de la fiche sur le poste de l’agent au moment où l’appel est présenté.
- Journalisation automatique : création d’une activité d’appel dans le CRM avec horodatage, agent, file, durée, issue et lien vers l’enregistrement.
- Libre-service alimenté par vos données : solde, statut de commande, prochain rendez-vous, facture en cours, directement dans le SVI ou le voicebot.
- Actions en écriture : prise de rendez-vous, mise à jour d’une adresse, ouverture d’un ticket, enregistrement d’un paiement, avec les contrôles appropriés.
- Routage selon les données : priorité aux clients ayant un dossier ouvert, orientation vers le gestionnaire attitré, langue préférée.
Notre étude de cas sur le paiement sécurisé illustre ce principe : un voicebot intégré au système de facturation et au CRM y a réduit les coûts de 65 % et divisé par trois la durée de traitement.
Systèmes que nous intégrons
| Type de système | Exemples | Usages fréquents |
|---|---|---|
| CRM | Salesforce, HubSpot, Microsoft Dynamics | identification, screen pop, journalisation |
| ERP | SAP, ERP sectoriels | commandes, facturation, stocks |
| Agendas et outils métier | logiciels de prise de rendez-vous, outils de billetterie | réservation, confirmation, rappels |
| Bases de données | PostgreSQL, MySQL, SQL Server | applications maison, historiques |
Nous n’avons de partenariat avec aucun de ces éditeurs : nous intégrons ce que vous utilisez déjà, via leurs API documentées.
Comment nous la réalisons
Un connecteur entre la téléphonie et vos systèmes
Plutôt que d’appeler le CRM directement depuis le dialplan, nous plaçons un service d’intégration intermédiaire. Côté téléphonie, il est sollicité par Asterisk AGI pour des requêtes simples ou par ARI pour les parcours pilotés par une application. Côté métier, il dialogue avec vos API REST ou SOAP, vos webhooks ou, en dernier recours, votre base de données.
Cette séparation présente trois avantages : la téléphonie reste indépendante du CRM, les identifiants d’accès sont centralisés, et un changement de CRM n’oblige pas à refaire les parcours d’appel.
Performance et repli
Pendant un appel, chaque milliseconde compte. Nous fixons des délais maximaux, mettons en cache les données peu volatiles et prévoyons toujours un chemin par défaut : si le CRM ne répond pas, l’appel est routé normalement, sans enrichissement.
Sécurité des données
Échanges chiffrés, comptes de service aux droits minimaux, journalisation des accès, et attention particulière aux données sensibles (paiement, santé). Pour les paiements, nous concevons des parcours qui limitent l’exposition des données de carte, comme dans notre projet de voicebot de paiement sécurisé. Les exigences exactes dépendent de votre contexte réglementaire.
Les pièges fréquents
La plupart des difficultés relèvent moins de la technique que de la conception. Nous les traitons dès le départ :
- Rapprochement des numéros peu fiable : formats différents, lignes partagées, plusieurs contacts sur un même numéro. Nous normalisons les numéros (E.164) et définissons le comportement en cas d’absence ou de doublon.
- Limites d’API : certains CRM plafonnent le nombre de requêtes. Les pointes d’appels doivent tenir dans ces limites, ce qui impose parfois un cache ou une journalisation différée.
- Doublons dans l’historique : transferts et rappels peuvent créer plusieurs activités pour une même conversation. Nous fixons une règle claire de représentation d’un appel.
- Droits trop larges : nous demandons uniquement l’accès aux objets et champs réellement nécessaires.
Comment se déroule un projet
- Inventaire : systèmes concernés, données utiles à chaque étape de l’appel, API disponibles et leurs limites.
- Spécification des échanges : quelles données lire, lesquelles écrire, à quel moment, avec quels droits.
- Développement du connecteur et tests sur un environnement de préproduction du CRM ou de l’ERP.
- Pilote sur une file ou un flux d’appels, avec vérification de la qualité des données journalisées.
- Généralisation et suivi : extension aux autres flux, surveillance des erreurs d’intégration.
À quoi vous attendre et prérequis
Ce que vous obtenez : un connecteur documenté, des parcours d’appel enrichis par vos données, un historique d’appels fiable dans votre CRM et des tableaux de bord sur les erreurs d’intégration.
Prérequis :
- un accès API à vos systèmes (clés ou comptes de service) et, idéalement, un environnement de test ;
- une règle claire d’identification des clients (numéro de téléphone, numéro de dossier, etc.) ;
- un responsable de la donnée côté métier pour valider ce qui est lu et écrit ;
- une téléphonie accessible en SIP, ou une interconnexion à définir avec nous.
Cette intégration s’appuie souvent sur une couche d’orchestration téléphonique et profite particulièrement aux services financiers, où l’identification et la traçabilité sont centrales.