FrontLine Connaissances — une seule base de connaissances pour tous vos clients, scope par audience.
Les procédures du tenant et les références spécifiques aux clients partagent un seul index. La visibilité se résout au moment de la requête. Cycle Knowledge-Centered Service (KCS), recherche plein texte avec analytique zéro-résultat, alertes de propriété et de péremption, porte de révision de conformité, flux d'arbres de décision et portail client filtré par audience.
Connaissances
Rédigez, révisez et publiez des articles pour votre tenant, vos clients ou vos LOB.
Protocole de salutation standard — Appels entrants
Service à la clientèle
20 mai
Vérification du titulaire de carte PCI-DSS — v2
Conformité et Réglementaire
19 mai
Matrice d'escalade — Quand transférer
Service à la clientèle
18 mai
Gestion des RPI lors de la vérification
Conformité
5 mai
RetailCo — Catalogue de produits
Spécifique au compte
14 mai
Script de vérification PIPEDA — Brouillon
Processus et Politique
20 mai
Ce qui est difficile dans la gestion des connaissances chez un BPO multi-clients
Les outils génériques de base de connaissances (BDC) supposent une seule entreprise, une seule équipe, un seul manuel. Le modèle BPO casse chaque hypothèse dès le premier jour.
La confidentialité inter-clients dépend du filtrage applicatif
La visibilité tient sur un filtre applicatif. Nouvelles LDA, rattachements de rôle, refactos de recherche : la surface de fuite croît. Chaque MSA suppose que le filtre tient.
Les articles deviennent obsolètes quand les auteurs changent d'équipe
L'auteur de la procédure change d'équipe. Six mois passent ; l'article est erroné. La péremption ne se révèle qu'à l'audit manuel.
Les recherches zéro-résultat sont du temps de traitement répété
L'agent cherche un article qui existe sous un autre titre. Le même appel reçoit une réponse différente. Les BDC génériques traitent ça comme du bruit de journal.
La révision de conformité passe par les courriels et les documents Word
Procédures réglementées révisées en chaînes de pièces jointes. Le KM recopie la version approuvée dans la BDC. Personne ne peut prouver quelle version les agents ont vue à une date donnée.
Rédiger en deux langues sans perdre le lien
EN et FR partagent une procédure mais vivent comme URL et versions distinctes. EN gagne des révisions ; FR reste en arrière. La traduction dérive sans signal.
La logique de décision vit dans les antisèches et la tête des superviseurs
Admissibilité au remboursement, vérification PCI, seuils d'escalade : ce sont des décisions, pas des documents. Listes survolées, organigrammes périmés. La logique finit dans la tête des superviseurs.
Ce que FrontLine fait pour votre programme de connaissances
Sept surfaces conçues pour le travail de connaissances en BPO multi-clients.
Fonctionnalité 01
Portée d'audience appliquée à la base de données
Chaque article porte des enregistrements d'audience : tenant, compte client ou LOB spécifique. La vérification de visibilité se compose dans la même requête que les points d'accès liste, recherche et détail.
- Modèle de portée à trois niveaux. Les audiences tenant servent tout le monde. Les audiences client correspondent aux rattachements de compte de l'utilisateur. Les audiences LOB correspondent à la LOB rattachée. Un article peut porter plusieurs portées.
- Sous-requête EXISTS sur chaque point d'accès. La vérification de portée s'exécute comme sous-requête EXISTS sur knowledge_article_audiences. Liste, recherche, détail et articles connexes partagent tous le même prédicat.
- Le portail client lit la même table. L'édition interne et le portail client lisent dans knowledge_articles. Le point d'accès du portail applique un filtrage d'audience plus strict.
- Contournement administratif par rôle. tenant_admin, hr_admin et operations_manager contournent la portée d'audience pour la révision tenant. La vérification de rôle est explicite et auditée.
Portée d'audience
Appelant
Agent · RetailCo / Card Services
Articles visibles
47 sur 312 dans le tenant
Fonctionnalité 02
Cycle KCS complet avec alertes de propriété et de péremption
Machine à sept états sur chaque article : brouillon, capturé, structuré, approuvé, publié, périmé, archivé. Les transferts de propriété sont de première classe. Le balayage nocturne signale les articles expirés et notifie le propriétaire ; la passe 2 escalade au réviseur.
- Machine à sept états. Chaque transition émet un événement d'audit avec from_state et to_state. La vue liste filtre par état ; chaque ligne porte un badge d'état.
- Imputabilité propriétaire et réviseur. Chaque article porte owner_employee_id et reviewer_employee_id. Le balayage à deux passes notifie d'abord le propriétaire, puis le réviseur 30 jours plus tard si aucune action.
- Porte de révision de conformité. Les articles Conformité et Réglementaire passent par la file du réviseur assigné. L'article reste en pending_approval jusqu'à l'approbation. L'édition après approbation réinitialise la chaîne.
- Historique d'édition versionné. Chaque modification écrit une nouvelle ligne knowledge_article_versions. Les retours en arrière créent une nouvelle version pointant vers le contenu précédent.
Cycle de vie Knowledge-Centered Service
Chaque transition émet un événement d'audit
Propriétaire modifie → version, balayage signale les expirés, réviseur approuve
Fonctionnalité 03
Recherche plein texte avec analytique zéro-résultat
Index tsvector Postgres sur titre, résumé, corps et étiquettes. Chaque recherche zéro-résultat est enregistrée, regroupée et normalisée. L'indice de qualité par article surface les meilleurs et les moins bons sur le tableau de bord de l'éditeur.
- Recherche plein texte indexée. tsvector sur titre, résumé, corps et étiquettes. La portée d'audience et les filtres de catégorie se composent dans la même requête.
- Journal des requêtes zéro-résultat. Capturé avec caller_kind, query_text et horodatage. Regroupé et normalisé pour la vue éditeur ; douze recherches de la même requête apparaissent comme une ligne avec douze occurrences.
- Indice de qualité par article. Le cumul nocturne calcule quality_index à partir des vues, de la portée d'agents uniques et de l'utilisation en résolution. Les éditeurs trient par qualité, vues ou agents uniques 30j.
- Articles connexes. La similarité de contenu (fréquence de terme–fréquence inverse de document) se révèle sur chaque page de détail d'article. Les épinglages d'éditeur remplacent la correspondance algorithmique.
Analytique éditeur
Meilleurs performeurs
Qualité · Vues
Protocole de salutation — Entrée
0,92246Matrice d'escalade — Transfert
0,88182Travail post-appel — Standard
0,81151Requêtes zéro-résultat
Occ.
calendrier de rétrofacturation
9×retour sans reçu
7×ligne française Québec
5×Fonctionnalité 04
Interface bilingue aujourd'hui ; jumelage d'articles EN ↔ FR en feuille de route
Chaque surface de l'interface est entièrement bilingue (EN ↔ FR) et s'affiche dans la langue de l'utilisateur. Les corps d'articles peuvent être rédigés dans l'une ou l'autre langue. Le schéma de lignes sœurs qui lie un article anglais à sa traduction française et signale la péremption d'une langue quand l'autre change est inscrit à la feuille de route de l'Atlas — pas livré aujourd'hui.
- Interface bilingue aujourd'hui. Chaque surface — éditeur, lecteur agent, portail client — s'affiche en EN ou FR selon la langue préférée de l'utilisateur. Les utilisateurs québécois voient la plateforme en français dès le premier jour.
- Articles rédigeables dans l'une ou l'autre langue. Une procédure en anglais et une procédure en français peuvent coexister dans la BDC. Elles ne sont pas encore liées structurellement, donc les éditeurs suivent les paires de traduction à l'extérieur de la plateforme en attendant le schéma de lignes sœurs.
- En feuille de route — schéma de lignes sœurs. Une future migration ajoute locale, translation_group_id et translation_stale_at à knowledge_articles. Les modifications source définiront translation_stale_at sur chaque sœur d'une autre langue. Suivez le statut sur l'Atlas : spec 32, fonctionnalité bilingual_content.
Éditeur d'article · sœurs linguistiques
Modifier l'article
Protocole de salutation standard — Entrée
Ouverture requise pour chaque interaction entrante. Couvre la mention de la marque, l'identification de l'agent, la divulgation d'enregistrement.
Traductions
Standard Greeting Protocol — Inbound
Fonctionnalité 05
Flux de connaissances — arbres de décision avec exécution côté agent
Une toile visuelle construit le graphe nœud-arête. Le runtime agent avance une question à la fois. Chaque session est capturée pour la révision assurance qualité (QA) et le lien de coaching.
- Six types de nœuds. prompt, branche, saisie, action, porte_de_conformité, terminal. Le graphe valide la couverture des terminaux avant la publication.
- Runtime agent avec capture de session. L'agent ouvre /knowledge/flows/[id]/run, répond à une question à la fois, atteint un terminal. Chaque transition est auditée ; les abandons sont enregistrés.
- Portes de conformité intégrées. Case à cocher de reconnaissance requise plus libellé avant de continuer. La reconnaissance est auditée par session.
- Parité avec les articles. Les flux partagent la catégorisation, la portée d'audience et l'historique de versions avec les articles. Même cycle de vie, mêmes surfaces d'éditeur.
Arbre de décision · runtime agent
Session #2841 · refund_eligibility
Abandonnerbranch
Le client a-t-il reçu le produit ?
Oui — passer à la vérification
→Non — escalader aux opérations
→Suivant : porte de conformité · vérification PCI
Fonctionnalité 06
Lecteur du portail client pour les connaissances en libre-service
Les articles publiés apparaissent dans le portail client via la sous-requête EXISTS d'audience. Quatre filtres se composent en une seule requête : recherche, sélecteur de client, sélecteur LOB chaîné, sélecteur de catégorie.
- Liste filtrée par audience. Le point d'accès du portail exécute la même sous-requête d'audience que l'interne. Des règles de portée plus strictes s'appliquent.
- Quatre dimensions de filtre. Recherche en texte libre, sélecteur de compte client, sélecteur LOB chaîné, sélecteur de catégorie. Les quatre se composent en une requête aller-retour.
- Brouillons cachés du portail. Seuls les articles publiés et périmés retournent. Les brouillons et états archivés n'atteignent jamais le portail.
Portail client · connaissances
Rechercher articles, résumés, catégories…
47 articles
Politique de retour de carte — RetailCo
Processus et Politique · RetailCo
Fenêtre de retour des fêtes — prolongée
Service à la clientèle · RetailCo
Chemin d'escalade de rétrofacturation
Conformité et Réglementaire · RetailCo
Fonctionnalité 07
Chaque lecture, modification et publication dans le journal d'audit unifié
Chaque opération privilégiée émet une ligne audit_events immuable. Les événements de connaissances arrivent dans la même table que tous les autres modules.
- Audit par action. knowledge.article.publish, archive, approve, update (avec diff au niveau du champ). Chaque ligne est immuable.
- Suivi des vues. knowledge_article_views enregistre actor_user_id, caller_kind et viewed_at à chaque lecture.
- Version-de-lecture. Les lectures capturent la version que l'agent a vue. Les auditeurs récupèrent le contenu exact depuis l'horodatage d'un incident.
- Visualiseur unifié. Filtrez le journal d'audit par acteur, action, ressource et plage de dates. Un seul visualiseur couvre chaque action à travers les modules.
audit_events · module connaissances
Flux en direct
L'édition interne et le portail client lisent la même table
Les connaissances se trouvent à la jonction entre les opérations d'agent et le libre-service client. Les deux surfaces lisent knowledge_articles. Le point d'accès du portail applique un filtre d'audience plus strict pour que les utilisateurs clients ne voient que les lignes scopées à leur compte et leurs LOB. Une seule source de vérité. Deux surfaces. Aucun export, aucune seconde mémoire.
- Même sous-requête EXISTS aux deux bouts. Les points d'accès liste, recherche et détail internes partagent le prédicat d'audience avec le point d'accès du portail. Le portail ajoute des règles de portée plus strictes ; la forme du prédicat reste la même.
- Jeu de filtres du portail client. Recherche sur titre, résumé et catégorie. Sélecteur de compte client. Sélecteur LOB chaîné. Sélecteur de catégorie. Les quatre se composent en une requête aller-retour.
- Brouillons cachés du portail. Seuls les articles publiés et périmés retournent au portail. Les brouillons et versions archivées n'atteignent jamais le portail.
- Passage de révision administrative interne. Les rôles tenant_admin, hr_admin et operations_manager contournent la portée d'audience pendant un partage d'écran client. La vérification de rôle est explicite et auditée.
Édition interne
Protocole de salutation — Entrée
Publiéil y a 2jVérification PCI-DSS — v2
Approuvéil y a 1jknowledge_articles
312 lignes · portée par audience
Portail client · RetailCo
Politique de retour — RetailCo
Processus et PolitiqueFenêtre de retour des fêtes — prolongée
Service à la clientèleRésultats d'affaires pour le dirigeant des opérations
Ce que cela représente en termes de P&L BPO.
Les agents trouvent la réponse à la première recherche
Recherche classée par langue, articles connexes et analytique zéro-résultat réduisent le temps médian recherche-à-lecture. L'article recherché mais non ouvert indique à l'éditeur quel titre réécrire.
Les clauses de confidentialité MSA défendables à la couche de requête
La portée d'audience à trois niveaux s'exécute comme sous-requête de base de données. La fuite inter-clients exige un changement délibéré de base de données pour se produire.
Connaissances prêtes pour l'audit sans semaines de préparation
Les articles réglementés passent par le réviseur assigné. Chaque modification, publication et lecture est capturée. Les auditeurs obtiennent versions et horodatages en secondes.
Une surface de connaissances remplace la pile SharePoint
Les BPO multi-clients exécutent typiquement trois à quatre outils BDC plus une structure de dossiers. La consolidation réduit le coût BDC par agent et met fin à la question de quel outil consulter.
Ce que les opérations de connaissances récupèrent
Résultats indicatifs — la magnitude réelle dépend de votre cadence d'édition, de votre discipline de portée d'audience et de votre référence de départ.
La portée d'audience est la valeur par défaut de la base de données
Zéro heure/trimestre à rebâtir la visibilité inter-clients — chaque article porte sa portée d'audience à la couche de données, pas dans l'hygiène de dossiers.
Recherches zéro-résultat en forte baisse
Après plusieurs cycles d'éditeur fermant les écarts les plus fréquents. La file zéro-résultat est la liste « à corriger », pas une métrique à cacher.
Jours → heures
La file d'approbation du réviseur remplace la chaîne de courriels. La magnitude dépend de la longueur de votre cycle antérieur.
Une seule source pour tous les clients
Remplace la pile SharePoint / Confluence / dossiers par client par une seule plateforme, une seule recherche, une seule chaîne d'audit.
Posture réglementaire
FrontLine Connaissances vs. SharePoint / Confluence / Zendesk Guide
Cinq différences que les responsables KM BPO multi-clients remarquent dans le premier mois.
| FrontLine Connaissances | BDC générique | |
|---|---|---|
Portée d'audience à trois niveaux (tenant / client / LOB) appliquée à la base de données Les BDC génériques s'appuient sur les permissions de dossier ou les rôles de page. | ||
Cycle KCS complet (brouillon / capturé / structuré / approuvé / publié / périmé / archivé) La plupart livrent brouillon / publié / archivé. Capturé, structuré et périmé exigent des flux personnalisés. | ||
Analytique de recherche zéro-résultat surfacée comme file « à corriger » de l'éditeur La recherche existe ; le suivi zéro-résultat surfacé pour l'éditeur avec regroupement de requêtes normalisé, non. | ||
Porte de révision de conformité acheminant les articles réglementés via un réviseur assigné La révision dépend des chaînes de courriels ou des verrouillages de page. | ||
Flux de connaissances — procédures d'arbres de décision avec portes de conformité auditées Les BDC génériques offrent des listes ordonnées ou des images d'organigrammes. |
En production aujourd'hui
Cycle d'édition, portée d'audience, recherche avec analytique zéro-résultat, porte de révision de conformité, journal d'audit, lecteur du portail client et la sous-spécification Flux de connaissances (32A) sont livrés aujourd'hui. Le jumelage bilingue d'articles par lignes sœurs et l'analytique d'efficacité plus poussée sont en feuille de route — voyez l'Atlas pour le statut en direct.
Questions que les responsables KM posent avant de signer
Tirées d'appels d'adéquation. Réponses courtes et directes.
Comment les articles spécifiques aux clients sont-ils isolés des autres clients ?+
Que se passe-t-il pour les articles en cours quand un auteur part ?+
Comment FrontLine gère-t-il les connaissances bilingues EN ↔ FR ?+
Comment savons-nous ce que les agents ne peuvent pas trouver ?+
Le portail client peut-il montrer uniquement le contenu du client ?+
Comment les articles réglementés sont-ils révisés avant la publication ?+
Livrez-vous avec du contenu de départ ?+
Prêt à le voir dans votre environnement ?
Deux façons de passer à l'étape suivante.
Autres équipes utilisant FrontLine
Les connaissances côtoient la QA, la formation, la conformité et le portail client.