O Que Procurar em um Provedor de SBC Gerenciado: Um Framework de Avaliação para Compradores

A maioria das páginas de vendas de SBC gerenciado parece idêntica. As diferenças estão no contrato, no modelo de suporte e no que realmente aparece em produção seis meses após a assinatura.

As apresentações comerciais de Controlador de Borda de Sessão (SBC) gerenciado se repetem. Todo provedor promete “totalmente gerenciado”, “suporte 24×7”, “monitoramento incluso” e “alta disponibilidade”. As conversas iniciais soam iguais.

As diferenças estão nos detalhes do contrato, no modelo de suporte e no que realmente aparece em produção. Escolha o provedor errado e você descobre os limites durante seu primeiro incidente às 2h da manhã: um operador de help desk que registra um chamado e volta a dormir, uma configuração que você não pode alterar sozinho, uma plataforma de hospedagem da qual você não consegue sair sem reconstruir tudo do zero.

Este guia apresenta as perguntas que você deve fazer, organizadas por categoria. Ele pressupõe que você já decidiu que um SBC gerenciado se adequa melhor à sua equipe do que operar por conta própria. Se você ainda está avaliando essa decisão, a comparação entre SBC gerenciado e SBC auto-hospedado cobre esse tema. Se você ainda não escolheu um SBC, o guia do comprador de SBC é o ponto de partida correto. Esta página é para o próximo passo: você sabe que quer gerenciado, e agora precisa de um framework para comparar os provedores à sua frente.

1. O Que “Gerenciado” Realmente Cobre

A primeira pergunta também é a mais subestimada: o que o provedor realmente faz por você?

Todo provedor diz “totalmente gerenciado”. Mas o que isso realmente significa? Alguns provedores param no encaminhamento de Level 1 do help desk: eles atendem o telefone, registram um chamado e passam o incidente para a sua equipe resolver. Outros assumem o SBC de ponta a ponta. Eles configuram, monitoram, aplicam patches durante janelas de manutenção, integram novas operadoras quando você as contrata, renovam certificados TLS antes que expirem e ajustam a lógica de roteamento quando seu padrão de tráfego muda.

Solicite explicitamente o Statement of Work (SoW). Dentro do SoW, procure estes itens:

Setup inicial e integração é o esforço de implantação: provisionamento do SBC, configuração dos seus SIP Trunks e NAPs, integração com suas operadoras e sistemas PBX, e execução de chamadas de validação antes do go-live. Confirme que isso está incluso na mensalidade e não é cobrado como um projeto avulso.

Alterações de configuração contínuas são as mudanças que acontecem após o go-live: onboarding de uma nova operadora, ajuste de roteamento, uma nova regra de fraude, renovação de certificado TLS. Alguns provedores incluem alterações ilimitadas; outros cobram por solicitação ou limitam o número de alterações por trimestre. Ambos os modelos podem funcionar, mas você precisa saber qual se aplica.

Integração com operadoras e PBX é o trabalho de integrar novos provedores de SIP Trunk, novas plataformas PBX ou novos destinos em nuvem como um tenant Teams. Se seu roadmap inclui uma troca de operadora ou uma implantação de Teams Direct Routing nos próximos 18 meses, formalize a cobertura de integração por escrito.

Configuração do serviço de assinatura STIR/SHAKEN cobre a configuração que conecta seu SBC a um parceiro de serviço de assinatura STIR/SHAKEN (TransNexus ClearIP, Neustar, ou outro) e lida com a injeção do token PASSporT e do header Identity para chamadas de saída. A assinatura do serviço de signing em si é geralmente uma compra separada do fornecedor do serviço, mas o trabalho de integração no lado do SBC pertence ao escopo do serviço gerenciado.

Patches de segurança e atualizações de software cobrem a cadência de patches do fabricante, atualizações de kernel e upgrades de versão principal. A resposta correta é “o provedor cuida disso durante janelas de manutenção pré-acordadas”. A resposta errada é “avisaremos quando uma atualização estiver disponível e você pode agendá-la”. Isso não é serviço gerenciado.

