Was ist eine Multi-Tenant-Architektur?

Mandantenfähigkeit ist das Design, das Software as a Service wirtschaftlich möglich macht. Statt für jeden Kunden eine eigene Kopie der Anwendung aufzusetzen, bedient eine Installation alle, und die Trennung zwischen ihnen wird in Software durchgesetzt. Upgrade-Pfad, Betriebsaufwand und Kosten pro Kunde verbessern sich dadurch erheblich. Der Preis: Isolation wird zu einer Eigenschaft, die Sie aufbauen und verteidigen müssen, statt sie von der Hardware geschenkt zu bekommen.

Für eine Contact-Center-Plattform steht ungewöhnlich viel auf dem Spiel, denn es geht um Gesprächsaufzeichnungen, Kundenkontaktlisten, Einwilligungsnachweise und Sperrlisten. Ein BPO, der konkurrierende Kunden auf einer Plattform betreibt, ist vertraglich und oft auch regulatorisch verpflichtet, sie getrennt zu halten – ein Datenabfluss ist dann keine Unannehmlichkeit, sondern ein Vorfall.

Wo die Isolation durchgesetzt werden sollte

Die schwächste verbreitete Umsetzung legt die Grenze in den Anwendungscode: Jede Abfrage filtert nach Mandant, und die Korrektheit hängt davon ab, dass jeder Entwickler jedes Mal daran denkt. Das funktioniert, bis eine Abfrage es nicht tut – und nichts macht den Fehler sichtbar, bis jemand Daten sieht, die er nicht sehen sollte. Der stärkere Ansatz verlagert die Durchsetzung in die Datenbank, sodass die Richtlinie an den Daten hängt statt am Code, der sie liest, und eine Abfrage ohne Mandantenfilter nichts statt alles zurückgibt. Bei der Bewertung einer Plattform lautet die nützliche Frage daher nicht, ob Mandanten isoliert sind, sondern auf welcher Ebene.

Was pro Mandant unterschiedlich sein muss

• Daten und Benutzer. Kampagnen, Kontakte, Aufzeichnungen und Konten – so abgegrenzt, dass ein Benutzer nur innerhalb seines Mandanten existiert.
• Compliance-Konfiguration. Sperrlisten, Anrufzeitfenster und Einwilligungsregeln, da Mandanten unter unterschiedlichen Regelwerken arbeiten.
• Aufbewahrung. Aufbewahrung von Aufzeichnungen und Transkripten nach der eigenen Richtlinie jedes Mandanten, mit verfügbarem Legal Hold.
• Rufnummern. Eine Anruferkennung, die exklusiv einem Mandanten gehört, und ein Nebenstellenbereich, der nicht mit dem eines anderen kollidiert.
• Branding und Sprache. Die Oberfläche, die die Benutzer jedes Mandanten sehen, einschließlich ihrer Standardsprache.
• Abrechnung und Verbrauchsmessung. Nutzung, die pro Mandant zuordenbar ist, statt in einer Gesamtsumme zu verschwinden.

So setzt DialerBee Mandantenfähigkeit um

Das von DialerBee entwickelte mandantenfähige Architektur gibt jedem Mandanten isolierte Daten, durchgesetzt per PostgreSQL Row-Level-Security auf Datenbankebene; unabhängige Compliance-Regeln für Do-Not-Call-Listen, Anrufzeiten und Einwilligungsnachverfolgung; getrennte Gesprächsaufzeichnungen mit Speicherung pro Mandant, unabhängiger Aufbewahrung und Legal Hold; Abrechnung pro Mandant mit getrennter Erfassung von Nutzung, Minuten und Arbeitsplätzen; rollenbasierte Zugriffskontrolle, die Agenten und Supervisoren auf ihren Mandanten beschränkt; KI-Feinabstimmung pro Mandant und die Bereitstellung neuer Mandanten in Minuten über das Admin-Portal oder die API. Verfügbar in 11 Sprachen mit Standardsprachen pro Mandant.

