El mejor software de marcación para BPO

Los BPO tienen requisitos de marcación que ningún otro segmento de clientes comparte. No ejecuta una campaña para una empresa: ejecuta decenas de campañas para varios clientes al mismo tiempo, cada una con datos, reglas de cumplimiento, SLA y requisitos de reportes distintos. Un marcador que funciona para un equipo de ventas interno se quiebra ante la complejidad operativa de un BPO.

Esta guía cubre las capacidades específicas que las operaciones BPO deben evaluar al elegir un software de marcador, a partir de los patrones operativos que vemos en agencias de cobranza, operaciones de ventas tercerizadas y BPO de servicio al cliente que ejecutan campañas salientes.

Arquitectura multi-tenant: lo innegociable

El multi-tenant es la base. Todo lo demás depende de él. En el contexto de un BPO, multi-tenant significa:

Aislamiento de datos

Los datos de contacto del Cliente A deben ser completamente invisibles para los agentes, supervisores y administradores del Cliente B. No es solo una configuración de permisos: debe aplicarse a nivel de base de datos. Un permiso mal configurado en un sistema de acceso basado en roles puede filtrar datos entre clientes. Un verdadero multi-tenant usa una separación lógica o física de los datos que hace que el acceso cruzado entre clientes sea imposible por arquitectura.

Por qué importa: los contratos de BPO incluyen, sin excepción, cláusulas de protección de datos. Una fuga de datos entre clientes es un incumplimiento de contrato, una posible infracción regulatoria y un evento que puede acabar con el negocio. Pregunte a su proveedor de marcador: "Si un administrador configura mal un rol por accidente, ¿pueden los agentes de un cliente ver los datos de otro?". Si la respuesta no es un "no" rotundo, la arquitectura no es realmente multi-tenant.

Aislamiento de configuración

Cada tenant de cliente debe tener una configuración independiente para: modos de marcación (Cliente A en predictivo, Cliente B en progresivo), reglas de cumplimiento (distintos límites de reintentos, horarios de llamada y listas DNC), ajustes de AMD (sensibilidad distinta por cliente según su tolerancia a falsos positivos frente a falsos negativos), políticas de grabación de llamadas, códigos y flujos de tipificación, y flujos de IVR.

Aislamiento de recursos

La campaña de un cliente no debe dejar sin recursos de marcación a la campaña de otro. Si el Cliente A tiene un pico de marcación de alto volumen, las campañas del Cliente B deben seguir funcionando con normalidad. Busque mecanismos de colas equitativas o de reserva de recursos que eviten el problema del "vecino ruidoso".

El arquitectura multi-tenant aplica el aislamiento a nivel de datos, configuración y recursos, con el objetivo de que cada cliente opere como si tuviera su propia instancia de marcador dedicada.

Configuración de cumplimiento por cliente

Cada cliente opera bajo un marco regulatorio distinto. Un BPO que atiende a la vez a clientes de cobranza en EE. UU. y a clientes de ventas en EAU necesita aplicar las reglas de TCPA/Reg F a unos y las de la TDRA a otros, al mismo tiempo, en la misma plataforma y sin mezclarlas.

Funciones clave de cumplimiento para BPO:

• Listas DNC por tenant: Cada cliente tiene su propia lista DNC interna, además de acceso a los registros nacionales correspondientes. Una solicitud de no llamar de un deudor del Cliente A no debe suprimir ese número de las campañas del Cliente B (a menos que el número también figure en la lista DNC del Cliente B).
• Ventanas de llamada por tenant: Cliente A en EE. UU.: de 8 AM a 9 PM, hora local del destinatario. Cliente B en EAU: de 9 AM a 9 PM, hora estándar del Golfo. Cliente C en la UE: de 10 AM a 8 PM, según las reglas de cada Estado miembro. Cada una debe aplicarse de forma independiente.
• Límites de reintentos por tenant: Un cliente de cobranza sujeto a Reg F necesita 7 intentos cada 7 días. Un cliente de ventas podría permitir 3 intentos por día. Estos límites deben ser configurables y aplicarse por tenant.
• Políticas de grabación por tenant: Algunos clientes exigen que se graben todas las llamadas. Otros exigen anuncios de consentimiento de grabación. Algunos clientes en jurisdicciones específicas pueden necesitar pausar la grabación durante la captura de datos PCI. Cada tenant necesita su propia configuración de grabación.