Gerenciamento do ciclo de vida de certificados cobre os certificados TLS que o SBC utiliza para SIP/TLS, SRTP e conexões de TLS mútuo como Teams Direct Routing. Certificados expiram em um cronograma fixo. Um serviço gerenciado que não assume essa responsabilidade está a um certificado expirado de uma interrupção. Com a atualização da CA raiz da Microsoft em junho de 2026 para Teams Direct Routing, isso não é teórico.

Resposta a incidentes e análise de causa raiz é o trabalho após algo quebrar: quem atende a ligação, quem diagnostica o problema, quem fornece um relatório escrito do incidente e quanto tempo tudo isso leva. Um bom provedor entrega um relatório pós-incidente dentro de um prazo definido. Um fraco fecha o chamado e segue em frente.

2. Estrutura de SLA: Resposta e Resolução Mensuráveis

Um Acordo de Nível de Serviço (SLA) é a espinha dorsal contratual de qualquer serviço gerenciado. Leia-o antes de ler qualquer outra coisa.

A primeira coisa a verificar é se o SLA distingue tempo de resposta de tempo de resolução. Um SLA somente de resposta diz que o provedor reconhecerá um incidente de Severidade 1 em 30 minutos. Isso não diz nada sobre quando o serviço será restaurado. Um SLA com tempo de resolução se compromete a realmente corrigir o problema dentro de um prazo definido, com créditos devidos se o provedor não cumprir. A maioria dos SLAs robustos inclui ambos, estratificados por severidade.

Uma matriz de severidade típica tem quatro níveis: Severidade 1 é interrupção total ou degradação grave do serviço; Severidade 2 é degradação parcial ou falha de funcionalidade com solução alternativa; Severidade 3 é problema menor ou impacto em um único tenant; Severidade 4 é solicitação de informação ou alteração de configuração não urgente. Metas de resposta se comprimem na faixa de alta severidade (15 a 30 minutos para Sev 1) e relaxam na faixa baixa (próximo dia útil para Sev 4).

Garantias de uptime merecem uma análise cuidadosa das exclusões. Uma garantia de 99,99% de uptime no papel significa aproximadamente 52 minutos de downtime permitido por ano. Mas todo SLA define uptime em relação a eventos específicos. Janelas de manutenção não contam. Força maior não conta. Interrupções de operadoras upstream normalmente não contam. Interrupções causadas pelo cliente não contam. O envelope restante é o que o provedor está realmente se comprometendo a entregar.

Por fim, peça referências e pergunte às referências sobre comportamento em incidentes, não sobre satisfação. Uma referência dizendo “eles têm sido ótimos” não ajuda. Uma referência dizendo “tivemos uma inundação SIP às 4h da manhã no último trimestre, eis o que aconteceu, eis quando a ligação foi atendida, eis quando o serviço foi restaurado” é o dado que você precisa.

3. Calibre do Suporte e Acesso a Engenheiros

O SLA diz o que o provedor se compromete a entregar. O modelo de suporte diz quem realmente atende o telefone.

A divisão fundamental é entre help desk com níveis e primeiro contato Level 3. Em um modelo com níveis, sua ligação de Severidade 1 é primeiro atendida por um operador Level 1 que coleta informações, depois escala para Level 2 se necessário, depois para Level 3 se o Level 2 não resolver. Cada passagem adiciona tempo. Quando um engenheiro experiente entra na ligação, você já gastou uma hora explicando o problema duas vezes.

Em um modelo de primeiro contato Level 3, a primeira pessoa que atende sua ligação é o engenheiro capaz de resolver o problema. Não há camada de triagem, fila de chamados, nem árvore de perguntas padronizadas. Para infraestrutura de voz em produção com uma interrupção em tempo real, este é o modelo pelo qual vale a pena pagar.

A localização geográfica dos engenheiros de suporte importa. Suporte 24×7 prestado por engenheiros em um único fuso horário não é o mesmo que cobertura 24×7 follow-the-sun. Pergunte onde os engenheiros estão baseados. Pergunte se a mesma equipe cobre todos os horários ou se o horário fora do expediente é direcionado a uma rotação separada e menos experiente. Pergunte se o suporte fora do horário comercial é interno ou terceirizado.

