Architecture multi-locataire

Isolation complète du client. Conçu pour les centres d'appels.

Règles de conformité, enregistrements, utilisateurs et facturation distincts par client. Sécurité au niveau des lignes (RLS) PostgreSQL appliquée au niveau de la base de données. Mise en service de nouveaux locataires en quelques minutes.

Réponse rapide

Qu'est-ce que l'architecture mutualisée de DialerBee ? L'architecture mutualisée de DialerBee assure une isolation complète des clients pour les BPO, les revendeurs télécoms et les organisations gérant plusieurs programmes clients. Chaque client bénéficie de données isolées (garantie par la sécurité au niveau des lignes de PostgreSQL au niveau de la base de données), de règles de conformité indépendantes (listes d'opposition au démarchage téléphonique, horaires d'appel, suivi du consentement), d'enregistrements d'appels séparés (stockage par client avec conservation et obligation légale de conservation indépendantes), d'une facturation par client (utilisation, minutes, utilisateurs suivis séparément), d'un contrôle d'accès basé sur les rôles (agents et superviseurs associés à leur client), d'un réglage de l'IA par client (la précision de l'AMD s'améliore indépendamment pour chaque client) et d'un provisionnement des clients en quelques minutes via le portail d'administration ou l'API. Disponible en 9 langues avec des langues par défaut pour chaque client.

Le problème

Les numéroteurs mono-locataires ne le font pas échelle pour les BPO

Les entreprises d'externalisation de processus métier (BPO) et les revendeurs de télécommunications gèrent plusieurs programmes clients sur une plateforme unique. Chaque client dispose de Des exigences de conformité différentes, des listes d'opposition au démarchage téléphonique différentes, des politiques d'enregistrement différentes et une facturation différente.L'exécution d'une instance de numérotation distincte pour chaque client est coûteuse, complexe à gérer et difficilement évolutive. Cependant, l'exécution de tous les clients sur une instance partagée sans isolation adéquate engendre des risques inacceptables : fuite de données d'un client vers un autre, application des règles de conformité d'un client aux campagnes d'un autre.

La plupart des composeurs n'offrent que groupes d'utilisateurs de base Il ne s'agit pas d'une véritable architecture mutualisée. Les utilisateurs peuvent être organisés en groupes, mais les données sous-jacentes sont partagées. Les rapports peuvent être filtrables par groupe, mais l'application de ce filtrage se fait au niveau de l'application, et non de la base de données. Un bug, un filtre mal configuré ou une requête API mal conçue pourraient exposer les données d'un client à un autre. Pour les prestataires de services d'externalisation de processus métier (BPO) qui traitent des données réglementées (financières, de santé ou personnelles), ce niveau d'isolation est insuffisant.

La véritable mutualisation implique une isolation à tous les niveaux : les requêtes de base de données sont limitées à chaque locataire, les enregistrements sont stockés séparément, les règles de conformité sont configurables indépendamment, la facturation est suivie par client et les contrôles d’accès rendent l’accès inter-locataires architecturalement impossible, et non seulement improbable.

N instances
Sans multi-location
Un numéroteur par client, c'est cher.
Risque
Numéroteurs à instance partagée
L'isolation de la couche application est fragile
Minutes
Pour fournir un nouveau locataire
pas des semaines de déploiement

Comment ça marche

Isolement à chaque couche

L'architecture multi-locataires de DialerBee utilise Sécurité au niveau des lignes (RLS) de PostgreSQL L'isolation des données entre locataires est assurée au niveau du moteur de base de données. Ainsi, elle n'est pas uniquement une question de logique applicative, mais bien une opération effectuée par la base de données elle-même. Chaque requête est automatiquement limitée au locataire actuel. L'accès aux données entre locataires est empêché par l'architecture du système, et non pas seulement restreint par des politiques de sécurité.

Étape 01

Isoler les données

Les données de chaque client résident dans une partition logiquement isolée. La sécurité au niveau des lignes (RLS) de PostgreSQL garantit que chaque requête est automatiquement limitée au client actuel ; cette limitation est appliquée par le moteur de base de données, et non par la logique applicative.

