Jidá sedia a 27ª Copa do Golfo Arábico de 23 de setembro a 6 de outubro de 2026, com oito seleções nacionais divididas em dois grupos, jogando no Estádio da Cidade Esportiva Rei Abdullah e no Estádio Príncipe Abdullah Al-Faisal. É uma notícia esportiva e, para a maioria das pessoas, termina aí.

Dentro dela há uma história operacional que diz respeito a cada restaurante, hotel, loja, empresa de transporte e clínica em Jidá e arredores. Durante duas semanas inteiras muda o perfil do cliente que está diante do seu caixa. As seleções participantes vêm do Iraque, Omã, Kuwait, Emirados Árabes Unidos, Catar, Bahrein e Iêmen, e cada uma traz uma torcida com números de celular que começam com 964, 968, 965, 971, 974, 973 e 967. Sete códigos de país diferentes daquele em torno do qual os seus sistemas foram construídos.

A suposição silenciosa por trás da maioria dos sistemas sauditas

Pelo plano nacional de numeração do Reino, um número de celular local começa com 05 e tem dez dígitos. É um fato regulatório claro e não é o problema. O problema é como esse fato migrou para o código como uma regra de validação rígida: um campo que recusa qualquer entrada que não corresponda a dez dígitos começando com zero cinco.

A regra parece correta porque funciona para 99% dos clientes o ano inteiro. Então chega uma quinzena como esta e a regra deixa de ser proteção e vira uma porta trancada. A diferença importa: a proteção recusa dados inválidos, enquanto essa regra recusa um cliente real tentando pagar você.

Pior: o padrão não vive só no campo de telefone. Ele se repete em todo lugar onde um desenvolvedor presumiu que o cliente era residente na Arábia Saudita:

  • O campo de celular. Uma validação presa ao 05, ou a um tamanho fixo de dez dígitos, recusa um número do Golfo antes mesmo de ele chegar ao seu servidor.
  • O código de verificação. Mesmo que o campo aceite o número, o seu provedor de mensagens pode não ter o envio internacional ativado na sua conta, e o cliente digita o número e espera uma mensagem que nunca chega.
  • A página de pagamento. Um gateway configurado apenas para Mada. O visitante tem um cartão emitido por um banco do Golfo em uma bandeira internacional e vê uma recusa que não consegue explicar.
  • O campo de identificação. Um número obrigatório de identidade nacional ou de residência, com dez dígitos, começando com um ou dois. O visitante tem um passaporte, e o formulário não oferece uma terceira opção.
  • O endereço. Uma lista fechada só com cidades sauditas e um CEP obrigatório no formato local, dentro de um formulário que nem precisa de endereço, porque o pedido é retirado na loja.
  • O idioma. Uma interface só em árabe em um caminho crítico como reserva ou pagamento. Os visitantes do Golfo leem árabe, mas uma parte da torcida que viaja e das pessoas que a acompanham não lê.

Por que nada disso aparece nos seus relatórios

É aqui que está o perigo real. Quando o seu formulário recusa o número de um visitante, nada mensurável acontece. Não há pedido com falha no painel, nenhum erro nos logs, nenhum chamado de suporte. O cliente tenta duas vezes, fecha a aba e vai para o concorrente cujo formulário aceitou o número. Você vê o resultado como um número de vendas um pouco abaixo do esperado em uma semana movimentada e o explica com qualquer outra explicação.

Os sistemas registram o sucesso com excelente nível de detalhe e ficam calados sobre o que falhou antes de começar. Um pedido concluído deixa um rastro completo do primeiro clique até a nota fiscal, enquanto um visitante barrado pela validação no navegador nunca chegou ao servidor para deixar vestígio. Por isso a primeira correção aqui não está no formulário, e sim na medição: registre as falhas de validação como um evento próprio, com o nome do campo e o motivo da recusa, sem armazenar o que foi digitado. Uma semana disso mostra exatamente qual campo está recusando clientes, e é o mesmo tipo de visibilidade que abordamos em o ponto único de falha que você não enxerga na sua arquitetura.

O que dá para corrigir de verdade antes de 23 de setembro