Cobertura linguística importa em implantações internacionais. Um MSP europeu atendendo clientes franceses e alemães não deveria estar depurando traces SIP com um engenheiro de suporte que só fala inglês.

Por fim, escalação. Se o engenheiro da linha de frente não consegue resolver o problema, qual é o caminho documentado? Quem revisa o caso? Qual é o tempo até a liderança de engenharia? Provedores que não conseguem responder a essa pergunta geralmente não têm um processo definido.

4. Visibilidade do Cliente: Dashboard Completo ou Caixa-Preta

A preocupação mais comum dos compradores com serviços gerenciados é a perda de controle. A preocupação é legítima; a resposta depende inteiramente do provedor.

Alguns provedores tratam o SBC como uma caixa-preta. O cliente vê uma página de status (verde ou vermelho) e um portal de cobrança. CDRs, rastreamento de chamadas, telas de configuração e monitoramento em tempo real não são expostos. Se algo parece errado, o único caminho para obter informação é abrir um chamado de suporte. Esse modelo existe, e funciona para alguns compradores, mas é incompatível com a maioria das operações de voz em produção.

O extremo oposto é o acesso completo do cliente. O cliente faz login no mesmo dashboard que os engenheiros do provedor utilizam. Podem visualizar cada configuração de NAP, cada regra de roteamento, cada CDR, cada rastreamento de chamada ao vivo, cada pontuação MOS. Podem auditar políticas de segurança, entradas de lista de bloqueio e limites de taxa sem abrir um chamado. Alterações ainda passam por um processo estruturado de gestão de mudanças (caso contrário o monitoramento do provedor quebra), mas a visibilidade é ilimitada.

A pergunta certa a fazer, por escrito: Terei acesso completo à interface do SBC, CDRs e rastreamento de chamadas? Se a resposta for não, procure outro provedor.

Uma pergunta relacionada é se o dashboard expõe as métricas que você realmente precisa. Operações de voz modernas se importam com métricas por NAP e por tronco: CPS, ASR, ABR, PDD, jitter, perda de pacotes, pontuação MOS no nível da chamada, não apenas dashboards agregados. Um serviço gerenciado que entrega apenas métricas agregadas da plataforma não consegue dizer qual cliente é responsável por um pico de CPS ou qual operadora é a origem de uma queda de qualidade. O guia de melhores práticas de monitoramento VoIP cobre as métricas que valem a pena acompanhar em detalhes.

Essa não é uma preocupação hipotética. Um BPO recentemente migrou de uma plataforma concorrente especificamente porque a stack de observabilidade existente agregava todo o tráfego e não conseguia isolar as métricas de um único grande cliente bancário. Eles precisavam de visibilidade por tenant, e a configuração anterior não fornecia isso. Qualquer avaliação de SBC gerenciado deve testar este cenário na demonstração: mostre-me as métricas de uma operadora específica ou de um cliente específico isoladamente.

5. Flexibilidade de Hospedagem: Por Que BYOI Importa Mais do Que os Compradores Imaginam

Uma divisão sutil, porém consequente, entre provedores de SBC gerenciado é se eles exigem que você hospede na infraestrutura deles ou se suportam BYOI.

Hospedagem pelo provedor significa que o SBC roda na conta de nuvem do provedor, no hardware deles, na região deles. Mais fácil de contratar, relacionamento com um único fornecedor para toda a stack, uma única fatura. A desvantagem aparece quando você tem restrições que a hospedagem do provedor não consegue atender: um requisito de residência de dados GDPR que exige que o SBC resida em um país específico, um ambiente PCI que requer auto-hospedagem sob controle da sua organização, um contrato governamental que exige on-premises, um acordo empresarial existente de AWS ou Azure no qual você quer que o tráfego do SBC trafegue.

O serviço gerenciado BYOI resolve todos esses cenários. O provedor implanta e opera o SBC na sua conta AWS, na sua assinatura Azure, no seu cluster VMware, no seu ambiente KVM/Proxmox ou no seu hardware on-premises. A infraestrutura permanece sob seu controle; as operações ficam com o provedor. Você obtém o benefício da gestão sem abrir mão da decisão de hospedagem.

Alguns cenários específicos em que BYOI é a resposta certa:

Regras de residência ou soberania de dados exigem que o tráfego de voz e os metadados de chamadas permaneçam dentro de uma conta de nuvem, data center ou jurisdição específica. GDPR é o mais citado; serviços financeiros e saúde têm seus próprios equivalentes. Serviço gerenciado BYOI na sua própria região satisfaz a regra de residência enquanto ainda transfere as operações do dia a dia.

Compromissos de nuvem existentes incluem instâncias reservadas, descontos empresariais, interconexões privadas e acordos de gasto comprometido que você já negociou com AWS, Azure ou um fornecedor de nuvem privada. Serviço gerenciado hospedado pelo provedor não aproveita esses descontos; BYOI aproveita.

Adjacência de rede importa quando o SBC precisa estar próximo ao seu PBX existente, plataforma de cobrança, sistema de detecção de fraude ou stack de contact center. Integrações sensíveis à latência funcionam melhor quando o SBC está na mesma VPC ou data center que os sistemas com os quais ele se comunica.

PCI DSS é o caso de conformidade específico em que o serviço gerenciado pode não ser viável. PCI exige que a organização administre sistemas críticos de segurança dentro do ambiente de dados do titular do cartão. Um SBC gerenciado no caminho de chamadas do processamento de pagamentos normalmente cai dentro desse perímetro. Confirme com seu auditor PCI antes de assumir que o serviço gerenciado é compatível.

Hospedagem pelo provedor é a resposta certa para compradores sem restrições de infraestrutura; BYOI é a resposta certa para todos os demais. Um provedor de SBC gerenciado que suporta apenas um modelo está forçando uma decisão que deveria ser sua.

6. Programabilidade Preservada

Um SBC gerenciado que elimina a programabilidade da plataforma subjacente é um rebaixamento disfarçado de conveniência.

Tabelas de rotas estáticas são suficientes para peering simples. Qualquer coisa além disso (atestação STIR/SHAKEN por chamada, seleção dinâmica de operadora, pontuação de fraude em tempo real, roteamento orientado por CRM, consultas LNP/CNAM em escala, integração com sua plataforma de cobrança) requer um SBC com uma camada programável aberta. O guia de integração de roteamento de chamadas via REST API do SBC cobre o padrão arquitetural.

Ao avaliar um provedor de SBC gerenciado, pergunte se a plataforma subjacente suporta roteamento programável e se o serviço gerenciado preserva essa capacidade. Um provedor que roda uma plataforma de SBC configurável mas bloqueia os clientes fora do motor de roteamento está oferecendo um produto diferente (inferior) de um provedor que expõe toda a superfície programável sob gestão de mudanças.

Especificamente:

O provedor suporta lógica de roteamento personalizada? Se você precisa de roteamento de menor custo entre múltiplas operadoras, roteamento por horário, overflow geográfico ou roteamento VIP para clientes específicos, essas políticas precisam estar em código em algum lugar. Confirme onde.

O provedor suporta suas integrações existentes? NetSapiens, PortaOne, FreePBX, 3CX, Genesys Cloud, Five9, NICE, sua plataforma de cobrança, seu CRM. Um SBC gerenciado que nunca implantou contra sua stack vai significar um onboarding mais lento e maior risco de casos extremos no go-live.

O provedor suporta suas integrações de fraude e STIR/SHAKEN? Os principais parceiros de signing STIR/SHAKEN (TransNexus ClearIP, Neustar) e os principais parceiros de pontuação de fraude (SecureLogix, YouMail) são caminhos de integração bem estabelecidos nas melhores plataformas de SBC gerenciado. Confirme por nome.

Você pode criar suas próprias integrações depois? Se você desenvolver uma regra de fraude customizada, um módulo de seleção de operadora personalizado ou um exportador de CDR customizado daqui a dezoito meses, o serviço gerenciado consegue acomodar? Ou você fica limitado ao que o provedor suporta nativamente?

Um serviço gerenciado que diz “operamos uma plataforma fechada, essas decisões são nossas” serve para alguns compradores. Para a maioria, a resposta é a plataforma que preserva a programabilidade dentro de um processo estruturado de gestão de mudanças.