Étape 02

Règles d'isolement

Chaque client bénéficie de configurations de conformité indépendantes : listes d’opposition au démarchage téléphonique, règles relatives aux heures d’appel, suivi du consentement, limites de nouvelles tentatives et profils réglementaires. Les règles d’un client n’affectent jamais les campagnes d’un autre.

Étape 03

Isoler les enregistrements

Les enregistrements des appels sont stockés et consultés individuellement pour chaque locataire, en toute confidentialité. Des politiques de conservation indépendantes, des contrôles de mise sous séquestre légal et un suivi du stockage sont appliqués à chaque client.

Étape 04

Facturation isolée

L'utilisation, les minutes et les postes sont suivis par utilisateur. Exportez les données de facturation pour la facturation client ou intégrez-les à votre système de facturation. Imputation complète des coûts par client.

Comparaison côte à côte

Véritable multi-locataire vs groupes d'utilisateurs de base

Capacité Groupes d'utilisateurs de base DialerBee Multi-locataire
Isolation des données Filtres de la couche application RLS PostgreSQL au niveau du moteur de base de données
Règles de conformité Partagé avec les substitutions de groupe Indépendant par locataire — totalement isolé
Enregistrements Stockage partagé avec étiquettes de groupe Stockage isolé par locataire
Facturation Attribution manuelle Suivi automatique de l'utilisation par locataire
Provisionnement Configuration manuelle par client Minutes via le portail d'administration ou l'API
Risque inter-locataires Un filtre défectueux ou mal configuré peut entraîner une fuite de données. Architecturalement empêché par RLS
Réglage de l'IA Modèle partagé pour tous les clients Flux de travail d'optimisation AMD par locataire
Signalement Vues filtrées des données partagées Tableaux de bord et exportations par locataire

Fonctionnalités de gestion

Gérer plusieurs clients à partir d'une seule plateforme

Au-delà de l'isolation, l'architecture multi-locataires de DialerBee offre Les BPO de niveau de gestion ont besoin Pour une gestion efficace auprès de plusieurs clients, le provisionnement des locataires, le contrôle d'accès basé sur les rôles, les analyses inter-locataires pour les propriétaires de plateformes et les options en marque blanche s'associent pour rendre la gestion multi-clients opérationnellement pratique, et non seulement techniquement possible.

Contrôle d'accès basé sur les rôles

Gestion des permissions par locataire. Les administrateurs, superviseurs et agents voient uniquement les informations auxquelles ils ont droit. Les propriétaires de la plateforme bénéficient d'une vue d'ensemble des locataires pour la gestion opérationnelle.

Rapports au niveau du client

Chaque rapport, tableau de bord et exportation est limité au client. Des analyses inter-clients sont disponibles pour les propriétaires de plateformes. Des rapports personnalisés sont programmés.

Provisionnement des locataires

Déployez un nouvel environnement client en quelques minutes via le portail d'administration ou l'API partenaire. Utilisateurs, campagnes, règles de conformité et pools DID : tout est basé sur des modèles.

Séparation de facturation

Suivez l'utilisation, les minutes, les postes et les coûts de messagerie par utilisateur. Exportez les données de facturation. Intégrez le système à votre système de facturation via API.

Réglage de l'IA par locataire

La précision d'AMD s'améliore indépendamment pour chaque client grâce à des processus d'optimisation personnalisés. Les retours de chaque client contribuent à améliorer les performances de son propre modèle.

Options en marque blanche

Exploitez DialerBee sous votre marque avec un domaine, un logo et des couleurs personnalisés. Personnalisation de la marque par locataire pour les déploiements revendeurs.

Spécifications techniques

Sous le capot

