Saltar al contenido

Arquitectura multi-tenant

Contact center multi-tenant: cada cliente aislado, una sola plataforma.

Reglas de cumplimiento, grabaciones, usuarios y facturación separados por cliente. RLS de PostgreSQL aplicado en la capa de base de datos. Aprovisione nuevos tenants en minutos.

Prueba gratuita de 14 días · crédito de IA gratuito para probar el agente de voz con IA · sin tarjeta

El panel de administración DialerBee para un inquilino, que muestra los agentes activos de ese inquilino, la tendencia de la tasa de conexión, las disposiciones y la combinación de idiomas, de forma aislada de otros inquilinos.

El panel de DialerBee: gestione campañas, agentes y reportes por tenant desde un solo lugar.

Creado por BroadNet, 22 años en telecomunicaciones 11 idiomas, adaptado a dialectos BYOC: sus operadores, sin ataduras Controles que apoyan el cumplimiento (TCPA, RGPD, TDRA)

Respuesta rápida

¿Qué es la arquitectura multi-tenant de DialerBee? La arquitectura multi-tenant de DialerBee ofrece aislamiento total de clientes para BPO, revendedores de telecomunicaciones y organizaciones que gestionan programas de varios clientes. Cada tenant tiene datos aislados (aplicado mediante Row-Level Security de PostgreSQL en la capa de base de datos), reglas de cumplimiento independientes (listas DNC, horarios de llamada, seguimiento del consentimiento), grabaciones de llamadas separadas (almacenamiento por tenant con retención y retención legal independientes), facturación por tenant (uso, minutos y puestos medidos por separado), control de acceso basado en roles (agentes y supervisores limitados a su tenant), ajuste de IA por tenant (la precisión del AMD mejora de forma independiente en cada tenant) y aprovisionamiento de tenants en minutos desde el portal de administración o la API. Disponible en 11 idiomas con idioma predeterminado por tenant.

El problema

Los dialers de un solo tenant no escalan para los BPO

Los BPO y los revendedores de telecomunicaciones gestionan programas de varios clientes en una sola plataforma. Cada cliente tiene requisitos de cumplimiento, listas DNC, políticas de grabación y facturación distintos. Tener una instancia de dialer separada para cada cliente es caro, complejo de operar y no escala. Pero tener a todos los clientes en una instancia compartida sin un aislamiento adecuado crea un riesgo inaceptable: datos de un cliente que se filtran a otro, reglas de cumplimiento de un cliente que afectan las campañas de otro.

La mayoría de los dialers solo ofrecen grupos de usuarios básicos , no un verdadero multi-tenant. Los usuarios se pueden organizar en grupos, pero los datos subyacentes son compartidos. Los reportes quizá se puedan filtrar por grupo, pero el control se aplica en la capa de aplicación, no en la base de datos. Un error, un filtro mal configurado o una consulta de API mal escrita podría exponer los datos de un cliente a otro. Para los BPO que manejan datos regulados —financieros, de salud o datos personales—, este nivel de aislamiento es insuficiente.

Un verdadero multi-tenant significa aislamiento en cada capa: consultas a la base de datos limitadas por tenant, grabaciones almacenadas por separado, reglas de cumplimiento configurables de forma independiente, facturación medida por cliente y controles de acceso que hacen que el acceso entre tenants sea imposible por arquitectura, no solo improbable.

N instancias
Sin multi-tenant
un dialer por cliente sale caro
Riesgo
Dialers de instancia compartida
el aislamiento en la capa de aplicación es frágil
Minutos
Para aprovisionar un nuevo tenant
no semanas de implementación

Cómo funciona

Aislamiento en cada capa

La arquitectura multi-tenant de DialerBee usa Row-Level Security (RLS) de PostgreSQL para aplicar los límites entre tenants a nivel del motor de base de datos. Esto significa que el aislamiento no es solo lógica de aplicación: lo aplica la propia base de datos. Cada consulta se limita automáticamente al tenant actual. El acceso a datos entre tenants está impedido a nivel arquitectónico, no solo restringido por política. Si estás sopesando esto frente a una pila de código abierto más antigua, consulta nuestra alternativa a VICIdial comparison.

