Coût de la création d'un service client basé sur l'IA vs coût des solutions SaaS

Coût des services d'assistance clientèle basés sur l'IA (SaaS) : exemples et références.

La principale difficulté lors de la comparaison des offres SaaS réside dans les différentes unités de tarification : certaines facturent en fonction du nombre de "conversations réussies", d'autres en fonction du nombre de places, et d'autres encore en fonction de l'ensemble de la solution. Il est donc impossible de comparer directement les prix, car il faut les convertir en "coût mensuel en fonction du volume de conversations". Voici les fourchettes de prix officielles proposées par chaque fournisseur (il est important de se référer aux tarifs les plus récents) :

• Intercom Fin : Tarif de 0,99 $ par échange
• Agent IA de Zendesk : Selon le plan d'abonnement choisi, le prix commence généralement à 50 USD par siège / par mois.
• Salesforce Einstein : différences importantes selon les configurations.

Structure des coûts de la création d'un service client basé sur l'IA

Les coûts peuvent être divisés en trois catégories, qui présentent des caractéristiques très différentes : les frais de développement sont un coût unique, les frais d'API varient en fonction de l'utilisation, et les frais de maintenance dépendent de votre décision de les externaliser ou non. La séparation de ces trois catégories permet une prise de décision indépendante pour chacune : par exemple, vous pouvez d'abord externaliser la maintenance, puis reprendre le contrôle une fois que l'équipe est formée. Prenons l'exemple des tarifs proposés par Falcon :

• Développement de Falcon MVP : coût unique de 25 000 à 37 500 TWD
• Coût de l'API IA : entre 5 000 et 30 000 € par mois (le coût de l'API correspond à l'utilisation réelle, au prix de revient).
• Coût de maintenance du Falcon : 2 500 à 7 500 TWD par mois (possibilité de choisir un forfait mensuel ou un paiement à l'heure)

Comment calculer le coût total sur trois ans ?

Lors de la comparaison de deux options, il est recommandé d'utiliser la même formule pour calculer le coût total sur trois ans, en remplaçant vos propres chiffres : Coût SaaS sur trois ans = (coût mensuel ou coût par résolution × votre volume de conversations mensuelles) × 36 mois + frais de mise en place ; Coût de développement sur trois ans = frais de développement initiaux + (coût mensuel de l'API + frais de maintenance) × 36 mois. Deux remarques importantes : premièrement, le volume de conversations est la variable la plus importante – lorsque le volume est faible, le SaaS est presque toujours plus économique, tandis que lorsque le volume est élevé, les coûts fixes du développement seront dilués ; deuxièmement, le prix du SaaS peut varier en fonction du plan, et le prix de l'API pour le développement peut également varier. Pour obtenir des résultats fiables, il est préférable d'utiliser des fourchettes plutôt que des valeurs uniques. Nous accompagnons nos clients dans le calcul réel de cette formule lors de la présentation des devis, plutôt que de simplement leur dire qu'une option est "plus économique à long terme".

Dans quelles situations le modèle SaaS (Software as a Service) est-il le plus approprié ?

Pour être franc, dans de nombreuses situations, le modèle SaaS (Software as a Service) est une option plus judicieuse, et nous recommandons de suivre cette approche.

• Nécessite une mise en ligne immédiate (les solutions SaaS prennent généralement 1 semaine, tandis que les solutions auto-construites nécessitent 3 à 4 semaines).
• L'équipe ne dispose pas de personnel informatique pour la maintenance.
• Le processus de service client est standardisé et ne nécessite pas de personnalisation excessive.
• Le nombre de clients est encore faible, et le volume de conversations mensuelles est inférieur à 1 000.

Dans quelles situations la construction de sa propre maison est-elle plus avantageuse ?

Inversement, dans les situations suivantes, les coûts et la flexibilité des systèmes auto-construits sont généralement plus avantageux :

• Volume important de communication (coûts de mise en place faibles grâce à la construction interne)
• Nécessite une connexion aux systèmes internes / bases de données.
• Il existe des exigences réglementaires spécifiques (notamment dans les secteurs de la finance et de la santé).
• J'espère éviter d'être lié à des frais de licence à long terme.

Coûts liés au passage d'un modèle SaaS (Software as a Service) à un modèle de développement interne (ou inversement).

De nombreuses entreprises adoptent une approche progressive : d'abord, elles utilisent une solution SaaS pour valider et tester, puis, une fois que le volume de données est suffisamment important, elles migrent vers une solution interne. Cette approche est viable, mais il est important de prendre en compte les coûts associés à la transition. Ces coûts comprennent : 1. La portabilité de la base de connaissances : Les questions et les documents bien organisés sont des actifs précieux. Lors du choix d'une solution SaaS, il est essentiel de vérifier si une exportation complète est possible, et si le format est compatible. 2. L'historique des conversations : Les conversations passées sont des données précieuses pour l'entraînement et l'optimisation. Il est donc important de se renseigner sur les limitations d'exportation avant de migrer. 3. La réintégration des processus : Les notifications, les transferts vers des agents et les processus de gestion des tickets qui étaient auparavant gérés par la solution SaaS doivent être réintégrés. 4. La période de coexistence : Il est nécessaire de faire fonctionner les deux systèmes (le SaaS et la solution interne) en parallèle pendant une période donnée, ce qui entraîne des coûts supplémentaires pour les deux. L'approche inverse (de la solution interne vers le SaaS) est généralement moins coûteuse, car les données sont déjà disponibles lorsque vous migrez vers une solution SaaS. C'est pourquoi nous incluons la notion de "propriété des données par le client" dans nos normes de livraison.

Comment évaluer les résultats après la mise en place : les indicateurs à suivre

Beaucoup de dirigeants évaluent l'efficacité des chatbots basés sur l'IA uniquement en fonction de leur "impression" quant à l'amélioration de la "sagesse", ce qui rend difficile de les convaincre de continuer à investir. Il est recommandé de définir dès le départ plusieurs indicateurs mesurables : taux de résolution automatique (pourcentage de conversations qui se terminent sans transfert vers un agent humain), temps de première réponse, satisfaction client (CSAT), et variation des coûts ou du temps moyen de traitement. Il est important de souligner que ces chiffres varient considérablement en fonction du secteur, de la complexité des problèmes, et du niveau de maturité de la base de connaissances. Il ne faut donc pas se fier aveuglément aux affirmations telles que "taux de résolution de 80 %". Notre approche consiste à établir une base de référence avant le déploiement, puis à comparer les résultats après, afin de pouvoir évaluer objectivement et de discuter des progrès de manière constructive.

Les erreurs courantes lors de l'implémentation de l'IA pour le service client

Si l'intégration rencontre des difficultés, il est probable que ce ne soit pas dû à un manque de puissance du modèle, mais plutôt à ces points suivants : 1. Une base de connaissances trop sale : les documents sont désorganisés, le contenu est obsolète, et l'IA reçoit des données de mauvaise qualité, ce qui entraîne des réponses inexactes. (Le principe "garbage in, garbage out" s'applique ici). 2. Des attentes irréalistes : l'idée que l'IA puisse remplacer complètement l'humain, et la réaction négative lorsqu'elle ne répond pas correctement. La bonne approche serait de concevoir un mécanisme de secours pour l'humain. 3. Un déploiement sans suivi : si personne ne vérifie régulièrement les réponses incorrectes et ne met à jour le contenu, la précision diminuera avec le temps. 4. Une vision trop optimiste : une sous-estimation du temps nécessaire pour la préparation et la maintenance. Nous préférons aborder ces points dès le début, afin d'éviter que vous ne réalisiez les écarts une fois le système mis en place.