Integração de ERP, BSS e OSS em uma MVNO: o que precisa conversar

Uma MVNO precisa ligar a gestão comercial ao funcionamento da linha. O ERP conhece cliente, contrato e cobrança. O BSS organiza produtos, pedidos, faturamento e relacionamento. O OSS acompanha recursos, provisionamento e o estado técnico do serviço.

Os nomes e os limites variam entre plataformas, e numa operação menor um mesmo software pode cumprir várias dessas funções. O que importa é que os dados de cliente, plano, linha, SIM, consumo, status e financeiro continuem coerentes durante toda a jornada.

Sem essa integração, a empresa vende um plano num sistema, ativa outro na plataforma móvel e cobra um terceiro no financeiro. O cliente enxerga um único problema, e a marca é que responde por ele.

O que são ERP, BSS e OSS

ERP

O Enterprise Resource Planning concentra os processos da empresa. Em provedores de internet, costuma reunir cadastro, contratos, cobrança, estoque, ordens, fiscal e atendimento. Em varejo ou serviços financeiros, o escopo pode ser outro.

O ERP não precisa controlar a rede móvel, mas precisa receber informação suficiente para manter contrato, faturamento, conciliação e atendimento alinhados.

BSS

Business Support Systems são os sistemas voltados ao negócio e ao cliente de telecom: catálogo, CRM, pedido, cobrança, faturamento, pagamentos, receita, parceiros e autosserviço. Quando o cliente escolhe um plano, troca de oferta ou consulta a fatura, ele usa, direta ou indiretamente, capacidades de BSS.

OSS

Operational Support Systems sustentam a execução e o acompanhamento técnico: inventário de recursos, provisionamento, ativação, garantia de serviço, falhas e desempenho.

Numa MVNO credenciada, parte relevante do OSS pode estar na prestadora de origem ou no habilitador. Mesmo assim, a informação precisa chegar aos canais da marca, para que a equipe saiba se a linha está reservada, ativa, bloqueada ou cancelada.

Por que a integração é difícil

Sistemas de telecom trabalham com eventos assíncronos. Uma portabilidade pode ser pedida hoje e concluída depois. Um pagamento pode ser aprovado enquanto a ativação ainda processa. Uma plataforma pode aceitar a requisição e demorar a devolver o resultado final.

Entre "pedido recebido" e "operação concluída" existem estados intermediários. Se os sistemas só registram sucesso ou erro, a equipe perde visibilidade e acaba resolvendo os casos à mão.

A mesma relação também recebe identificadores diferentes:

• ID do cliente no ERP;
• ID do assinante na plataforma móvel;
• número telefônico;
• ICCID do SIM;
• EID ou outros identificadores do eSIM;
• ID do contrato;
• ID do pedido;
• código do plano;
• protocolo de portabilidade.

Uma boa arquitetura mantém o vínculo entre todos eles e permite rastrear cada alteração.

Defina a fonte de verdade

Para cada dado, escolha o sistema responsável por criar e governar o valor.

A tabela é um ponto de partida, e o desenho final depende dos sistemas usados. A regra que não pode faltar: dois sistemas não alteram o mesmo dado sem uma regra de precedência.

Fluxos que precisam ser integrados

Cadastro e validação

O cadastro coleta o que é necessário para contratar e ativar, respeitando finalidade e segurança. As validações devem devolver respostas claras: aprovado, pendente, recusado ou requer revisão.

Copiar o cadastro inteiro para todos os sistemas aumenta o risco e a divergência. Compartilhe só o necessário e guarde identificadores para consulta.

Pedido e ativação

Um fluxo robusto separa o pedido comercial da ativação técnica:

1. pedido criado;
2. pagamento ou elegibilidade confirmados;
3. recurso reservado;
4. ativação solicitada;
5. plataforma aceita a solicitação;
6. linha ativada;
7. sistemas conciliados;
8. cliente comunicado.

Se a etapa seis falhar, o pedido não pode sumir nem ser cobrado como concluído. Ele entra numa fila de tratamento com contexto suficiente para uma nova tentativa ou para intervenção.

Portabilidade

A portabilidade tem solicitação, confirmação, agendamento e conclusão, e o status precisa estar visível para o atendimento e para o cliente. Repetir a solicitação sem controle cria inconsistência. Cancelar localmente sem avisar a plataforma deixa o processo ativo.

Consumo

Os dados de consumo podem chegar com atraso em relação ao uso real. O aplicativo deve informar a natureza da atualização e não prometer tempo real quando o fornecedor não entrega essa capacidade.

Cobrança e inadimplência

O financeiro precisa saber quando começar e quando parar de cobrar. A plataforma móvel, por sua vez, precisa receber ações compatíveis com as regras comerciais e regulatórias na inadimplência e na regularização.

Uma falha comum é bloquear o contrato no ERP e não bloquear a linha, porque a chamada à API falhou. A documentação do IXC, por exemplo, alerta que uma alteração local pode acontecer sem efeito na plataforma externa. Esse tipo de falha pede alerta e conciliação, e não pode passar em silêncio.

Troca de plano, SIM e aparelho

As mudanças devem ser transacionais. Antes de confirmar ao cliente, verifique se a plataforma aceitou a operação e se a data de vigência foi registrada. Trocas de SIM e reemissões de eSIM também exigem controles de identidade e de fraude.

Cancelamento

O cancelamento coordena contrato, cobrança, benefícios e linha. A ordem das ações importa: ela evita cobrança depois do desligamento e a perda precoce de informações que a auditoria pode precisar.

