Was ist Multi-Tenant-Architektur?

Mandantenfähigkeit ist die Designgrundlage für wirtschaftliche Software-as-a-Service (SaaS). Anstatt für jeden Kunden eine separate Anwendungskopie bereitzustellen, wird eine einzige Installation für alle Kunden verwendet, und die Trennung zwischen den Kunden wird softwareseitig realisiert. Dadurch verbessern sich Upgrade-Prozesse, der operative Aufwand und die Kosten pro Kunde erheblich. Im Gegenzug wird die Isolation zu einer aktiv aufgebauten und geschützten Eigenschaft, anstatt eine selbstverständliche Hardware-Lösung zu sein.

Für eine Contact-Center-Plattform steht besonders viel auf dem Spiel, da es sich um Anrufaufzeichnungen, Kundenkontaktlisten, Einwilligungserklärungen und Sperrlisten handelt. Ein BPO-Unternehmen, das mehrere Kunden auf einer Plattform betreut, ist vertraglich und oft auch gesetzlich verpflichtet, diese Daten voneinander zu trennen. Ein Datenleck ist daher keine bloße Unannehmlichkeit, sondern ein schwerwiegender Vorfall.

Wo Isolation durchgesetzt werden sollte

Die schwächste gängige Implementierung platziert die Grenze im Anwendungscode: Jede Abfrage filtert nach Mandant, und die Korrektheit hängt davon ab, dass sich jeder Entwickler jedes Mal daran erinnert. Das funktioniert, solange eine Abfrage nicht funktioniert, und der Fehler wird erst sichtbar, wenn jemand Daten sieht, die er nicht sehen sollte. Der robustere Ansatz verlagert die Durchsetzung in die Datenbank, sodass die Richtlinie an die Daten und nicht an den Code, der sie liest, gebunden ist. Eine Abfrage, die den Mandantenfilter weglässt, liefert daher keine Ergebnisse anstatt aller. Bei der Bewertung einer Plattform ist die entscheidende Frage nicht, ob Mandanten isoliert sind, sondern auf welcher Ebene.

Was muss je nach Mieter variieren?

• Daten und Nutzer. Kampagnen, Kontakte, Aufzeichnungen und Konten, so dass ein Benutzer nur innerhalb seines Mandanten existiert.
• Konformitätskonfiguration. Sperrlisten, Anruffenster und Zustimmungsregeln, da die Mieter unter verschiedenen Regimen arbeiten.
• Zurückbehaltung. Aufzeichnung und Protokollierung gemäß der jeweiligen Versicherungspolice des Mieters, mit der Möglichkeit der rechtlichen Aufbewahrung.
• Zahlen. Die Anruferidentität gehört ausschließlich einem Mieter, und der Nebenstellenbereich kollidiert nicht mit dem eines anderen Mieters.
• Markenbildung und Sprache. Die Benutzeroberfläche, die die Nutzer jedes Mandanten sehen, einschließlich ihrer Standardsprache.
• Abrechnung und Messung. Die Nutzung wird jedem einzelnen Mieter einzeln zugeordnet und nicht zu einer Gesamtsumme zusammengefasst.

Wie DialerBee Mandantenfähigkeit implementiert

DialerBee's Multi-Tenant-Architektur Jeder Mandant erhält isolierte Daten, die durch PostgreSQL-Zeilenebenensicherheit auf Datenbankebene gewährleistet werden. Unabhängige Compliance-Regeln umfassen Sperrlisten, Anrufzeiten und Einwilligungserfassung, separate Anrufaufzeichnungen mit mandantenspezifischer Speicherung, unabhängige Aufbewahrungs- und Aufbewahrungspflichten, mandantenspezifische Abrechnung mit separater Erfassung von Nutzung, Minuten und Lizenzen, rollenbasierte Zugriffskontrolle zur Zuordnung von Agenten und Vorgesetzten zu ihrem jeweiligen Mandanten, mandantenspezifische KI-Optimierung und Mandantenbereitstellung innerhalb von Minuten über das Admin-Portal oder die API. Die Lösung ist in 11 Sprachen mit mandantenspezifischen Standardsprachen verfügbar.