7. Postura de Segurança e Conformidade

A baseline de segurança para um SBC gerenciado é inegociável. Um serviço gerenciado que não entrega todos esses itens está vendendo um equipamento de laboratório a preços de produção.

SIP sobre TLS para criptografia de sinalização, SRTP para criptografia de mídia. Ambos são requisitos básicos para qualquer SBC em produção. O guia de configuração TLS e SRTP cobre a arquitetura; a pergunta certa para um serviço gerenciado é se ambos estão habilitados por padrão e suportados em todas as conexões com operadoras.

Proteção DoS e DDoS com inspeção SIP, lista de bloqueio dinâmica, defesa contra varredura de registro SIP. Um firewall de rede não consegue fazer esse trabalho. O SBC é o único elemento de rede construído especificamente para inspecionar sinalização SIP na camada de aplicação. A referência de segurança de SBC cobre cada camada; confirme que o serviço gerenciado implementa todas elas.

Signing e verificação STIR/SHAKEN com escolha de parceiro. Os principais parceiros de serviço de signing (TransNexus ClearIP, Neustar) se conectam via SIP redirect a uma camada de roteamento configurável do SBC. Um serviço gerenciado que prende você a um único parceiro de signing está forçando uma decisão de compra que deveria ser sua. Integração aberta de parceiros é o modelo correto. Se você também precisa migrar de atestação nível C para autoatestação STIR/SHAKEN nível A sob a regra de certificado próprio da FCC, o serviço gerenciado deve suportar essa transição sem troca de plataforma.

Tratamento de mTLS para Teams Direct Routing da Microsoft. Se seu roadmap inclui Teams, o serviço gerenciado precisa lidar com TLS mútuo, registro de FQDN, o dialeto SIP do Teams e as atualizações de autoridade certificadora da Microsoft. A atualização de certificado do Teams Direct Routing em junho de 2026 é o exemplo mais recente; atualizações como essa devem ser tratadas pelo provedor sem intervenção do cliente.

Prevenção de fraude em tempo real. O serviço gerenciado deve suportar pontuação de fraude por chamada, bloqueio de números premium, limites de chamadas simultâneas, detecção de padrões anômalos e integração com parceiros terceirizados de detecção de fraude. A referência de detecção de fraude cobre o que significa um bom desempenho nesse quesito.

Opções de implantação específicas para conformidade. GDPR, HIPAA e PCI DSS, cada um impõe restrições sobre onde o SBC roda e quem o administra. Confirme que o serviço gerenciado tem padrões de implantação que correspondem ao seu framework de conformidade. Como mencionado acima, PCI é o único caso em que o serviço gerenciado pode não ser adequado.

8. Transparência de Preços: O Que Está Incluso e O Que é Adicional

Os preços de SBC gerenciado têm um problema: o número principal raramente é o número real. Peça o detalhamento por item, não o valor mensal agrupado, e verifique o que está em cada linha.

Os componentes padrão que um SBC gerenciado deve agrupar na mensalidade são: a licença do SBC propriamente dita, HA 1+1, suporte 24×7, setup e integração, monitoramento contínuo, alterações de configuração contínuas e atualizações de software. Um provedor que cobra qualquer um desses como complemento separado está oferecendo um serviço menos completo ou competindo com um número principal enganoso.

Para o ProSBC Managed Service especificamente, os preços publicados são mensais e acompanham a contagem de sessões e a complexidade da configuração. A taxa mensal inclui a licença ProSBC+, HA 1+1, suporte 24×7 Level 3, setup, integração, testes e monitoramento, agrupados em vez de precificados separadamente.

Ao comparar propostas, o benchmark correto não é a taxa de licença ou o número mensal principal. O benchmark correto é o custo de oportunidade de um engenheiro VoIP interno: $60.000 a $100.000 por ano em remuneração total. A pergunta para a planilha não é “o serviço gerenciado é mais barato que a licença”, mas sim “o serviço gerenciado é mais barato que as horas de engenheiro necessárias para operar internamente, mais o risco de dependência de pessoa-chave, mais o custo de rotação de plantão 24×7”. Para a maioria das implantações com menos de 5.000 sessões, a matemática favorece fortemente o modelo gerenciado.