Alcance de supervisores y administradores

Las estructuras organizativas de un BPO son más complejas que las de los equipos internos. Un BPO típico tiene: un director de operaciones que supervisa a todos los clientes, gerentes de cliente que solo ven a sus clientes asignados, líderes de equipo que solo ven a su equipo dentro de un cliente y agentes que solo ven su propio trabajo.

El marcador debe admitir un alcance de acceso jerárquico:

• Administrador a nivel de BPO: Acceso completo a todos los tenants. Puede aprovisionar tenants, gestionar la configuración global y ver reportes consolidados.
• Supervisor a nivel de cliente: Acceso limitado a un solo tenant. Puede gestionar campañas, ver reportes, escuchar grabaciones y hacer coaching a los agentes, pero solo dentro de su cliente.
• Líder de equipo: Acceso limitado a un equipo dentro de un tenant. Puede ver el desempeño de su equipo, pero no el de otros equipos que trabajan para el mismo cliente.
• Agente: Acceso a su propia cola, guiones e interfaz de tipificación. Sin acceso al trabajo de otros agentes ni a datos a nivel de cliente.

Este alcance también debe aplicarse a las funciones en tiempo real. Cuando un supervisor usa escucha, susurro o intervención, solo debe poder unirse a llamadas dentro de su alcance de acceso. Un supervisor del Cliente A no debe poder escuchar las llamadas del Cliente B, ni siquiera por accidente.

BYOC: flexibilidad de operador por cliente

Los BPO se encuentran con frecuencia con clientes que tienen sus propios contratos con operadores y quieren que las llamadas salientes se enruten por sus troncales SIP. Los motivos incluyen: el cliente negoció tarifas mayoristas que no quiere perder, la regulación exige enrutar el tráfico por operadores con licencia específicos, el cliente quiere gestionar la reputación de su propio identificador de llamadas, o el contrato especifica que el tráfico de voz debe originarse en la infraestructura del cliente.

BYOC a nivel de tenant resuelve esto. Cada tenant de cliente conecta sus propias troncales SIP, usa sus propios DID y paga directamente a su operador. El BPO gestiona la plataforma de marcación; el cliente gestiona su operador. Esto también simplifica la facturación: el BPO factura los puestos de software y el cliente paga a su operador por separado, lo que elimina las disputas sobre cargos por minuto.

Marca blanca para portales de clientes

Algunos clientes de BPO quieren acceder a dashboards de campañas, grabaciones de llamadas y reportes de desempeño, pero no quieren ver la marca de su proveedor de marcador. Quieren ver la marca de su BPO o la suya propia.

Las capacidades de marca blanca le permiten ofrecer portales para clientes con la identidad de su BPO. Los clientes de mayor nivel podrían recibir portales con su propia identidad. Esto es especialmente valioso para clientes empresariales que consideran la plataforma tecnológica del BPO como parte de su experiencia de marca.

Reportes y gestión de SLA

Los requisitos de reportes de un BPO son fundamentalmente distintos de los de una operación interna. Usted necesita:

Reportes por cliente

Cada cliente necesita su propio dashboard de reportes con métricas relevantes para su SLA: tasa de contacto, tasa de contacto con la persona correcta, tasa de conversión, tiempo medio de atención (AHT), llamadas por hora y KPI específicos de la campaña. Los reportes deben estar aislados: el Cliente A nunca puede ver los datos de desempeño del Cliente B.

Reportes de operaciones internas

Su equipo de operaciones necesita vistas transversales entre clientes: utilización de agentes en todos los clientes, eficiencia en la asignación de puestos, desempeño de colas combinadas (blended), análisis de costos de operador y datos de planificación de recursos. Es la vista a nivel de BPO que los clientes no ven.

Monitoreo de SLA

