Cos'è l'architettura multi-tenant?

Il multi-tenancy è il modello che rende economicamente possibile il software as a service. Invece di installare una copia separata dell'applicazione per ogni cliente, un'unica installazione li serve tutti, e la separazione tra loro è garantita via software. Percorso di aggiornamento, carico operativo e costo per cliente migliorano tutti in modo drastico. Il compromesso è che l'isolamento diventa una proprietà da costruire e difendere, invece di qualcosa che l'hardware ti dà gratis.

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

Dove va imposto l'isolamento

L'implementazione comune più debole colloca il confine nel codice applicativo: ogni query filtra per tenant e la correttezza dipende dal fatto che ogni sviluppatore se ne ricordi ogni volta. Funziona finché una query non lo fa, e niente fa emergere l'errore finché qualcuno non vede dati che non dovrebbe vedere. L'approccio più robusto sposta l'applicazione delle regole nel database, così la policy è legata ai dati e non al codice che li legge, e una query che omette il filtro per tenant non restituisce nulla invece di restituire tutto. Quando valuti una piattaforma, la domanda utile non è se i tenant sono isolati, ma a quale livello.

Cosa deve variare per tenant

• Dati e utenti. Campagne, contatti, registrazioni e account, delimitati in modo che un utente esista solo all'interno del proprio tenant.
• Configurazione della conformità. Liste di esclusione, fasce orarie di chiamata e regole di consenso, perché i tenant operano sotto regimi diversi.
• Conservazione. Conservazione di registrazioni e trascrizioni secondo la policy di ciascun tenant, con legal hold disponibile.
• Numeri. Un'identità del chiamante che appartiene in esclusiva a un solo tenant, e un intervallo di interni che non entra in conflitto con quello di un altro.
• Branding e lingua. L'interfaccia che vedono gli utenti di ciascun tenant, compresa la lingua predefinita.
• Fatturazione e misurazione dei consumi. Consumi attribuibili a ciascun tenant invece che aggregati in un unico totale.

Come DialerBee implementa il multi-tenancy

In DialerBee, il architettura multi-tenant offre a ogni tenant dati isolati, garantiti dalla row-level security di PostgreSQL a livello di database, regole di conformità indipendenti per liste di non chiamare, orari di chiamata e tracciamento del consenso, registrazioni separate con archiviazione per tenant, conservazione e legal hold indipendenti, fatturazione per tenant che tiene traccia separata di consumi, minuti e postazioni, controllo degli accessi basato sui ruoli che limita agenti e supervisori al proprio tenant, ottimizzazione dell'IA per tenant e provisioning di un tenant in pochi minuti tramite il portale di amministrazione o l'API. È disponibile in 11 lingue con lingua predefinita per tenant.

Il confine si estende al resto della piattaforma invece di fermarsi al database. Ogni dashboard e report in analisi è limitato al tenant corrente, così i clienti di un BPO vedono solo i propri dati mentre i gestori della piattaforma possono accedere ad analisi trasversali tra tenant, e i confini tra tenant sono garantiti a livello di database. La proprietà di un caller ID è esclusiva di un solo tenant, il che impedisce a un numero di cui sei responsabile di comparire sulle chiamate di qualcun altro, e ogni tenant ha i propri pool di caller ID con regole di rotazione e report isolati. I dati delle trascrizioni sono archiviati con isolamento per tenant tramite row-level security, con conservazione configurabile per tenant. Nelle installazioni white-label un amministratore partner gestisce i tenant che crea, e la procedura guidata di onboarding imposta per ogni tenant il proprio intervallo di interni e i propri caller ID, perché le impostazioni predefinite entrano in conflitto e un trunk condiviso non è un caller ID.

Domande frequenti

Che differenza c'è tra multi-tenant e single-tenant?

In un'installazione single-tenant ogni cliente ha la propria istanza del software e spesso la propria infrastruttura. In un'installazione multi-tenant i clienti condividono infrastruttura e codice, e sono separati dall'applicazione e dal database invece che da copie distinte. Il multi-tenancy costa meno da gestire e da aggiornare; il single-tenancy offre una separazione fisica a un costo per cliente molto più alto.

Cos'è la row-level security (sicurezza a livello di riga)?

Una funzionalità del database che associa una policy a una tabella, così una query può restituire solo le righe che il tenant corrente ha diritto di vedere. È importante perché l'alternativa, filtrare per tenant in ogni query eseguita dall'applicazione, dipende dal fatto che ogni sviluppatore se ne ricordi ogni volta. Imporla a livello di database significa che una query che dimentica il filtro non restituisce nulla invece di restituire tutto.

Multi-tenancy significa che i miei dati sono mescolati con quelli di altri clienti?

Significa che sono archiviati in un'infrastruttura condivisa con confini garantiti, non che qualcun altro possa raggiungerli. La domanda pratica da porre a un fornitore non è se le tabelle sono condivise, ma dove viene imposto l'isolamento. Un isolamento implementato solo nel codice applicativo è una risposta più debole di un isolamento imposto dal database.

Perché ogni tenant ha bisogno di un proprio intervallo di interni e di propri caller ID?

Perché le impostazioni predefinite entrano in conflitto. Due tenant configurati con lo stesso intervallo di interni o puntati sullo stesso trunk producono chiamate instradate male e un'identità del chiamante che appartiene all'azienda sbagliata. Assegnare a ogni tenant il proprio intervallo e i propri numeri al momento del provisioning previene un'intera categoria di problemi spiacevoli da diagnosticare in seguito.

Cosa dovrebbe essere configurabile per tenant?

Tutto ciò che differisce tra le aziende che usano la piattaforma, che in un contact center è quasi tutto: regole di conformità, orari di chiamata, liste di esclusione, periodi di conservazione, lingua predefinita, branding, numeri e fatturazione. Un'impostazione che può essere solo globale è un'impostazione che prima o poi sarà sbagliata per qualcuno.

Termini correlati: piattaforma white-label per contact center, contact center BPO, gestione del consenso, caller ID e presenza locale e DID.