Un sistema per cliente, oppure una piattaforma per ogni cliente. L'architettura determina la scalabilità.

Un dialer multi-tenant serve numerosi clienti (tenant) da un'unica piattaforma condivisa. Ogni tenant visualizza solo le proprie campagne, contatti, agenti, registrazioni e report, ma tutti i tenant operano sulla stessa applicazione sottostante. L'isolamento è garantito a livello logico, non tramite hardware separato per ciascun cliente. Se implementato correttamente, un tenant non potrà mai visualizzare o accedere ai dati di un altro tenant.

DialerBee è progettato per essere multi-tenant e garantisce l'isolamento a livello di dati. Ogni record ha un'identità di tenant e l'accesso è limitato in modo che le query possano restituire solo righe appartenenti al tenant richiedente: un approccio comunemente implementato con meccanismi di database come la sicurezza a livello di riga di PostgreSQL. Ciò significa che la separazione tra i client è garantita dalla piattaforma dati stessa, e non lasciata alla sola gestione del codice applicativo.

Per un BPO o un rivenditore, il vantaggio operativo è decisivo. L'onboarding di un nuovo cliente è una fase di configurazione, non un progetto infrastrutturale. Aggiornamenti, patch di sicurezza e nuove funzionalità vengono distribuiti contemporaneamente a tutti i tenant. Si ottiene un'unica piattaforma da monitorare e gestire, mentre ogni cliente usufruisce di un'area di lavoro completamente separata e personalizzabile con il proprio marchio. Questo è ciò che rende l'architettura multi-tenant la soluzione ideale per chiunque gestisca chiamate in uscita per più clienti. Vedi il nostro funzionalità multi-tenant per la spiegazione completa.

L'architettura multi-tenant è la scelta predefinita ideale per le organizzazioni che gestiscono chiamate in uscita verso numerosi clienti, ma l'architettura single-tenant non è obsoleta. Esistono situazioni in cui un'istanza dedicata rimane la soluzione migliore.

Se un singolo cliente opera in base a vincoli di residenza dei dati o contrattuali che richiedono un'infrastruttura fisicamente dedicata, una distribuzione a tenant singolo può soddisfare direttamente tale requisito. Lo stesso vale quando un cliente necessita di una personalizzazione approfondita e su misura del sistema sottostante, che non sarebbe appropriata per una piattaforma condivisa.

Le organizzazioni che servono un solo cliente, o che sono esse stesse gli unici utenti finali, traggono scarso vantaggio dal multi-tenancy, poiché non esiste un secondo tenant da cui isolarsi. In questi casi, la semplicità operativa di un singolo ambiente può superare di gran lunga i vantaggi di una piattaforma condivisa.

Per tutti gli altri — i BPO, i rivenditori di telecomunicazioni e le agenzie che aggiungono regolarmente clienti e necessitano di separazione per cliente senza costi aggiuntivi per cliente — una piattaforma multi-tenant ben progettata offre l'isolamento di sistemi separati con l'efficienza di un unico sistema. Questo è l'equilibrio su cui si basa la progettazione di DialerBee, ed è per questo che il nostro Soluzione BPO E piattaforma di composizione automatica white-label sono costruiti su fondamenta multi-tenant.

DialerBee è multi-tenant per sua natura. L'isolamento è imposto a livello di database con la sicurezza a livello di riga di PostgreSQL, quindi ogni query è limitata al tenant richiedente e l'accesso tra tenant è impedito dal motore del database anziché dalla logica applicativa. Ogni tenant ha le proprie regole di conformità, le proprie registrazioni con controlli indipendenti di conservazione e blocco legale, la propria attribuzione di utilizzo e fatturazione e il proprio marchio. I nuovi tenant vengono configurati in pochi minuti tramite il portale di amministrazione o l' API partner. I dettagli si trovano su pagina sull'architettura multi-tenant.

L'accesso è qualcosa che si può leggere da una griglia piuttosto che dedurre: una matrice di ruoli per tenant di 11 categorie di autorizzazione e 41 autorizzazioni, un registro di controllo che registra l'azione, l'utente e l'indirizzo IP da cui proviene, chiavi API con hash a riposo e con ambito al rispettivo tenant e amministratori partner che vedono solo i tenant di cui sono proprietari. Questo è trattato su sicurezza e accesso. Anche gli amministratori della piattaforma e dei partner ottengono un centro operativo con informazioni sullo stato del servizio, chiamate in tempo reale e tracciamento completo delle chiamate, mentre gli amministratori dei tenant vedono solo il proprio tenant.