Un process suivi de bout en bout, du premier contact jusqu'à la relance

Quand un prestataire répond à cette question par une présentation, la question reste posée. Un cas se raconte autrement : par le mécanisme. Voici l'un des nôtres, celui du traitement des demandes entrantes, qui est aussi le plus transposable d'une entreprise à l'autre.

La situation de départ

Les demandes arrivaient par quatre canaux : un formulaire du site, une boîte e-mail générique, le téléphone, et un numéro de messagerie professionnelle. Aucun des quatre ne parlait aux autres. La qualification se faisait de tête, la relance dépendait de la mémoire de la personne disponible, et personne n'était capable de dire combien de demandes étaient restées sans réponse la semaine précédente.

Le coût n'était pas dans le temps de traitement d'une demande. Il était dans celles qui tombaient.

Le découpage

Nous avons découpé le process en six étapes, en décidant pour chacune qui l'exécute :

• Réception. Les quatre canaux écrivent dans un seul endroit, avec l'origine conservée. Entièrement automatique.
• Nettoyage. Détection des doublons, normalisation du téléphone et de l'adresse, rattachement au client existant s'il y en a un. Automatique, règles déterministes.
• Qualification. Le modèle lit la demande, en extrait l'objet, l'urgence, le secteur, et propose un niveau de priorité avec une justification en une phrase. Automatique, mais rien n'est envoyé au client à cette étape.
• Réponse. Une proposition de réponse est rédigée à partir de la base de connaissances interne. Elle est soumise à un humain sur les demandes sensibles, envoyée directement sur les cas simples et fréquents.
• Relance. Programmée automatiquement, annulée automatiquement dès qu'une réponse arrive, plafonnée en nombre.
• Clôture et mesure. Chaque demande finit dans un état explicite, avec ses délais enregistrés.

Où passe la frontière

La règle que nous appliquons ici est constante : la machine prépare, l'humain engage l'entreprise. Une qualification, un résumé, un brouillon, un classement, un rappel : la machine s'en charge seule. Un engagement contractuel, un prix négocié, un refus, un litige : un humain valide. Cette frontière ne se décide pas au moment du développement, elle se décide au cadrage, process par process. Nous détaillons ce point dans un article dédié.

Ce que ça a changé, en chiffres

Trois indicateurs ont été posés avant de commencer, et c'est ce qui rend le bilan possible : le délai médian de première réponse, la part de demandes sans réponse à quarante-huit heures, et le temps humain passé par demande. Sans ces trois chiffres pris avant, tout bilan se serait résumé à une impression.

Nous n'affichons pas ici des pourcentages génériques : d'un secteur à l'autre, ils ne veulent rien dire. Ce qui se transpose, c'est la méthode : mesurer avant, mesurer après, sur les mêmes indicateurs, et accepter que le résultat puisse être décevant sur une étape et excellent sur une autre.

Une automatisation qui n'a pas de chiffre avant n'a pas de résultat après. Elle a une réputation.

Ce qui casse, et à quelle fréquence

Trois choses cassent, et elles cassent régulièrement. Une interface de programmation change de format sans prévenir. Un modèle change de comportement après une mise à jour et devient plus bavard ou plus prudent. Et l'entreprise elle-même change une règle métier sans le dire, parce que ce n'était « qu'un détail ».

C'est pour cela que la question de la maintenance n'est pas une question annexe : elle fait partie du coût du process, pas du service après-vente. Nous y répondons dans l'article sur la maintenance.

Comment vérifier chez un prestataire

Demandez à voir le déroulé réel, pas la présentation : les étapes, le point exact où un humain intervient, le journal des exécutions, ce qui se passe en cas d'échec, et les indicateurs avant et après. Un prestataire qui a mis un process en production peut ouvrir cet écran en trente secondes. Un prestataire qui ne peut montrer qu'une vidéo n'a pas menti, mais il n'a pas répondu.