Die Grenze zieht sich durch die gesamte Plattform, statt an der Datenbank zu enden. Jedes Dashboard und jeder Bericht in Analysen ist auf den aktuellen Mandanten beschränkt: BPO-Kunden sehen nur ihre eigenen Daten, während Plattformbetreiber mandantenübergreifende Analysen nutzen können, und die Mandantengrenzen werden auf Datenbankebene durchgesetzt. Eine Anrufer-ID gehört exklusiv einem Mandanten – das verhindert, dass eine Nummer, für die Sie verantwortlich sind, bei Anrufen anderer erscheint –, und jeder Mandant erhält eigene Anrufer-ID-Pools mit getrennten Rotationsregeln und eigenem Reporting. Transkriptdaten werden pro Mandant per Row-Level-Security isoliert gespeichert, mit pro Mandant konfigurierbarer Aufbewahrung. In White-Label -Umgebungen verwaltet ein Partner-Admin die Mandanten, die er anlegt, und der Onboarding-Assistent legt für jeden Mandanten einen eigenen Nebenstellenbereich und eigene Anrufer-IDs fest – denn Standardwerte kollidieren, und ein gemeinsamer Trunk ist keine Anrufer-ID.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Multi-Tenant und Single-Tenant?

Bei einer Single-Tenant-Bereitstellung erhält jeder Kunde eine eigene Instanz der Software und oft eine eigene Infrastruktur. Bei einer Multi-Tenant-Bereitstellung teilen sich die Kunden Infrastruktur und Code und werden durch Anwendung und Datenbank getrennt statt durch eigene Kopien. Multi-Tenancy ist günstiger im Betrieb und beim Upgrade; Single-Tenancy bietet physische Trennung zu deutlich höheren Kosten pro Kunde.

Was ist Row-Level-Security?

Eine Datenbankfunktion, die einer Tabelle eine Richtlinie zuordnet, sodass eine Abfrage nur die Zeilen zurückgeben kann, die der aktuelle Mandant sehen darf. Das ist wichtig, denn die Alternative – in jeder Abfrage der Anwendung nach Mandant zu filtern – hängt davon ab, dass jeder Entwickler jedes Mal daran denkt. Die Durchsetzung auf Datenbankebene bedeutet: Eine Abfrage, die den Filter vergisst, liefert nichts statt alles.

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

Es bedeutet, dass sie in gemeinsamer Infrastruktur mit durchgesetzten Grenzen gespeichert werden – nicht, dass jemand anderes darauf zugreifen kann. Die praktische Frage an einen Anbieter lautet nicht, ob Tabellen geteilt werden, sondern wo die Isolation durchgesetzt wird. Isolation, die nur im Anwendungscode umgesetzt ist, ist eine schwächere Antwort als Isolation, die die Datenbank durchsetzt.

Warum braucht jeder Mandant einen eigenen Nebenstellenbereich und eigene Anrufer-IDs?

Weil Standardwerte kollidieren. Zwei Mandanten, die mit demselben Nebenstellenbereich angelegt oder auf denselben Trunk gelegt werden, erzeugen fehlgeleitete Anrufe und eine Anruferkennung, die zum falschen Unternehmen gehört. Wer jedem Mandanten bei der Einrichtung einen eigenen Bereich und eigene Nummern gibt, verhindert eine ganze Klasse von Problemen, die später unangenehm zu diagnostizieren sind.

Was sollte pro Mandant konfigurierbar sein?

Alles, was sich zwischen den Unternehmen auf der Plattform unterscheidet – im Contact Center ist das fast alles: Compliance-Regeln, Anrufzeiten, Sperrlisten, Aufbewahrungsfristen, Standardsprachen, Branding, Rufnummern und Abrechnung. Eine Einstellung, die nur global sein kann, wird früher oder später für irgendjemanden falsch sein.

Verwandte Begriffe: White-Label-Contact-Center-Plattform, BPO-Contact-Center, Einwilligungsmanagement, Anrufer-ID und Local Presence und DID.