Melhor software de discador para BPOs

BPOs têm requisitos de discador que nenhum outro segmento de clientes compartilha. Você não roda uma campanha para uma empresa — roda dezenas de campanhas para vários clientes ao mesmo tempo, cada uma com dados, regras de conformidade, SLAs e requisitos de relatório diferentes. Um discador que funciona para uma equipe de vendas interna não aguenta a complexidade operacional de um BPO.

Este guia aborda os recursos específicos que operações de BPO devem avaliar ao escolher um software de discador, com base nos padrões operacionais que observamos em agências de cobrança, operações de vendas terceirizadas e BPOs de atendimento ao cliente que rodam campanhas ativas (outbound).

Arquitetura multi-tenant: o item inegociável

A arquitetura multi-tenant é a base. Todo o resto depende dela. No contexto de BPO, multi-tenant significa:

Isolamento de dados

Os dados de contato do Cliente A precisam ser totalmente invisíveis para agentes, supervisores e administradores do Cliente B. Isso não é apenas uma configuração de permissão — precisa ser garantido no nível do banco de dados. Uma permissão mal configurada em um sistema de acesso baseado em funções pode vazar dados entre clientes. Uma arquitetura multi-tenant de verdade usa separação lógica ou física dos dados, tornando o acesso cruzado entre clientes impossível pela própria arquitetura.

Por que isso importa: contratos de BPO sempre incluem cláusulas de proteção de dados. Um vazamento de dados entre clientes é quebra de contrato, possível violação regulatória e um evento capaz de encerrar o negócio. Pergunte ao fornecedor do discador: "Se um administrador configurar uma função errada por acidente, os agentes de um cliente conseguem ver os dados de outro?" Se a resposta não for um "não" convicto, a arquitetura não é verdadeiramente multi-tenant.

Isolamento de configuração

Cada tenant de cliente deve ter configuração independente para: modos de discagem (Cliente A no preditivo, Cliente B no progressivo), regras de conformidade (limites de tentativas, horários de ligação e listas DNC diferentes), configurações de AMD (sensibilidade diferente por cliente, conforme a tolerância a falsos positivos versus falsos negativos), políticas de gravação de chamadas, códigos e fluxos de tabulação e fluxos de IVR.

Isolamento de recursos

A campanha de um cliente não pode tirar recursos de discagem da campanha de outro. Se o Cliente A tiver um pico de discagem em alto volume, as campanhas do Cliente B devem continuar operando normalmente. Procure mecanismos de enfileiramento justo ou reserva de recursos que evitem o problema do "vizinho barulhento".

O arquitetura multi-tenant impõe isolamento nos níveis de dados, configuração e recursos, e foi projetada para que cada cliente opere como se tivesse sua própria instância dedicada de discador.

Configuração de conformidade por cliente

Clientes diferentes operam sob marcos regulatórios diferentes. Um BPO que atende clientes de cobrança nos EUA e clientes de vendas nos Emirados Árabes Unidos precisa aplicar as regras do TCPA/Reg F para um e as regras da TDRA para o outro — simultaneamente, na mesma plataforma, sem misturá-las.

Principais recursos de conformidade para BPOs:

• Listas DNC por tenant: Cada cliente tem sua própria lista DNC interna, além de acesso aos cadastros nacionais pertinentes. Um pedido de DNC de um devedor do Cliente A não deve suprimir esse número das campanhas do Cliente B (a menos que o número também esteja na lista DNC do Cliente B).
• Janelas de ligação por tenant: Cliente A nos EUA: das 8h às 21h no horário local do destinatário. Cliente B nos Emirados Árabes Unidos: das 9h às 21h no horário padrão do Golfo. Cliente C na UE: das 10h às 20h conforme as regras de cada Estado-membro. Cada uma precisa ser aplicada de forma independente.
• Limites de novas tentativas por tenant: Um cliente de cobrança sujeito ao Reg F precisa de 7 tentativas a cada 7 dias. Um cliente de vendas pode permitir 3 tentativas por dia. Esses limites precisam ser configuráveis e aplicados por tenant.
• Políticas de gravação por tenant: Alguns clientes exigem que todas as chamadas sejam gravadas. Outros exigem avisos de consentimento de gravação. Alguns clientes em jurisdições específicas podem precisar pausar a gravação durante a captura de dados PCI. Cada tenant precisa da sua própria configuração de gravação.