Taxas de setup merecem uma pergunta separada. Alguns provedores incluem o setup na mensalidade; outros cobram uma taxa única de projeto. Ambos podem ser legítimos. O que não é legítimo é uma taxa de setup que paga apenas pela execução de um template de configuração. Pergunte o que o trabalho de setup cobre: integração de SIP Trunk, integração de PBX, chamadas de validação, onboarding de operadora, conexão com serviço de assinatura STIR/SHAKEN.

Descontos para contratos plurianuais e lock-in merecem escrutínio. Um desconto de 20% para um compromisso de três anos parece atraente no primeiro dia e parece caro no dia seiscentos, quando você descobre que o serviço não é o que esperava. Cobrança mensal OPEX sem lock-in de longo prazo é o modelo mais amigável para compradores, mesmo que a taxa nominal seja ligeiramente mais alta.

9. Termos de Onboarding e Saída

A primeira pergunta que os compradores fazem é com que rapidez o serviço pode entrar em operação. A pergunta que eles também deveriam fazer é com que facilidade podem sair.

Prazo de setup para um SBC gerenciado depende inteiramente da complexidade da integração. Uma implantação com operadora única e um PBX leva dias a uma semana. Implantações multi-operadora, multi-tenant e multi-região com integração de serviço de assinatura STIR/SHAKEN e Teams Direct Routing levam semanas. Peça ao provedor prazos típicos por tamanho de implantação, não promessas de melhor caso.

Migração de configuração é o trabalho de mover suas regras de roteamento, definições de NAP, políticas de segurança e integrações existentes da sua rede atual para o serviço gerenciado em produção. Um provedor mais proativo nesta etapa está oferecendo um negócio melhor do que um que trata a configuração como proprietária.

Termos contratuais importam para gestão de risco. Cobrança mensal com rescisão em 30 dias é o padrão favorável ao comprador. Compromissos anuais são comuns e podem ser razoáveis. Compromissos plurianuais sem cláusula de saída são a estrutura da qual se deve afastar.

Portabilidade na saída é a pergunta mais importante que os compradores nunca fazem: se você decidir deixar o serviço gerenciado em dois anos, o que leva consigo? A resposta correta é: sua configuração completa, seu histórico de CDR, sua lógica de roteamento, suas definições de NAP.

Portabilidade de plataforma acompanha a questão de saída. Se a plataforma de SBC gerenciado é o mesmo software que você operaria por conta própria (o modelo que o ProSBC usa), a transição de gerenciado para auto-hospedado, ou de um modelo de hospedagem para outro, é uma migração de configuração em vez de uma troca de plataforma. Se o serviço gerenciado roda software proprietário que você não consegue operar sozinho, a única maneira de sair é reimplementar em um SBC diferente.

Uma consideração de portabilidade relacionada é o seu PBX. Um exemplo real: um MSP que atualmente opera um PBX específico está planejando uma possível migração de PBX em alguns anos. Eles especificamente não queriam reinstalar o SBC caso fizessem essa troca. Sua escolha de SBC gerenciado foi orientada pelo agnosticismo de PBX (compatibilidade confirmada com NetSapiens, PortaOne, FreePBX, 3CX, Cisco UCM e outros), porque essa flexibilidade preserva a opção de tomar essa decisão depois sem reconstruir a infraestrutura de voz.

Sinais de Alerta para Se Afastar

Os seguintes padrões devem desqualificar um provedor de SBC gerenciado da sua lista:

Cultura de suporte “vamos retornar”. Se os clientes de referência descrevem a resposta do suporte como fila-de-chamados-e-retorno, sua interrupção das 2h da manhã será respondida às 9h. Esse é o motivo mais comum relatado para substituição de serviço gerenciado (e a razão específica citada em uma avaliação recente de SBC empresarial que migrou para um concorrente).

Acesso à configuração em caixa-preta. Um serviço gerenciado que não dá visibilidade ao dashboard do SBC, CDRs e rastreamento de chamadas equivale a voz-como-serviço com um SLA. Se você não consegue responder “o que está acontecendo com meu próprio tráfego agora” sem abrir um chamado, o modelo operacional está quebrado para voz em produção.