Paso 01

Aislar los datos

Los datos de cada cliente viven en una partición lógicamente aislada. El RLS de PostgreSQL garantiza que cada consulta se limite automáticamente al tenant actual, aplicado por el motor de la base de datos y no por la lógica de la aplicación.

Paso 02

Aislar las reglas

Cada tenant tiene configuraciones de cumplimiento independientes: listas DNC, reglas de horarios de llamada, seguimiento del consentimiento, límites de reintentos y perfiles regulatorios. Las reglas de un cliente nunca afectan las campañas de otro.

Paso 03

Aislar las grabaciones

Las grabaciones de llamadas se almacenan y se accede a ellas por tenant, con aislamiento total. Políticas de retención, controles de retención legal y monitoreo del almacenamiento independientes por cliente.

Paso 04

Aislar la facturación

El uso, los minutos y los puestos se miden por tenant. Exporte los datos de facturación para facturar a sus clientes o intégrelos con su sistema de facturación. Atribución completa de costos por cliente.

Comparación lado a lado

Multi-tenant real frente a grupos de usuarios básicos

Capacidad Grupos de usuarios básicos DialerBee multi-tenant
Aislamiento de datos Filtros en la capa de aplicación RLS de PostgreSQL en el motor de la base de datos
Reglas de cumplimiento Compartidas, con excepciones por grupo Independientes por tenant, totalmente aisladas
Grabaciones Almacenamiento compartido con etiquetas de grupo Almacenamiento aislado por tenant
Facturación Atribución manual Medición automática del uso por tenant
Aprovisionamiento Configuración manual por cliente Minutos, desde el portal de administración o la API
Riesgo entre tenants Un error o un filtro mal configurado puede filtrar datos Impedido por arquitectura mediante RLS
Ajuste de IA Modelo compartido entre todos los clientes Flujos de ajuste del AMD por tenant
Informes Vistas filtradas de datos compartidos Paneles y exportaciones delimitados por tenant

Funciones de gestión

Opere varios clientes desde una sola plataforma

Además del aislamiento, la arquitectura multi-tenant de DialerBee ofrece la capa de gestión que necesitan los BPO para operar con eficiencia con varios clientes. El aprovisionamiento de tenants, el acceso basado en roles, la analítica entre tenants para los propietarios de la plataforma y las opciones de marca blanca funcionan en conjunto para que la gestión de varios clientes sea viable en la práctica, no solo técnicamente posible.

Control de acceso basado en roles

Permisos detallados por tenant. Administradores, supervisores y agentes ven solo lo que deben ver. Los propietarios de la plataforma tienen vistas entre tenants para la gestión operativa.

Reportes por cliente

Cada reporte, panel y exportación se limita al tenant. Analítica entre clientes disponible para los propietarios de la plataforma. Reportes programados específicos por cliente.

Aprovisionamiento de tenants

Cree el entorno de un nuevo cliente en minutos desde el portal de administración o la API para partners. Usuarios, campañas, reglas de cumplimiento y pools de DID, todo a partir de plantillas.

Separación de la facturación

Mida el uso, los minutos, los puestos y los costos de mensajería por tenant. Exporte los datos de facturación para emitir facturas. Intégrelos con su sistema de facturación mediante API.

Ajuste de IA por tenant

La precisión del AMD mejora de forma independiente en cada tenant mediante flujos de ajuste limitados al tenant. La retroalimentación de cada cliente mejora el rendimiento de su propio modelo.

Opciones de marca blanca

Opere DialerBee con su marca, con dominio, logotipo y paleta de colores propios. Marca por tenant para implementaciones de revendedores.

Especificaciones técnicas

Bajo el capó

