Muita gente adiciona um novo país com a frase «vamos ver pelo caminho» e sem plano — e um mês depois o orçamento acabou e o mercado nunca confirmou sua rentabilidade. Uma semana de piloto só funciona com um plano rígido por dias: não uma lista de ações, mas um critério de conclusão em cada etapa, depois do qual você pode avançar ou parar. Vamos ver o plano de lançamento de um mercado em uma semana, onde o prazo costuma quebrar e o que deve ser o sinal para encerrar o piloto em vez de ficar ajustando.

Dia 1–2: verificar a presença do país nos catálogos

O primeiro passo não é calcular o orçamento, mas checar a disponibilidade técnica: o país precisa estar no catálogo de números para verificação, e o catálogo de proxies precisa ter os tipos de endereço necessários, não apenas a opção de datacenter. O critério de conclusão não é «o país está na lista», mas a entrega confirmada: o pedido de código de teste passou em vários serviços, em vez de ficar travado na espera.

Verifique também quais canais existem de fato para o país: em alguns lugares não há endereços móveis, apenas residenciais e de datacenter, e isso muda o cálculo do orçamento. Em mercados como o Vietnã, o pool móvel costuma ser bem mais restrito que o residencial — vale registrar isso logo, e não no meio da carga total.

Dia 2–3: montar um circuito consistente

O circuito é a combinação «número + endereço IP + idioma da interface», que precisa parecer coerente para a plataforma. Juntar um número de um país com um proxy de outro é tecnicamente mais simples, mas o risco não aparece de imediato: surge na segunda ou terceira ação na conta. A verificação do ASN do endereço recebido é obrigatória: o endereço deve pertencer a um provedor do país certo, e não apenas exibir o código desejado na base de geolocalização.

Critério de conclusão: o país do número, o país e o ASN do IP e o idioma da interface coincidem em um mesmo perfil de teste, e não só no papel.

Dia 3–4: verificação de teste e medição da taxa de entrega

Antes de incluir o mercado no plano, é preciso um lote de teste — de 20 a 50 verificações, e não uma única tentativa bem-sucedida. Um único código recebido não diz nada sobre estabilidade: a taxa de entrega se mede em porcentagem. A referência de trabalho é não menos que 85–90% de códigos entregues no lote de teste; qualquer coisa abaixo indica um pool de números instável e um motivo para rever o fornecedor antes mesmo do lançamento.

Critério de conclusão: a porcentagem de entrega foi registrada em uma amostra comparável à carga real, e não em três tentativas manuais.

Dia 4–5: checar o conteúdo local e calcular o orçamento

O conteúdo local é verificado separadamente da entrega do código: o site deve mostrar conteúdo, preços e disponibilidade como um morador local os vê, e não uma versão genérica. Sem medir as métricas de qualidade do proxy, a divergência passa despercebida — ela aparece não no cadastro, mas depois, em uma ação-alvo que depende de conteúdo local.

O orçamento se calcula a partir do volume da tarefa, e não do número de endereços: reserve tráfego para os cenários reais e uma margem para novas tentativas, inevitáveis mesmo com boa taxa de entrega. Critério de conclusão: foi calculado o custo de um perfil confirmado, e não apenas o preço do número ou do gigabyte separadamente.

Dia 6–7: lançamento, primeira revisão e onde o prazo costuma quebrar

O lançamento em carga total só começa depois que os quatro primeiros itens foram concluídos com números, e não «no olho». Em seguida, uma revisão curta com os resultados do primeiro dia: a taxa de entrega no volume real é comparada com a do lote de teste, o custo do perfil com o calculado e o conteúdo local com o esperado.

O prazo escorrega com mais frequência em uma única etapa — a verificação de teste: a equipe ou pula essa etapa e vai direto para a carga total, ou a estica por cinco dias porque o lote de teste é pequeno demais. A segunda causa de fracasso é calcular o orçamento pela média do catálogo, e não pelo dado real do país específico: a diferença entre mercados chega a ser de várias vezes. Se o piloto for conduzido por uma equipe externa, confirme à parte que os acessos às contas estão em seu nome, e não nos dados pessoais dela — o procedimento está descrito no artigo como não perder contas ao trocar de prestador.

Considere fracasso do piloto não uma falha isolada, mas um resultado sistêmico: taxa de entrega abaixo do limite em volume total, e não só no lote de teste, ou custo do perfil acima do planejado em uma vez e meia ou mais por vários dias seguidos. Nesse caso, a decisão é encerrar o mercado, e não continuar ajustando: o ajuste fino faz sentido diante de um problema local — um fornecedor, um tipo de endereço —, mas não quando o país inteiro falha sistematicamente na verificação.

Perguntas frequentes

Dá para reduzir a semana de piloto para três dias?

Dá, se o país já foi testado em um mercado vizinho e há dados de taxa de entrega dos últimos meses. Para um país novo, sem histórico, reduzir a verificação de teste é arriscado: uma amostra pequena não distingue uma falha temporária de um problema sistêmico do pool.

A taxa de entrega no lote de teste está boa, mas o orçamento não fecha — o que fazer?

Olhar o custo real de um perfil confirmado naquele país, e não a tarifa média do catálogo: a diferença entre mercados em preço e novas tentativas pode ser de várias vezes. Se, depois de recalcular, a conta não fechar, isso por si só é motivo para encerrar o mercado.

Vale já deixar um fornecedor reserva de números?

Sim, principalmente para países sem um histórico longo. A alternativa é testada no mesmo período de teste que a principal — assim, a troca diante de uma queda na taxa de entrega leva horas, e não vira uma etapa separada depois do fracasso do piloto.

Para a verificação de teste e para escalar o mercado, use os números OTP da turbon.rent — o catálogo cobre os países necessários, e a taxa de entrega de cada mercado fica visível já na etapa do lote de teste.