Die Grenze wird durch die gesamte Plattform hindurchgeführt und endet nicht an der Datenbank. Jedes Dashboard und jeder Bericht in Analysen Die Daten sind auf den jeweiligen Mandanten beschränkt, sodass BPO-Kunden nur ihre eigenen Daten sehen, während Plattformbetreiber auf mandantenübergreifende Analysen zugreifen können. Mandantengrenzen werden auf Datenbankebene durchgesetzt. Die Anrufer-ID ist exklusiv einem Mandanten zugeordnet, wodurch verhindert wird, dass eine Ihnen zugeordnete Nummer bei Anrufen anderer Nutzer erscheint. Jeder Mandant verfügt über eigene Anrufer-ID-Pools mit isolierten Rotationsregeln und Berichtsfunktionen. Transkriptdaten werden mandantenspezifisch isoliert mittels Zeilenebenensicherheit gespeichert, wobei die Aufbewahrungsdauer pro Mandant konfigurierbar ist. White-Label-Produkt Bei Bereitstellungen besitzt ein Partneradministrator die von ihm erstellten Mandanten, und der Onboarding-Assistent legt für jeden Mandanten einen eigenen Nebenstellenbereich und eigene Anrufer-IDs fest, da Standardwerte kollidieren und ein gemeinsam genutzter Trunk keine Anrufer-ID ist.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen Mehrmieter- und Einzelmieter-Wohnungen?

Bei einer Single-Tenant-Umgebung erhält jeder Kunde eine eigene Softwareinstanz und oft auch eine eigene Infrastruktur. Bei einer Multi-Tenant-Umgebung teilen sich die Kunden die Infrastruktur und den Code und sind nicht durch separate Kopien, sondern durch die Anwendung und die Datenbank voneinander getrennt. Multi-Tenant-Umgebungen sind kostengünstiger im Betrieb und bei Upgrades; Single-Tenant-Umgebungen bieten zwar eine physische Trennung, sind aber pro Kunde deutlich teurer.

Was ist Zeilenebenensicherheit?

Eine Datenbankfunktion, die einer Tabelle eine Richtlinie zuweist, sodass eine Abfrage nur die Zeilen zurückgibt, auf die der aktuelle Mandant Zugriff hat. Dies ist wichtig, da die Alternative – das Filtern nach Mandant bei jeder einzelnen Abfrage der Anwendung – voraussetzt, dass jeder Entwickler dies jedes Mal berücksichtigt. Die Durchsetzung dieser Richtlinie auf Datenbankebene führt dazu, dass eine Abfrage, die den Filter nicht beachtet, keine Ergebnisse liefert, anstatt alle.

Bedeutet Mandantenfähigkeit, dass meine Daten mit denen anderer Kunden vermischt werden?

Das bedeutet, dass die Daten in einer gemeinsam genutzten Infrastruktur mit festgelegten Grenzen gespeichert sind, nicht, dass jeder darauf zugreifen kann. Die entscheidende Frage an den Anbieter ist nicht, ob Tabellen gemeinsam genutzt werden, sondern wo die Isolation gewährleistet ist. Eine Isolation, die ausschließlich im Anwendungscode implementiert ist, ist weniger aussagekräftig als eine durch die Datenbank selbst sichergestellte Isolation.

Warum benötigt jeder Mieter einen eigenen Nebenstellenbereich und eigene Anrufer-IDs?

Weil es zu Konflikten mit den Standardeinstellungen kommt. Wenn zwei Mandanten mit demselben Nebenstellenbereich oder demselben Trunk ausgestattet sind, kommt es zu Fehlleitungen von Anrufen und die Anrufer-ID gehört zum falschen Unternehmen. Indem man jedem Mandanten bei der Einrichtung einen eigenen Bereich und eigene Rufnummern zuweist, lässt sich eine Problemklasse vermeiden, deren Diagnose später sehr aufwendig ist.

Was sollte pro Mandant konfigurierbar sein?

Alles, was sich zwischen den Unternehmen, die die Plattform nutzen, unterscheidet – und in einem Contact Center betrifft das fast alles: Compliance-Regeln, Erreichbarkeitszeiten, Sperrlisten, Aufbewahrungsfristen, Standardsprachen, Branding, Rufnummern und Abrechnung. Eine Einstellung, die nur global gelten kann, ist zwangsläufig für jeden einzelnen Nutzer falsch.

Verwandte Begriffe: White-Label-Kontaktcenter-Plattform, BPO-Kontaktzentrum, Einwilligungsmanagement, Anrufer-ID und lokale Präsenz Und DID.