Une base de connaissances client ne crée de la valeur que si elle est fraîche, consultable et multilingue. Dans la plupart des entreprises, les articles KB sont rédigés manuellement une fois et jamais mis à jour — les clients cherchent, trouvent des réponses obsolètes et ouvrent quand même un ticket.

La deflection échoue quand la KB ne correspond pas aux vraies questions des clients. Utilyx modélise la KB comme un workflow vivant : l'IA génère les articles depuis les tickets résolus, la recherche sémantique sert les réponses en 7 langues, et les analytics suivent les articles qui défilectent réellement les tickets.

Le workflow est structuré en arbre de décision avec 3 branches (auto-brouillon depuis ticket, backlog sujets manquants, revue vote négatif) et 7 étapes de bout en bout. Chaque action est logée dans la sous-table kb_audit. Les clients trouvent la réponse eux-mêmes seulement 20% du temps — la deflection IA KB vise 60%.

• Étape 1 (Start — Ticket résolu) : à la clôture d'un ticket support, le workflow capture case_id, ticket_category, resolution_text, customer_id, agent_id. Le copilote IA extrait l'énoncé du problème, la cause racine et les étapes de résolution.

• Étape 2 (Génération brouillon IA) : le copilote IA rédige un article KB en 7 langues depuis le contenu du cas — titre, résumé, résolution étape par étape, tags, related_articles[]. Le brouillon est routé vers le propriétaire de connaissance.

• Étape 3 (Branche — décision contenu) : Branche A (nouveau sujet) : le brouillon est publié comme nouvel article après revue du propriétaire. Branche B (mise à jour sujet existant) : le brouillon est fusionné dans un article existant via versioning (vue diff). Branche C (doublon) : le brouillon est écarté et lié à l'article canonique existant.

• Étape 4 (Recherche sémantique) : les clients et agents cherchent la KB en langage naturel via sql-query contre kb_article_index (embeddings vectoriels) ; la recherche sémantique renvoie les 5 articles les plus pertinents dans les 7 langues supportées, classés par score de pertinence — pas par mots-clés.

• Étape 5 (Deflection self-service) : quand un client commence un ticket via le portail ou le chatbot, le workflow suggère 3 articles KB correspondants avant soumission. Sous-branche A (l'article résout) : le client confirme, le ticket est défilecté et deflection_event est logé avec article_id, customer_id, channel. Sous-branche B (besoin d'aide) : le ticket continue avec les articles suggérés attachés pour le contexte agent.

• Étape 6 (Boucle de feedback) : après lecture d'un article, le client vote utile/inutile. Les votes négatifs déclenchent une tâche de revue pour le propriétaire de connaissance avec article_id et commentaire verbatim. La sous-table kb_gap_analysis loge les recherches sans article correspondant pour bâtir le backlog.

• Étape 7 (Analytics & archive) : le tableau de bord suit article_views, helpfulness_rate, deflection_rate, gap_topics[] par semaine. Le versioning des articles est archivé dans useArchive avec champs d'index article_id, version, author, publish_date pour la conformité.

Les équipes qui utilisent Utilyx constatent une réduction de 40% du volume de tickets grâce à la deflection self-service IA, et un time-to-answer 50% plus rapide pour les clients qui trouvent leur solution directement. Le taux de deflection monte de 20% à 60% à mesure que la KB mature sur le contenu réel des tickets.

Le designer visuel no-code permet à un manager de connaissance de posséder le workflow sans développeurs, et le copilote IA génère les brouillons d'articles en 7 langues depuis les cas résolus — déploiement 60% plus rapide à un TCO 70% inférieur aux suites KM legacy. Le backlog des sujets manquants garantit que la KB reste alignée sur ce que les clients demandent réellement.

La recherche sémantique en 7 langues via embeddings vectoriels signifie qu'une seule base d'articles sert une clientèle mondiale. Le versioning des articles garantit que tout changement est auditable et réversible pour la conformité.

Les analytics de manques ferment la boucle entre ce que les clients demandent et ce que la KB couvre, pour que la base reste alignée sur la demande réelle, et la sous-table kb_gap_analysis priorise les prochains articles à écrire.