Méthode d'isolement Sécurité au niveau des lignes (RLS) de PostgreSQL au niveau du moteur de base de données
Définition du périmètre des données Chaque requête est automatiquement limitée au locataire actuel.
Isolation de conformité Listes d'opposition au démarchage téléphonique par locataire, heures d'appel, consentement, limites de tentatives, profils réglementaires
Isolation de l'enregistrement Espace de stockage par locataire avec conservation indépendante et mise sous séquestre légale
Suivi de facturation Coûts d'utilisation, de minutes, de licences et de messagerie par locataire
Provisionnement Minutes via le portail d'administration ou l'API partenaire avec des configurations prédéfinies
RBAC Contrôle d'accès granulaire basé sur les rôles par locataire
Réglage de l'IA Amélioration du modèle par client pour les flux de travail de réglage AMD au niveau du locataire
Signalement Tableaux de bord et exportations par locataire ; vues inter-locataires pour les propriétaires de plateformes
Gestion des DID Pools de numéros DID par locataire avec évaluation et rotation isolées de la santé
Marque blanche Domaine, logo et couleurs personnalisés par locataire
accès API Gestion des locataires, provisionnement et facturation via API REST

Questions fréquentes sur la multilocation

Comment DialerBee assure-t-il l'isolation des locataires ?
DialerBee utilise la sécurité au niveau des lignes (RLS) de PostgreSQL pour garantir l'isolation des locataires au niveau des requêtes de la base de données. L'isolation est ainsi assurée par le moteur de base de données lui-même, et non uniquement par la logique applicative. Chaque requête est automatiquement limitée au locataire actuel. L'accès aux données entre locataires est architecturalement empêché.
Chaque locataire peut-il avoir des règles de conformité différentes ?
Oui. Chaque client dispose de listes d'opposition au démarchage téléphonique, de règles d'horaires d'appel, d'un suivi du consentement, de limites de tentatives et de profils réglementaires indépendants. Un client peut appliquer les règles TCPA tandis qu'un autre applique les règles TDRA sur la même plateforme, sans chevauchement ni interférence.
À quelle vitesse puis-je mettre en service un nouveau locataire ?
Il est possible de créer de nouveaux locataires en quelques minutes via le portail d'administration ou l'API partenaire. Des configurations prédéfinies pour les règles de conformité, les rôles utilisateurs, les paramètres de campagne et les listes de numéros DID accélèrent l'intégration. Les agents peuvent commencer à appeler dès le jour même.
L'enregistrement des appels est-il isolé entre les locataires ?
Oui. Les enregistrements d'appels sont stockés et accessibles individuellement pour chaque locataire, de manière totalement isolée. Chaque locataire dispose de politiques de conservation, de contrôles de mise sous séquestre et d'un système de surveillance du stockage qui lui sont propres. Aucun locataire ne peut accéder aux enregistrements d'un autre locataire via l'interface utilisateur ou l'API.
Comment fonctionne le réglage de l'IA par locataire ?
Les corrections apportées par les agents à l'AMD par l'IA sont intégrées aux flux de travail d'optimisation propres à chaque locataire. Ainsi, les retours de chaque locataire améliorent la précision de l'AMD pour ses opérateurs, régions et types de campagnes spécifiques, sans impacter les modèles des autres locataires.
Les propriétaires de plateformes peuvent-ils consulter les données inter-locataires ?
Oui. Les propriétaires et administrateurs de plateformes peuvent accéder aux analyses inter-locataires pour la gestion opérationnelle : utilisation totale, état de la plateforme et indicateurs agrégés. Cependant, les utilisateurs au niveau du locataire (administrateurs, superviseurs, agents) ne voient que les données de leur propre locataire.
La mutualisation fonctionne-t-elle avec les solutions en marque blanche ?
Oui. Les options en marque blanche permettent de personnaliser le domaine, le logo et les couleurs pour chaque client. C'est idéal pour les revendeurs de télécommunications qui souhaitent offrir à chaque client une expérience de marque personnalisée, même sur une infrastructure partagée.
Comment la facturation est-elle suivie par locataire ?
Les coûts d'utilisation, de minutes, de postes et de messagerie sont automatiquement suivis pour chaque utilisateur. Les données de facturation peuvent être exportées pour la facturation ou intégrées à votre système de facturation via API. Les coûts de chaque utilisateur sont intégralement imputés sans calcul manuel.

Conçu pour les BPO et les revendeurs

Réservez une démonstration et découvrez comment DialerBee isole chaque client grâce à une architecture multi-tenant de niveau entreprise.

View full site in English →