Exploitants BPO
Vous exploitez plusieurs clients finaux sur un effectif partagé. Chaque client a ses propres attentes de niveau de service, sa propre voix de marque, ses propres clauses de confidentialité, sa propre cadence de rapport — et FrontLine doit en faire la valeur par défaut, pas la configuration. La portée Locataire → Client → LDA est livrée comme primitive de données de la plateforme. Fiches d'évaluation par client, assignation d'agent sans fuite de données, portail client à portée d'audience, preuves SOC 2 sur demande, interface bilingue EN ↔ FR — tout cela parce que le multi-client était le mandat de conception, pas le cas d'usage.
| Capacité | FrontLine |
|---|---|
| Confidentialité multi-clients appliquée à la base de données (sécurité au niveau des lignes) | Oui — chaque table opérationnelle porte tenant_id + client_account_id avec RLS |
| Fiches d'évaluation, calibration et rapports qualité par client | Oui — fiches scopées par client + LDA; séances de calibration par cohorte |
| Assignation d'agents multi-clients sans dossiers employés en double | Oui — un seul dossier d'agent porte compétences, certifications et admissibilité d'acheminement par client |
| Portail client — lecture seule, à portée d'audience, heures facturables tirées du registre de présence | Oui — la fiche SLA et les heures facturables proviennent de la même source que votre facture |
| Génération de trousse de preuves SOC 2 Type II pour les revues d'approvisionnement | Oui — export CSV pré-construit par critère de confiance (audit T3 2026) |
| Interface bilingue (EN ↔ FR) pour opérations transfrontalières et canadiennes | Oui — chaque surface UI s'affiche dans la langue de l'utilisateur |
| Posture de conformité par client (LPRPDE, PCI, LDA réglementées) | Oui — rétention, audit et contrôles DSAR peuvent chevaucher au niveau du client_account |
Le modèle d'exploitation BPO — et ce que la plateforme doit rendre trivial
Le multi-client est l'architecture, pas un commutateur de fonctionnalité. Les outils HRMS et WFM génériques ont été conçus en supposant un seul employeur avec un seul effectif. Quand vous ajoutez un nouveau client BPO, ces outils vous forcent à choisir entre des instances séparées par client (pas d'effectif partagé, connexions séparées, pas de rapports consolidés) ou une grande instance avec le client comme étiquette (les données fuient chaque fois que quelqu'un oublie un filtre). Aucune de ces options n'est acceptable quand vos MSA garantissent la confidentialité par client. FrontLine traite la portée locataire → client → LDA comme une primitive de base de données — de la même façon que Postgres traite les index.
Le SLA sur le portail client doit correspondre au SLA sur la facture. La plupart des piles opérationnelles BPO ont une source pour la facturation (le registre de présence), une autre pour les rapports SLA face au client (un tableau de bord opérationnel), et une troisième pour les diapos de revue trimestrielle (reconstruites manuellement dans PowerPoint). Quand les trois divergent, le client conteste la facture et la relation se fissure. Le portail client de FrontLine lit l'adhérence et les heures facturables à partir du même registre qui pilote la paie — il n'y a pas de seconde source de vérité à réconcilier.
La confidentialité client est contractuelle, pas une préférence d'expérience. Vos MSA s'engagent à l'isolation par client : RetailCo ne peut pas voir l'effectif, les agents, les horaires ou aucune donnée inter-comptes de FinCo. La plupart des portails maison appliquent cette portée dans le code applicatif — facile à oublier quand un analyste écrit une nouvelle requête et que la liste déroulante inclut silencieusement les options d'un autre client. Le RLS pousse cette frontière dans la base de données, où la requête ne peut physiquement pas retourner des lignes inter-clients.
SOC 2 est la barrière d'approvisionnement qui détermine quels clients d'entreprise vous pouvez gagner. Les équipes d'approvisionnement d'entreprise américaines demandent maintenant un rapport Type II comme prérequis — et rassembler les preuves trimestriellement prend des semaines de temps conformité + TI à travers plusieurs disciplines. Le générateur de trousse de preuves SOC 2 de FrontLine s'exécute comme un export en un clic par critère de confiance; le journal d'audit lui-même est immuable par architecture pour que l'auditeur ne puisse pas demander « est-ce complet » et obtenir une réponse défensive.
Si le multi-client n'est pas une primitive architecturale, chaque nouveau client casse un système.
Ce que FrontLine livre pour les BPO
Chaque capacité ci-dessous correspond à un module de l'Atlas. L'architecture n'est pas rétro-conçue à partir des cas d'usage BPO — c'était le mandat de conception.
Portée Locataire → Client → LDA à la base de données
Chaque table opérationnelle porte tenant_id (votre BPO), client_account_id (votre client final) et client_lob_id (ligne d'affaires). Les politiques RLS PostgreSQL appliquent l'isolation; les requêtes inter-clients retournent zéro ligne à la base, pas dans le code applicatif. Le JWT porte le contexte locataire de façon immuable dans chaque requête. La clause de confidentialité du MSA devient une garantie au niveau de la base.
Explorer le moduleFiches d'évaluation et calibration par client
Fiches scopées par client + LDA. FinCo obtient un formulaire réglementé de 12 items; RetailCo obtient un formulaire conversationnel de 5 items. Les séances de calibration tournent par cohorte client pour que la dérive d'évaluateur par client fasse surface avant qu'elle ne fausse le chiffre AQ publié. Les rapports respectent la structure — pas de moyenne globale de l'effectif cachant quel client saigne.
Explorer le moduleAssignation d'agents multi-clients sans fuite de données
Un seul dossier d'agent porte compétences, certifications et admissibilité LDA par client. Le planificateur applique l'admissibilité au moment de publier — un agent n'apparaît que sur les quarts pour les clients pour lesquels il est certifié. Pas de rôles dupliqués, pas de matrices de compétences parallèles, pas de travail de réconciliation quand un agent prend un second client.
Explorer le modulePortail client — SLA, heures facturables, activité d'agent
Votre client final se connecte et voit sa fiche d'adhérence, ses heures facturables par LDA, trois rapports pré-construits et des articles de connaissances à portée d'audience. Il ne voit jamais les données d'autres clients, les noms d'agents, le tarif interne ou votre effectif. La même portée que le reste de la plateforme utilise; rien à verrouiller manuellement.
Explorer le moduleTrousse de preuves SOC 2 Type II
Export ZIP par période avec un CSV par critère de services de confiance (CC6, CC7, CC9, A1). Borné par période; couvre les préfixes d'événements d'audit que les feuilles de travail de l'auditeur attendent. La génération elle-même émet un événement d'audit CC9 pour que la chaîne de garde soit intacte. La course aux preuves trimestrielle de 3 semaines devient un téléchargement en un clic.
Explorer le moduleInterface bilingue dès aujourd'hui
Chaque surface — portail agent, vue superviseur, portail client, tableau de bord exécutif — s'affiche en EN ou FR selon la langue de l'utilisateur. Pour les BPO canadiens desservant des comptes québécois ou des effectifs transfrontaliers Canada + États-Unis, l'interface bilingue est la valeur par défaut plutôt qu'un module payant. Le jumelage par paire EN ↔ FR des contenus est sur la feuille de route Atlas.
Explorer le moduleQuestions fréquentes des exploitants BPO
- Combien de clients pouvons-nous exploiter sur un seul locataire FrontLine ?
- Il n'y a pas de plafond strict. L'architecture de FrontLine traite client_account comme une dimension de données de première classe, pas une étiquette — alors ajouter un nouveau client est une ligne de configuration, pas une bifurcation d'instance. Les BPO partenaires de conception aujourd'hui exploitent 4 à 12 clients par locataire avec des structures multi-LDA dans chacun. L'intégration d'un nouveau client fait partie du flux d'administration normal; aucune intervention d'ingénierie nécessaire pour les ajouts de routine.
- Le SLA sur le portail client correspond-il au SLA sur la facture ?
- Oui — les deux dérivent du même registre de présence qui pilote la paie. Il n'y a pas de seconde source de vérité à réconcilier. Quand votre client conteste un chiffre d'heures facturables, la réponse est dans l'onglet suivant du même portail; quand il conteste l'adhérence, ce sont les mêmes données jointes à l'horaire. L'exercice de réconciliation lors de la revue trimestrielle cesse d'exister.
- Pouvons-nous personnaliser le portail client par client (marque blanche) ?
- L'image de marque par client (logo, couleur principale, courriel de contact substitut) est soutenue aujourd'hui. Les domaines personnalisés (par exemple, portail.votreclient.com) sont sur la feuille de route Atlas — c'est la prochaine phase du module portail client, prévue en parallèle avec la configuration en libre-service du client. Pour les conversations d'approvisionnement qui exigent un domaine personnalisé dès le jour un, parlez à l'équipe partenaire de conception du calendrier de déploiement.
- Et la confidentialité MSA entre clients — comment est-elle appliquée ?
- Politiques de sécurité au niveau des lignes PostgreSQL sur tenant_id (votre BPO) et client_account_id (le client final) — chaque table opérationnelle. La base de données refuse physiquement les requêtes inter-clients; il n'y a pas de filtre au niveau de l'application que quelqu'un pourrait oublier. Les tentatives de sondage inter-clients (JWT tenant_id ≠ tenant_id de la ressource) sont auto-classifiées comme gravité HAUTE dans le journal d'audit, alors les tentatives de violation sont visibles avant de devenir des incidents.
- Comment FrontLine gère-t-il nos preuves SOC 2 pour les revues d'approvisionnement d'entreprise ?
- Le générateur de trousse de preuves SOC 2 exporte un ZIP borné par période avec un CSV par critère de services de confiance (CC6 Accès logique, CC7 Opérations système, CC9 Gestion des changements, A1 Disponibilité). Chaque CSV est constitué des événements d'audit filtrés pour les préfixes d'action de ce critère. Votre auditeur le charge tel quel dans ses feuilles de travail; le même export alimente le questionnaire d'approvisionnement d'entreprise qui prenait auparavant deux semaines de temps conformité + TI.
- Différents clients ont différents régimes de conformité (PCI, LPRPDE, LDA réglementées). Comment cela est-il scopé ?
- Les contrôles de conformité — planchers de rétention RP, collecteurs DSAR, portée du journal d'audit, politiques de rétention — peuvent chevaucher soit au niveau du locataire (votre posture BPO globale), soit au niveau du client_account (exigence par client). Un client FinCo réglementé peut porter un traitement RP plus strict sans l'imposer à l'effectif RetailCo; le moteur de rétention et les collecteurs DSAR respectent les deux portées simultanément.
- Devons-nous relabelliser quelque chose pour nos clients spécifiques ?
- Les étiquettes UI de la plateforme sont configurables par locataire — la plupart des BPO les laissent par défaut (« Client », « LDA », « Agent »). Certains relabellisent « Client » pour correspondre à leur terminologie face au client. Le modèle de données sous-jacent et les contrats d'intégration (client_account_id, etc.) ne changent pas; le relabellisage est un choix de couche de présentation pendant l'intégration.
Parlons de votre opération BPO
Que vous soyez une boutique de 50 agents exploitant un seul contrat d'entreprise ou une opération de 2 000 agents répartie sur 8 clients et 30 LDA, nous parcourrons comment l'architecture correspond à votre modèle d'exploitation. La plateforme est conçue autour de la forme opérationnelle exacte que vous exploitez.
Démarrer la conversationSolutions connexes
FrontLine pour les effectifs
FrontLine pour QA et coaching
FrontLine pour les clients
FrontLine pour la conformité et l'informatique
BPO de soutien technique
BPO de télécommunications
BPO de services financiers