Cinco dias não bastam para reconstruir um sistema, mas são mais do que suficientes para remover as seis barreiras acima, porque a maioria delas é configuração, não desenvolvimento. A ordem abaixo vai do maior impacto para o menor:

  • Abra o campo de celular para o formato internacional. Um seletor de código de país com a Arábia Saudita como padrão, e números armazenados em um único formato internacional canônico que começa com sinal de mais. É uma mudança em uma única camada e resolve o problema para todos os países, não apenas para sete.
  • Teste o envio da verificação para um número real do Golfo antes do torneio. Não presuma que está ativado. Envie um código para um número real de um país participante e confirme que ele chega em segundos. O teste leva minutos e revela uma falha que custaria uma quinzena.
  • Ative cartões internacionais e carteiras digitais. Confirme com o seu provedor de pagamentos quais bandeiras estão realmente ativas na sua conta, não quais estão disponíveis em teoria no seu plano. Adicione uma opção de carteira digital se ainda não tiver, porque é o caminho mais rápido para um visitante que não vai digitar o número do cartão em um site que nunca usou.
  • Torne o campo de identificação opcional ou acrescente a alternativa do passaporte. Se o campo existe por exigência legal, diga isso ao lado dele e aceite o formato de passaporte. Se existe por costume, apague-o nesta semana.
  • Liberte o endereço da lista fechada. Transforme a cidade em campo de texto livre e o CEP em opcional, principalmente em pedidos que não envolvem entrega.
  • Traduza apenas o caminho crítico. O cardápio ou a lista de produtos, as etapas de reserva, a página de pagamento e a página de como chegar. Você não precisa do site inteiro traduzido até terça-feira. Precisa que o visitante consiga comprar.

Logo depois das correções vem a questão da capacidade. Esse pico não se distribui ao longo do dia, mas se concentra em duas janelas curtas antes e depois de cada jogo, o que se comporta de forma muito parecida com o padrão que descrevemos em o dia do pagamento e o pico cuja data você já conhece, com uma diferença: essa torcida também se desloca geograficamente, em uma única direção, ao mesmo tempo.

Os dados que você vai coletar durante a quinzena

Um visitante de fora do Reino que se cadastra no seu sistema significa dados pessoais sujeitos à Lei de Proteção de Dados Pessoais (PDPL), exatamente como os dados de um cliente local. O ponto prático é simples: não colete um campo que você não vai usar. Cada campo extra adicionado a um formulário feito às pressas é uma obrigação que fica com você por meses depois que o torneio termina.

Informe na sua página de privacidade o que você coleta, por que e por quanto tempo guarda, em uma linguagem que o visitante entenda, e não em um texto jurídico copiado. Quem se cadastra com você uma única vez em uma quinzena não vai ler dez parágrafos, mas vai perceber se você pedir um número de identidade nacional para reservar uma mesa.

A visão da Origami

Encontramos esse padrão com frequência ao revisar sistemas existentes: uma regra de validação escrita três anos atrás para uma situação que era verdadeira na época e que depois ficou no código como uma decisão permanente que ninguém revisitou. A falha não é um desenvolvedor ter errado. É que a suposição nunca foi escrita em lugar nenhum que pudesse ser revisado, então virou parte da estrutura em vez de uma configuração.

É por isso que, quando construímos um sistema, separamos as regras de validação do código e as tratamos como configuração, e sempre armazenamos os números de celular no formato internacional, mesmo quando todos os clientes de hoje são locais. O custo na hora de construir é quase zero. O custo dois anos depois, quando você abre uma filial em Dammam que atende visitantes do Bahrein, ou quando um torneio chega à sua cidade, é a diferença entre uma hora de configuração e um projeto de mudança medido em semanas. Aplicamos o mesmo princípio em tudo o que construímos dentro dos nossos serviços: uma suposição que vale hoje é escrita como configuração, não como uma condição em uma linha de código.

O que sobrevive a 6 de outubro

O torneio termina no dia seis de outubro. A parte que você corrigiu, não. O Reino recebe grandes eventos de forma contínua, e temporadas, conferências e torneios agora são parte permanente do calendário, e não uma exceção nele. Um sistema que aceita hoje um visitante de fora do Reino vai aceitá-lo no próximo evento sem nenhum trabalho adicional.

Comece nesta semana pelo menor passo executável: abra o seu site ou aplicativo e tente concluir uma compra completa usando um número de celular real do Golfo e um cartão não saudita. Se funcionar, você está pronto. Se você parar em algum campo, acabou de descobrir por onde duas semanas de vendas iam escapar.

Fontes