Método de aislamiento Row-Level Security (RLS) de PostgreSQL en el motor de la base de datos
Delimitación de datos Cada consulta se limita automáticamente al tenant actual
Aislamiento del cumplimiento Listas DNC, horarios de llamada, consentimiento, límites de reintentos y perfiles regulatorios por tenant
Aislamiento de grabaciones Almacenamiento por tenant con retención y retención legal independientes
Medición para facturación Uso, minutos, puestos y costos de mensajería por tenant
Aprovisionamiento Minutos, desde el portal de administración o la API para partners, con configuraciones basadas en plantillas
RBAC Control de acceso basado en roles detallado por tenant
Ajuste de IA Flujos de ajuste del AMD limitados al tenant: mejora del modelo por cliente
Informes Paneles y exportaciones por tenant; vistas entre tenants para los propietarios de la plataforma
Gestión de DID Pools de caller ID por tenant con rotación y asignación a campañas aisladas
Marca blanca Dominio, logotipo y colores propios por tenant
Acceso a la API Gestión, aprovisionamiento y facturación de tenants mediante API REST

Preguntas frecuentes sobre multi-tenant

¿Cómo aplica DialerBee el aislamiento entre tenants?
DialerBee usa Row-Level Security (RLS) de PostgreSQL para aplicar los límites entre tenants en la capa de consultas de la base de datos. Esto significa que el aislamiento lo aplica el propio motor de la base de datos, no solo la lógica de la aplicación. Cada consulta se limita automáticamente al tenant actual. El acceso a datos entre tenants está impedido por arquitectura.
¿Puede cada tenant tener reglas de cumplimiento distintas?
Sí. Cada tenant tiene listas DNC, reglas de horarios de llamada, seguimiento del consentimiento, límites de reintentos y perfiles regulatorios independientes. Un tenant puede operar con reglas de la TCPA y otro con reglas de la TDRA en la misma plataforma, sin solapamientos ni interferencias.
¿Qué tan rápido puedo aprovisionar un nuevo tenant?
Los nuevos tenants se pueden crear en minutos desde el portal de administración o la API para partners. Las configuraciones basadas en plantillas para reglas de cumplimiento, roles de usuario, ajustes de campaña y pools de DID aceleran la incorporación. Los agentes pueden empezar a marcar el mismo día.
¿La grabación de llamadas está aislada entre tenants?
Sí. Las grabaciones de llamadas se almacenan y se accede a ellas por tenant, con aislamiento total. Cada tenant tiene políticas de retención, controles de retención legal y monitoreo del almacenamiento independientes. Ningún tenant puede acceder nunca a las grabaciones de otro a través de la interfaz ni de la API.
¿Cómo funciona el ajuste de IA por tenant?
Las correcciones de los agentes al AMD con IA alimentan flujos de ajuste limitados al tenant. Así, la retroalimentación de cada tenant mejora la precisión del AMD para sus operadores, regiones y tipos de campaña específicos, sin afectar los modelos de otros tenants.
¿Pueden los propietarios de la plataforma ver datos entre tenants?
Sí. Los propietarios y administradores de la plataforma pueden acceder a analítica entre tenants para la gestión operativa: uso total, estado de la plataforma y métricas agregadas. Pero los usuarios a nivel de tenant (administradores, supervisores, agentes) solo ven los datos de su propio tenant.
¿El multi-tenant funciona con marca blanca?
Sí. Las opciones de marca blanca permiten dominio, logotipo y paleta de colores propios por tenant. Es ideal para revendedores de telecomunicaciones que quieren que cada cliente vea una experiencia con su marca mientras funciona sobre infraestructura compartida.
¿Cómo se mide la facturación por tenant?
El uso, los minutos, los puestos y los costos de mensajería se miden automáticamente por tenant. Los datos de facturación se pueden exportar para emitir facturas o integrar con su sistema de facturación mediante API. Los costos de cada tenant se atribuyen por completo sin cálculos manuales.

Hecho para BPO y revendedores

Agende una demo y vea cómo DialerBee aísla a cada cliente con un multi-tenant de nivel empresarial.

Prueba gratuita de 14 días · crédito de IA gratuito · sin tarjeta · ver precios

Ver el sitio completo en inglés →