Apa Itu Arsitektur Multi-Tenant?

Multi-tenancy adalah desain yang membuat software as a service (SaaS) layak secara ekonomi. Alih-alih menyiapkan salinan aplikasi terpisah untuk setiap pelanggan, satu deployment melayani semuanya, dan pemisahan di antara mereka ditegakkan oleh perangkat lunak. Jalur upgrade, beban operasional, dan biaya per pelanggan semuanya membaik secara drastis. Konsekuensinya, isolasi menjadi properti yang harus Anda bangun dan pertahankan, bukan sesuatu yang diberikan perangkat keras secara cuma-cuma.

Bagi platform pusat kontak, taruhannya sangat tinggi, karena datanya berupa rekaman panggilan, daftar kontak pelanggan, catatan persetujuan, dan daftar suppression. BPO yang menjalankan klien-klien yang saling bersaing di satu platform memiliki kewajiban kontraktual — dan sering kali regulasi — untuk memisahkan mereka, dan kebocoran bukan sekadar ketidaknyamanan, melainkan insiden.

Di Mana Isolasi Harus Ditegakkan

Implementasi umum yang paling lemah menempatkan batas di kode aplikasi: setiap query memfilter berdasarkan tenant, dan kebenarannya bergantung pada setiap developer yang selalu ingat melakukannya. Cara ini berhasil sampai ada satu query yang lupa, dan tidak ada yang memunculkan kesalahan itu sampai seseorang melihat data yang tidak seharusnya ia lihat. Pendekatan yang lebih kuat menempatkan penegakan di basis data, sehingga kebijakannya melekat pada data, bukan pada kode yang membacanya, dan query yang tidak menyertakan filter tenant tidak mengembalikan apa pun, bukan mengembalikan semuanya. Saat mengevaluasi platform, pertanyaan yang berguna bukanlah apakah tenant terisolasi, melainkan di lapisan mana isolasi itu ditegakkan.

Apa yang Harus Berbeda per Tenant

• Data dan pengguna. Kampanye, kontak, rekaman, dan akun dibatasi cakupannya sehingga setiap pengguna hanya ada di dalam tenant-nya sendiri.
• Konfigurasi kepatuhan. Daftar supresi, jendela waktu panggilan, dan aturan persetujuan, karena setiap tenant beroperasi di bawah rezim regulasi yang berbeda.
• Retensi. Retensi rekaman dan transkrip mengikuti kebijakan masing-masing tenant, dengan opsi legal hold.
• Nomor. Identitas penelepon yang eksklusif milik satu tenant, serta rentang ekstensi yang tidak bertabrakan dengan milik tenant lain.
• Branding dan bahasa. Tampilan yang dilihat pengguna setiap tenant, termasuk bahasa default mereka.
• Penagihan dan metering. Penggunaan yang dapat diatribusikan per tenant, bukan digabung menjadi satu total.

Cara DialerBee Menerapkan Multi-Tenancy

Di DialerBee, arsitektur multi-tenant memberi setiap tenant data terisolasi yang ditegakkan oleh row-level security PostgreSQL di lapisan basis data, aturan kepatuhan independen yang mencakup daftar jangan-hubungi (do-not-call), jam panggilan, dan pelacakan persetujuan, rekaman panggilan terpisah dengan penyimpanan per tenant, retensi dan legal hold independen, penagihan per tenant yang melacak penggunaan, menit, dan seat secara terpisah, kontrol akses berbasis peran (RBAC) yang membatasi agen dan supervisor pada tenant mereka, penyetelan AI per tenant, serta penyediaan tenant dalam hitungan menit melalui portal admin atau API. Tersedia dalam 11 bahasa dengan bahasa default per tenant.

Batas ini diteruskan ke seluruh platform, tidak berhenti di basis data. Setiap dasbor dan laporan di analitik dibatasi pada tenant yang sedang aktif, sehingga klien BPO hanya melihat data mereka sendiri, sementara pemilik platform dapat mengakses analitik lintas tenant, dan batas tenant ditegakkan di lapisan basis data. Kepemilikan caller ID bersifat eksklusif untuk satu tenant, dan inilah yang mencegah nomor yang menjadi tanggung jawab Anda muncul di panggilan pihak lain; setiap tenant juga mendapatkan pool caller ID sendiri dengan aturan rotasi dan pelaporan yang terisolasi. Data transkrip disimpan dengan isolasi per tenant menggunakan row-level security, dengan retensi yang dapat dikonfigurasi per tenant. Pada penerapan white-label , admin mitra memiliki tenant yang mereka buat, dan wizard onboarding menetapkan rentang ekstensi serta caller ID milik masing-masing tenant, karena pengaturan default saling bertabrakan dan trunk bersama bukanlah caller ID.

Pertanyaan yang Sering Diajukan

Apa perbedaan multi-tenant dan single-tenant?

Pada penerapan single-tenant, setiap pelanggan mendapatkan instance perangkat lunaknya sendiri dan sering kali juga infrastrukturnya sendiri. Pada penerapan multi-tenant, pelanggan berbagi infrastruktur dan kode, dan dipisahkan oleh aplikasi dan basis data, bukan dengan salinan terpisah. Multi-tenancy lebih murah untuk dijalankan dan di-upgrade; single-tenancy memberikan pemisahan fisik dengan biaya per pelanggan yang jauh lebih tinggi.

Apa itu row-level security?

Fitur basis data yang memasang kebijakan pada tabel sehingga sebuah kueri hanya dapat mengembalikan baris yang berhak dilihat oleh tenant saat ini. Ini penting karena alternatifnya, yaitu memfilter berdasarkan tenant di setiap kueri aplikasi, bergantung pada setiap developer yang harus selalu ingat setiap saat. Menegakkannya di lapisan basis data berarti kueri yang lupa memasang filter tidak mengembalikan apa pun, alih-alih mengembalikan semuanya.

Apakah multi-tenancy berarti data saya tercampur dengan data pelanggan lain?

Artinya data disimpan di infrastruktur bersama dengan batas yang ditegakkan, bukan berarti orang lain dapat mengaksesnya. Pertanyaan praktis untuk vendor bukanlah apakah tabelnya dipakai bersama, melainkan di mana isolasi ditegakkan. Isolasi yang hanya diterapkan dalam kode aplikasi adalah jawaban yang lebih lemah daripada isolasi yang ditegakkan oleh basis data.

Mengapa setiap tenant memerlukan rentang ekstensi dan caller ID sendiri?

Karena pengaturan default saling bertabrakan. Dua tenant yang disiapkan dengan rentang ekstensi yang sama atau diarahkan ke trunk yang sama akan menghasilkan panggilan yang salah rute dan identitas penelepon milik bisnis yang salah. Memberi setiap tenant rentang dan nomornya sendiri saat penyediaan mencegah satu kelas masalah yang menyulitkan untuk didiagnosis di kemudian hari.

Apa saja yang sebaiknya dapat dikonfigurasi per tenant?

Segala hal yang berbeda di antara bisnis yang memakai platform, dan di pusat kontak itu mencakup hampir semuanya: aturan kepatuhan, jam panggilan, daftar supresi, periode retensi, bahasa default, branding, nomor, dan penagihan. Pengaturan yang hanya bisa bersifat global adalah pengaturan yang pada akhirnya akan keliru bagi seseorang.

Istilah terkait: platform contact center white-label, Pusat kontak BPO, consent management, caller ID dan local presence dan DID.