Che cos'è l'architettura multi-tenant?

L'architettura multi-tenant è ciò che rende economicamente sostenibile il software come servizio (SaaS). Invece di installare una copia separata dell'applicazione per ogni cliente, un'unica implementazione serve tutti, e la separazione tra di essi è garantita a livello software. Il percorso di aggiornamento, l'onere operativo e il costo per cliente migliorano drasticamente. Il compromesso è che l'isolamento diventa una proprietà da costruire e proteggere, anziché una caratteristica intrinseca dell'hardware.

Per una piattaforma di contact center, la posta in gioco è insolitamente alta, perché i dati coinvolti includono registrazioni delle chiamate, elenchi di contatti dei clienti, registri dei consensi e liste di esclusione. Un'azienda di BPO che gestisce clienti concorrenti su un'unica piattaforma ha l'obbligo contrattuale, e spesso anche normativo, di mantenerli separati, e una fuga di dati non è un semplice inconveniente, ma un vero e proprio incidente.

Dove dovrebbe essere imposto l'isolamento

L'implementazione più debole comunemente adottata pone il limite nel codice dell'applicazione: ogni query filtra per tenant e la correttezza dipende dal fatto che ogni sviluppatore se ne ricordi ogni volta. Funziona finché una query non fallisce e l'errore non emerge finché qualcuno non visualizza dati che non dovrebbe. L'approccio più robusto sposta l'applicazione delle policy nel database, in modo che la policy sia associata ai dati anziché al codice che li legge, e una query che omette il filtro per tenant non restituisce nulla invece di restituire tutto. Quando si valuta una piattaforma, la domanda utile non è se i tenant sono isolati, ma a quale livello.

Cosa deve variare per ogni tenant

• Dati e utenti. Campagne, contatti, registrazioni e account, strutturati in modo che un utente esista solo all'interno del proprio tenant.
• Configurazione di conformità. Liste di esclusione, finestre di chiamata e regole di consenso, poiché gli tenant operano in base a regimi differenti.
• Ritenzione. La registrazione e la conservazione delle trascrizioni sono a discrezione di ciascun tenant, con possibilità di blocco legale.
• Numeri. Identità del chiamante appartenente esclusivamente a un singolo tenant e un intervallo di interni che non si sovrappone a quello di altri.
• Marchio e linguaggio. L'interfaccia visualizzata dagli utenti di ciascun tenant, inclusa la lingua predefinita.
• Fatturazione e misurazione. I consumi sono attribuibili a ciascun tenant anziché essere aggregati in un unico totale.

Come DialerBee implementa il multi-tenancy

DialerBee's architettura multi-tenant Fornisce a ciascun tenant dati isolati protetti dalla sicurezza a livello di riga di PostgreSQL a livello di database, regole di conformità indipendenti che coprono liste di non chiamare, orari di chiamata e tracciamento del consenso, registrazioni di chiamate separate con archiviazione per tenant, conservazione e blocco legale indipendenti, tracciamento della fatturazione per tenant di utilizzo, minuti e postazioni separatamente, controllo degli accessi basato sui ruoli che assegna agenti e supervisori al proprio tenant, ottimizzazione dell'IA per tenant e provisioning del tenant in pochi minuti tramite il portale di amministrazione o l' API. È disponibile in 11 lingue con impostazioni linguistiche predefinite per ciascun tenant.

Il confine viene esteso al resto della piattaforma anziché fermarsi al database. Ogni dashboard e report in analisi è limitato al tenant corrente, quindi i clienti BPO vedono solo i propri dati mentre i proprietari della piattaforma possono accedere alle analisi tra tenant e i confini dei tenant vengono applicati a livello di database. La proprietà dell'ID chiamante è esclusiva di un tenant, il che impedisce che un numero di cui sei responsabile appaia nelle chiamate di qualcun altro, e ogni tenant ottiene i propri pool di ID chiamante con regole di rotazione e reporting isolati. I dati delle trascrizioni vengono archiviati con isolamento per tenant utilizzando la sicurezza a livello di riga, con conservazione configurabile per tenant. etichetta bianca Nelle implementazioni, un amministratore partner è proprietario dei tenant che crea e la procedura guidata di onboarding imposta per ogni tenant il proprio intervallo di interni e i propri ID chiamante, poiché le impostazioni predefinite entrano in conflitto e un trunk condiviso non è un ID chiamante.

Domande frequenti

Qual è la differenza tra multi-tenant e single-tenant?

In un'implementazione single-tenant, ogni cliente ottiene la propria istanza del software e spesso anche la propria infrastruttura. In un'implementazione multi-tenant, i clienti condividono l'infrastruttura e il codice, e sono separati dall'applicazione e dal database anziché da copie separate. Il multi-tenancy è più economico da gestire e aggiornare; il single-tenant offre una separazione fisica a un costo per cliente decisamente superiore.

Che cos'è la sicurezza a livello di riga?

Una funzionalità del database che associa una policy a una tabella in modo che una query possa restituire solo le righe che l'utente corrente ha il diritto di visualizzare. È importante perché l'alternativa, ovvero filtrare per utente in ogni query eseguita dall'applicazione, dipende dalla capacità di ogni sviluppatore di ricordare tale policy ogni volta. Applicarla a livello di database significa che una query che non applica il filtro non restituirà nulla, anziché visualizzare tutte le righe.

La funzionalità multi-tenant implica che i miei dati vengano mescolati con quelli di altri clienti?

Significa che i dati sono archiviati in un'infrastruttura condivisa con confini ben definiti, non che chiunque altro possa accedervi. La domanda pratica da porre a un fornitore non è se le tabelle sono condivise, ma dove viene applicato l'isolamento. Un isolamento implementato solo nel codice dell'applicazione è una soluzione meno efficace rispetto a un isolamento imposto dal database.

Perché ogni tenant ha bisogno di un proprio intervallo di interni e di un proprio identificativo del chiamante?

Perché le impostazioni predefinite possono entrare in conflitto. Due tenant configurati con lo stesso intervallo di interni o indirizzati allo stesso trunk generano chiamate instradate in modo errato e l'identificazione del chiamante appartiene all'azienda sbagliata. Assegnare a ciascun tenant un proprio intervallo e i propri numeri al momento della configurazione previene una tipologia di problemi che risultano difficili da diagnosticare in seguito.

Quali elementi dovrebbero essere configurabili per ciascun tenant?

Qualsiasi elemento che differisce tra le aziende che utilizzano la piattaforma, e in un contact center si tratta praticamente di tutto: regole di conformità, orari di chiamata, liste di esclusione, periodi di conservazione, impostazioni della lingua, branding, numeri e fatturazione. Un'impostazione che può essere solo globale è un'impostazione che prima o poi risulterà errata per qualcuno.

Termini correlati: piattaforma white-label per contact center, Centro di contatto BPO, gestione del consenso, identificativo del chiamante e presenza locale E DID.