Escopo de supervisão e administração

As estruturas organizacionais de um BPO são mais complexas do que as de equipes internas. Um BPO típico tem: um diretor de operações que supervisiona todos os clientes, gerentes de conta que veem apenas o(s) cliente(s) atribuído(s) a eles, líderes de equipe que veem apenas sua equipe dentro de um cliente e agentes que veem apenas o próprio trabalho.

O discador precisa suportar escopo de acesso hierárquico:

• Administrador do BPO: Acesso total a todos os tenants. Pode provisionar tenants, gerenciar configurações globais e ver relatórios consolidados.
• Supervisor do cliente: Acesso restrito a um único tenant. Pode gerenciar campanhas, ver relatórios, ouvir gravações e orientar agentes — mas apenas dentro do seu cliente.
• Líder de equipe: Acesso restrito a uma equipe dentro de um tenant. Vê o desempenho da própria equipe, mas não o de outras equipes que atendem o mesmo cliente.
• Agente: Acesso à própria fila, aos scripts e à interface de tabulação. Sem acesso ao trabalho de outros agentes nem a dados de nível de cliente.

Esse escopo também precisa valer para os recursos em tempo real. Quando um supervisor usa escuta, sussurro ou intervenção (listen/whisper/barge), ele só deve conseguir entrar em chamadas dentro do seu escopo de acesso. Um supervisor do Cliente A não pode conseguir ouvir chamadas do Cliente B — nem por acidente.

BYOC: Flexibilidade de operadora por cliente

BPOs frequentemente lidam com clientes que têm seus próprios contratos com operadoras e querem que as chamadas ativas passem pelos seus troncos SIP. Os motivos incluem: o cliente negociou tarifas de atacado que não quer perder, exigências regulatórias determinam que o tráfego passe por operadoras licenciadas específicas, o cliente quer gerenciar a reputação do próprio caller ID ou o contrato exige que o tráfego de voz se origine na infraestrutura do cliente.

BYOC no nível do tenant resolve isso. Cada tenant de cliente conecta seus próprios troncos SIP, usa seus próprios DIDs e paga diretamente a sua operadora. O BPO gerencia a plataforma de discagem; o cliente gerencia sua operadora. Isso também simplifica o faturamento — o BPO cobra pelas posições de software e o cliente paga a operadora separadamente, eliminando disputas sobre tarifas por minuto.

White-label para portais voltados ao cliente

Alguns clientes de BPO querem acesso a dashboards de campanha, gravações de chamadas e relatórios de desempenho — mas não querem ver a marca do fornecedor do seu discador. Querem ver a marca do seu BPO ou a própria marca.

Os recursos white-label permitem oferecer portais para clientes com a identidade do seu BPO. Clientes de nível mais alto podem receber portais com a própria identidade. Isso é especialmente valioso para clientes enterprise que veem a plataforma tecnológica do BPO como parte da experiência da sua marca.

Relatórios e gestão de SLA

Os requisitos de relatório de um BPO são fundamentalmente diferentes dos de uma operação interna. Você precisa de:

Relatórios por cliente

Cada cliente precisa do seu próprio dashboard de relatórios com as métricas do seu SLA: taxa de contato, taxa de contato com a pessoa certa (RPC), taxa de conversão, tempo médio de atendimento (TMA), chamadas por hora e KPIs específicos da campanha. Os relatórios precisam ser isolados — o Cliente A nunca pode ver os dados de desempenho do Cliente B.

Relatórios de operação interna

Sua equipe de operações precisa de visões entre clientes: utilização de agentes em todos os clientes, eficiência na alocação de posições, desempenho de filas blended, análise de custos de operadora e dados de planejamento de recursos. Essa é a visão do BPO que os clientes não veem.