Plataforma de hospedagem única forçada. Se o provedor só implanta na infraestrutura deles sem opção BYOI, cada restrição de conformidade, residência de dados e compromisso de nuvem se torna um impedimento em vez de uma escolha de implantação.

Lock-in proprietário de STIR/SHAKEN. Um serviço gerenciado que agrupa seu próprio serviço de signing STIR/SHAKEN sem opção de usar TransNexus, Neustar ou outro parceiro está prendendo você a um fornecedor em uma decisão ortogonal. Integração aberta de parceiros é o padrão a exigir.

Itens ocultos na fatura. Um preço mensal que exclui HA, mensalidade que exclui monitoramento, mensalidade que exclui setup, mensalidade que exclui integração com operadora: quando tudo é somado, você está pagando mais do que os provedores que agrupam tudo. Insista em comparações equivalentes entre provedores.

Nenhum cliente de referência no seu segmento. Um provedor de SBC gerenciado que não tem nenhuma referência MSP mas está vendendo para o seu MSP, ou nenhuma referência de contact center para o seu contact center, não fez o trabalho de validar o caso de uso. Peça referências no seu perfil de comprador por nome.

Scorecard Prático de Avaliação

As nove categorias acima, destiladas em um scorecard comparativo que você pode usar contra cada provedor na sua lista:

Como o ProSBC Managed Service se Encaixa no Framework

Para leitores aplicando este scorecard ao ProSBC Managed Service, veja como ele responde a cada categoria. Isso não substitui fazer as mesmas perguntas a todos os provedores na sua lista; é um ponto de referência.

Escopo do serviço. O ProSBC Managed Service inclui ProSBC+ com HA 1+1, suporte 24×7 Level 3, setup, integração, testes, monitoramento, alterações de configuração contínuas e atualizações de software, tudo agrupado na mensalidade. Integração com serviço de assinatura STIR/SHAKEN faz parte do setup.

Estrutura de SLA. Metas de resposta e resolução por severidade, com créditos estruturados contra compromissos não cumpridos. Garantias de uptime definidas contra a configuração HA 1+1 inclusa.

Calibre do suporte. Suporte de primeiro contato Level 3 com engenheiros de telecomunicações baseados no Canadá com mais de 10 anos de experiência. Sem triagem de help desk com níveis. Um cliente de referência documentado no Brasil relatou tempos de resposta inferiores a cinco minutos.

Visibilidade do cliente. Os clientes mantêm acesso completo ao dashboard do ProSBC, CDRs, rastreamento de chamadas, monitoramento ao vivo e configuração. Alterações passam por um processo de gestão de mudanças. Métricas por NAP e por tronco estão disponíveis; a plataforma é construída sobre uma arquitetura B2BUA que expõe os dados necessários para observabilidade granular.

Flexibilidade de hospedagem. Hospedado pela TelcoBridges ou implantado BYOI em AWS, Azure, VMware, KVM/Proxmox ou hardware on-premises, a escolha do cliente. O mesmo serviço gerenciado se aplica a ambos os modelos de hospedagem.

Programabilidade. A API de roteamento Ruby permanece disponível sob serviço gerenciado. Integração aberta de parceiros com TransNexus ClearIP, Neustar, SecureLogix e YouMail. Compatibilidade confirmada com NetSapiens, PortaOne, FreePBX, 3CX, Cisco UCM, Genesys, Five9, NICE e outros.

Segurança e conformidade. TLS, SRTP, proteção DoS/DDoS com inspeção SIP, lista de bloqueio dinâmica com greylisting, defesa contra varredura de registro SIP, ocultação de topologia e escolha aberta de parceiro STIR/SHAKEN. O ProSBC suporta Microsoft Teams Direct Routing com tratamento de mTLS. Implantações BYOI na infraestrutura do cliente atendem GDPR e a maioria dos frameworks de residência de dados.

Termos de onboarding e saída. O setup normalmente leva dias a semanas com base na complexidade da integração. A configuração é portável: o ProSBC é a mesma plataforma de software seja gerenciado ou auto-hospedado, portanto a transição entre modelos é uma transferência de configuração em vez de uma troca de plataforma.