Muchos contratos de BPO incluyen compromisos de SLA: tasa mínima de contacto, tasa máxima de abandono, umbrales de llamadas por hora u objetivos de conversión. El marcador debe permitir monitorear los umbrales de SLA con alertas cuando las métricas se acerquen a ellos o los superen. La gestión reactiva del SLA, es decir, descubrir un incumplimiento en el reporte mensual, llega demasiado tarde.

Envío automatizado de reportes

Los clientes esperan reportes periódicos sin tener que iniciar sesión en un portal. Busque el envío programado de reportes por correo electrónico con plantillas, rangos de fechas y selección de métricas personalizables. Si usa marca blanca, los reportes deben llevar la marca del tenant.

Escalabilidad y gestión de campañas simultáneas

Un BPO mediano puede operar entre 5 y 10 tenants de clientes con 3 a 5 campañas cada uno: entre 15 y 50 campañas simultáneas. Un BPO grande puede tener más de 50 tenants y cientos de campañas. El marcador debe manejar esta concurrencia sin degradar el desempeño.

Indicadores clave de escalabilidad:

• Tiempo de inicio de campaña: ¿Qué tan rápido puede empezar a marcar una campaña con 10,000 números? Menos de 30 segundos es bueno. Más de 5 minutos indica limitaciones de arquitectura.
• Capacidad de agentes simultáneos: ¿Puede la plataforma soportar más de 500 agentes simultáneos en todos los tenants sin que se degrade la calidad de llamada?
• Almacenamiento de grabaciones: A escala, las grabaciones de llamadas consumen mucho almacenamiento. ¿Ofrece la plataforma almacenamiento escalable con políticas de retención por tenant?
• Rendimiento de la API: Si se integra con los CRM de varios clientes, la API debe atender solicitudes de alta frecuencia sin límites de tasa que afecten los flujos de trabajo en tiempo real.

Marco de evaluación

Al evaluar un software de marcador para operaciones BPO, pondere sus criterios de la siguiente manera:

1. Aislamiento multi-tenant (crítico): Aislamiento de datos, configuración y recursos entre clientes.
2. Cumplimiento por tenant (crítico): DNC, horarios de llamada, límites de reintentos y políticas de grabación independientes por cliente.
3. Control de acceso jerárquico (alto): Acceso con alcance definido para administradores del BPO, supervisores de clientes, líderes de equipo y agentes.
4. BYOC por tenant (alto): Configuración de troncales SIP a nivel de cliente para flexibilidad de operador.
5. Aislamiento de reportes y herramientas de SLA (alto): Reportes por cliente con analítica interna transversal entre clientes.
6. Marca blanca (medio): Personalización de marca para las interfaces que ven los clientes.
7. Escalabilidad (medio-alto): Capacidad verificada para su número proyectado de tenants y agentes.
8. Amplitud de la API (medio): Capacidad de integración con los distintos stacks tecnológicos de los clientes.

Para ver en detalle cómo DialerBee responde a los requisitos de un BPO, visite nuestra página de soluciones para BPO.

Preguntas frecuentes

¿Por qué el multi-tenant es innegociable para un BPO?

Cada cliente necesita datos aislados, su propia configuración de cumplimiento y sus propios reportes. Sin aislamiento por tenant, usted gestiona clientes distintos dentro de un mismo pool compartido, lo que supone un riesgo tanto operativo como de confidencialidad.

¿Puede cada cliente tener reglas de cumplimiento distintas?

Debe tenerlas. Los clientes llaman a jurisdicciones distintas, con horarios de llamada, bases de consentimiento y límites de intentos diferentes, por lo que esa configuración debe ser por tenant y no global.

¿Qué significa el alcance de supervisión?

Un supervisor solo debe ver las campañas, agentes y grabaciones de su cliente. El alcance aplica ese límite en la plataforma, en lugar de depender de que las personas eviten abrir la pantalla equivocada.

¿Por qué BYOC es importante para los BPO?

Los clientes suelen traer sus propias relaciones con operadores o exigir un enrutamiento específico. La flexibilidad de operador por cliente le permite cumplir con eso sin operar una plataforma separada para cada uno.