Monitoramento de SLA

Muitos contratos de BPO incluem compromissos de SLA: taxa mínima de contato, taxa máxima de abandono, limites de chamadas por hora ou metas de conversão. O discador deve oferecer monitoramento de limites de SLA com alertas quando as métricas se aproximam dos limites ou os ultrapassam. Uma gestão reativa de SLA — descobrir a violação no relatório mensal — chega tarde demais.

Entrega automatizada de relatórios

Os clientes esperam relatórios regulares sem precisar entrar em um portal. Procure envio agendado de relatórios por e-mail com modelos, períodos e seleção de métricas personalizáveis. Os relatórios devem levar a marca do tenant se você usa white-label.

Escalabilidade e gestão de campanhas simultâneas

Um BPO de médio porte pode rodar 5-10 tenants de clientes com 3-5 campanhas cada — ou seja, 15-50 campanhas simultâneas. Um BPO grande pode ter mais de 50 tenants e centenas de campanhas. O discador precisa suportar essa simultaneidade sem perda de desempenho.

Principais indicadores de escalabilidade:

• Tempo de início da campanha: Em quanto tempo uma campanha com 10.000 números começa a discar? Menos de 30 segundos é bom. Mais de 5 minutos indica limitações de arquitetura.
• Capacidade de agentes simultâneos: A plataforma suporta mais de 500 agentes simultâneos em todos os tenants sem degradar a qualidade das chamadas?
• Armazenamento de gravações: Em escala, as gravações de chamadas consomem muito armazenamento. A plataforma oferece armazenamento escalável com políticas de retenção por tenant?
• Vazão da API: Se você integra vários CRMs de clientes, a API precisa suportar requisições de alta frequência sem limites de taxa que afetem os fluxos em tempo real.

Critérios de avaliação

Ao avaliar um software de discador para operações de BPO, pondere seus critérios assim:

1. Isolamento multi-tenant (crítico): Isolamento de dados, configuração e recursos entre clientes.
2. Conformidade por tenant (crítico): DNC, horários de ligação, limites de tentativas e políticas de gravação independentes por cliente.
3. Controle de acesso hierárquico (alto): Acesso com escopo para administradores do BPO, supervisores de clientes, líderes de equipe e agentes.
4. BYOC por tenant (alto): Configuração de tronco SIP por cliente para flexibilidade de operadora.
5. Isolamento de relatórios e ferramentas de SLA (alto): Relatórios por cliente com analytics internos entre clientes.
6. White-label (médio): Personalização de marca nas interfaces voltadas ao cliente.
7. Escalabilidade (médio-alto): Capacidade comprovada para o número previsto de tenants e agentes.
8. Abrangência da API (médio): Capacidade de integração com stacks tecnológicos variados dos clientes.

Para ver em detalhes como o DialerBee atende aos requisitos de BPO, acesse nossa página de soluções para BPO.

Perguntas frequentes

Por que a arquitetura multi-tenant é inegociável para um BPO?

Cada cliente precisa de dados isolados, configuração de conformidade própria e relatórios próprios. Sem isolamento de tenants, você gerencia clientes separados dentro de um único pool compartilhado, o que é um risco tanto operacional quanto de confidencialidade.

Cada cliente pode ter regras de conformidade diferentes?

Precisa ter. Os clientes discam para jurisdições diferentes, com horários de ligação, bases de consentimento e limites de tentativas diferentes, por isso essas configurações devem ser por tenant, e não globais.

O que significa escopo de supervisão?

Um supervisor deve ver apenas as campanhas, os agentes e as gravações do seu cliente. O escopo impõe esse limite na própria plataforma, em vez de depender de as pessoas evitarem a tela errada.

Por que o BYOC é importante para BPOs?

Os clientes muitas vezes trazem seus próprios contratos com operadoras ou exigem um roteamento específico. A flexibilidade de operadora por cliente permite atender a isso sem manter uma plataforma separada para cada um.