APIs: o que avaliar além da existência

Perguntar "tem API?" não basta. Avalie:

• operações disponíveis;
• autenticação e rotação de credenciais;
• limites de uso;
• ambientes de teste;
• documentação e exemplos;
• códigos de erro;
• repetição segura de requisições;
• notificações ou webhooks;
• consulta de status;
• versionamento;
• suporte e prazo para mudanças;
• exportação de dados e auditoria.

O TM Forum mantém Open APIs para interoperabilidade em telecom, com domínios como cliente, catálogo, pedido e inventário. Uma solução não precisa implementar todos esses padrões para funcionar, mas referências comuns reduzem o acoplamento e deixam as responsabilidades mais claras.

Idempotência e conciliação

Idempotência quer dizer que repetir a mesma solicitação não produz efeitos duplicados. Ela é fundamental em ativação, cobrança, recarga e cancelamento.

Cada comando relevante recebe um identificador único. Se houver timeout, o sistema consulta o resultado antes de reenviar. Quando a repetição for necessária, a plataforma reconhece que se trata da mesma operação.

Além do fluxo em tempo real, faça conciliações periódicas de:

• linhas ativas na plataforma e no ERP;
• planos contratados e provisionados;
• SIMs em estoque e associados;
• cobranças emitidas e serviços ativos;
• cancelamentos pendentes;
• portabilidades sem atualização;
• eventos com erro.

A conciliação é o controle que sistemas distribuídos e fornecedores diferentes exigem.

Segurança e LGPD

Integrações movimentam dados pessoais, financeiros e de uso. Os controles devem incluir:

• criptografia em trânsito;
• credenciais fora do código e com rotação;
• menor privilégio;
• registros de acesso e alteração;
• mascaramento de dados em suporte e logs;
• separação entre produção e teste;
• retenção definida;
• resposta a incidentes;
• avaliação de fornecedores;
• base legal e transparência ao titular.

Não copie dados reais para ambientes de homologação sem proteção. Evite também registrar documentos completos, tokens ou códigos de ativação em logs de fácil acesso.

Observabilidade: saber antes do cliente

A integração deve emitir métricas e alertas. Alguns indicadores:

• taxa de sucesso por operação;
• tempo de resposta da API;
• pedidos pendentes por estado;
• idade do evento mais antigo na fila;
• divergências de conciliação;
• falhas de webhook;
• ativações por intervenção manual;
• incidentes por fornecedor;
• impacto em clientes.

Uma operação madura descobre que as ativações estão se acumulando antes de receber dezenas de contatos.

Exemplo para um provedor de internet

Imagine um assinante que já tem fibra e contrata uma linha móvel:

1. o ERP reaproveita o cadastro existente, com confirmação dos dados;
2. o cliente escolhe um plano associado ao contrato;
3. a integração envia o pedido à plataforma móvel;
4. um SIM disponível é associado ou um eSIM é emitido;
5. a plataforma devolve número e status;
6. o ERP registra os identificadores;
7. a cobrança entra no ciclo correto;
8. o cliente acompanha a linha no portal;
9. o atendimento vê banda larga e móvel no mesmo contexto.

Se o cliente cancelar só a linha móvel, o contrato de fibra continua. Se ficar inadimplente, as regras e os impactos de cada serviço seguem o produto, o contrato e a regulação. Isso pede modelagem, e uma chamada de API sozinha não resolve.

Para ver esse cenário do ponto de vista do negócio, leia provedor de internet pode oferecer telefonia móvel?.

Como testar

Crie cenários com resultado esperado e evidência:

• ativação de número novo;
• portabilidade confirmada e recusada;
• timeout depois de pedido aceito;
• repetição da mesma requisição;
• pagamento aprovado e ativação com falha;
• linha ativa e cobrança ausente;
• bloqueio com API indisponível;
• regularização;
• troca de SIM e eSIM;
• cancelamento parcial de combo;
• dados divergentes;
• recuperação depois de indisponibilidade.

Teste também permissões e logs. Um fluxo que funciona ainda pode ser inseguro se qualquer atendente conseguir emitir um novo eSIM sem validação ou ver credenciais sensíveis.

A integração faz parte do produto

O cliente não conhece ERP, BSS ou OSS. Ele vê uma marca que vende, ativa, cobra e atende, e a arquitetura deve sustentar essa experiência.

Antes de lançar, defina fontes de verdade, estados, responsabilidades, tratamento de erro e conciliação. Isso reduz o trabalho manual e protege a experiência conforme a base cresce.

Para encaixar a integração no projeto completo, leia como criar uma MVNO no Brasil.

Se a sua empresa precisa conectar a operação móvel ao ambiente que já usa, a Mood Mobile (abre em nova aba) pode ajudar a mapear o escopo e as integrações do projeto.

Fontes e referências

• TM Forum — Open APIs (abre em nova aba)
• TM Forum — modernização de BSS e OSS (abre em nova aba)
• TM Forum — caso de uso de pedidos móveis pós-pagos (abre em nova aba)
• IXC Soft — integrações de telefonia móvel (abre em nova aba)
• IXC Soft — parâmetro de comunicação por API (abre em nova aba)
• Anatel — Resolução nº 777/2025 (abre em nova aba)
• ANPD — legislação de proteção de dados, incluindo a Lei nº 13.709/2018 (abre em nova aba)

Conteúdo revisado em 30 de outubro de 2026. A arquitetura e as responsabilidades variam conforme modelo regulatório, contratos e plataformas adotadas.