Yeda acoge la 27.ª Copa de Naciones del Golfo Arábigo del 23 de septiembre al 6 de octubre de 2026, con ocho selecciones nacionales repartidas en dos grupos, que juegan en el estadio de la Ciudad Deportiva Rey Abdullah y en el estadio Príncipe Abdullah Al-Faisal. Es una noticia deportiva y, para la mayoría de la gente, termina ahí.

Dentro de ella hay una historia operativa que afecta a cada restaurante, hotel, tienda, empresa de transporte y clínica de Yeda y sus alrededores. Durante dos semanas completas cambia el perfil del cliente que tienes delante en tu caja. Los equipos participantes vienen de Irak, Omán, Kuwait, los Emiratos Árabes Unidos, Catar, Baréin y Yemen, y cada uno trae una afición con números de móvil que empiezan por 964, 968, 965, 971, 974, 973 y 967. Siete prefijos de país distintos del que sirvió de base para construir tus sistemas.

La suposición silenciosa que hay debajo de la mayoría de los sistemas saudíes

Según el plan nacional de numeración del Reino, un número de móvil local empieza por 05 y tiene diez dígitos. Es un hecho regulatorio claro y no es el problema. El problema es cómo ese hecho pasó al código como una regla de validación rígida: un campo que rechaza cualquier entrada que no coincida con diez dígitos que empiezan por cero cinco.

La regla parece correcta porque funciona para el 99 % de los clientes durante todo el año. Luego llega una quincena como esta y la regla deja de ser una protección para convertirse en una puerta cerrada. La diferencia importa: una protección rechaza datos erróneos, mientras que esta regla rechaza a un cliente real que intenta pagarte.

Peor aún, el patrón no vive solo en el campo del teléfono. Se repite en todos los lugares donde un desarrollador supuso que el cliente era residente en Arabia Saudí:

  • El campo del móvil. Una validación anclada a 05, o a una longitud fija de diez dígitos, rechaza un número del Golfo antes de que llegue a tu servidor.
  • El código de verificación. Aunque el campo acepte el número, puede que tu proveedor de mensajería no tenga activado el envío internacional en tu cuenta, así que el cliente introduce un número y espera un mensaje que nunca llega.
  • La página de pago. Una pasarela configurada solo para Mada. El visitante tiene una tarjeta emitida por un banco del Golfo en una red internacional y ve un rechazo que no puede explicar.
  • El campo de identificación. Un número de identidad nacional o de residencia obligatorio de diez dígitos que empieza por uno o por dos. El visitante tiene un pasaporte, y el formulario no ofrece una tercera opción.
  • La dirección. Una lista cerrada que contiene solo ciudades saudíes y un código postal obligatorio en formato local, dentro de un formulario que no necesita dirección alguna porque el pedido se recoge en la sucursal.
  • El idioma. Una interfaz solo en árabe en una ruta crítica como la reserva o el pago. Los visitantes del Golfo leen árabe, pero una parte de la afición que viaja y de quienes la acompañan no.

Por qué nada de esto aparece en tus informes

Aquí está el verdadero peligro. Cuando tu formulario rechaza el número de un visitante, no ocurre nada medible. No hay ningún pedido fallido en el panel, ningún error en los registros, ninguna incidencia de soporte. El cliente lo intenta dos veces, cierra la pestaña y se va a la competencia cuyo formulario aceptó el número. Tú ves el resultado como una cifra de ventas algo inferior a la esperada en una semana de mucho movimiento, y la atribuyes a cualquier otra causa.

Los sistemas registran el éxito con un detalle excelente y guardan silencio sobre lo que falló antes de empezar. Un pedido completado lleva un rastro completo desde el primer clic hasta la factura, mientras que un visitante detenido por la validación en el navegador nunca llegó al servidor para dejar huella. Por eso la primera corrección aquí no está en el formulario, sino en la medición: registra los fallos de validación como un evento propio, con el nombre del campo y el motivo del rechazo, sin guardar la entrada en sí. Una semana de esto te dice exactamente qué campo está rechazando clientes, y es el mismo tipo de visibilidad que tratamos en el punto único de fallo que no ves en tu arquitectura.

Qué se puede corregir de verdad antes del 23 de septiembre

Cinco días no bastan para reconstruir un sistema, pero son más que suficientes para eliminar las seis barreras anteriores, porque la mayoría son de configuración y no de desarrollo. El orden siguiente va de mayor a menor impacto:

  • Abre el campo del móvil al formato internacional. Un selector de prefijo de país que por defecto muestre Arabia Saudí y números guardados en un único formato internacional canónico que empieza por un signo más. Es un cambio en una sola capa y resuelve el problema para todos los países, no solo para siete.
  • Prueba el envío de la verificación a un número real del Golfo antes del torneo. No des por hecho que está activado. Envía un código a un número real de un país participante y confirma que llega en segundos. La prueba lleva minutos y revela un fallo que te costaría una quincena.
  • Activa las tarjetas internacionales y los monederos móviles. Comprueba con tu proveedor de pagos qué redes están realmente activas en tu cuenta, no cuáles están disponibles en teoría en tu plan. Añade una opción de monedero si no la tienes, ya que es la vía más rápida para un visitante que no escribirá el número de su tarjeta en un sitio que nunca ha usado.
  • Haz opcional el campo de identificación o añade la alternativa del pasaporte. Si el campo existe por un motivo legal, dilo junto a él y acepta el formato de pasaporte. Si existe por costumbre, elimínalo esta semana.
  • Libera la dirección de la lista cerrada. Convierte la ciudad en un campo de texto libre y el código postal en opcional, sobre todo en los pedidos que no implican entrega.
  • Traduce solo la ruta crítica. El menú o la lista de productos, los pasos de reserva, la página de pago y la página de indicaciones. No necesitas todo el sitio traducido para el martes. Necesitas que el visitante pueda comprar.

Justo después de las correcciones viene la cuestión de la capacidad. Este pico no se reparte a lo largo del día, sino que se concentra en dos franjas cortas antes y después de cada partido, lo que se comporta de forma muy parecida al patrón que describimos en el día de pago y el pico cuya fecha ya conoces, con una diferencia: esta afición además se desplaza geográficamente, en una sola dirección, al mismo tiempo.

Los datos que recogerás durante la quincena

Un visitante de fuera del Reino que se registra en tu sistema implica datos personales sujetos a la Ley de Protección de Datos Personales (PDPL), exactamente igual que los datos de un cliente local. El punto práctico es sencillo: no recojas un campo que no vayas a usar. Cada campo extra añadido a un formulario hecho con prisas es una obligación que te acompaña durante meses después de que termine el torneo.

Indica en tu página de privacidad qué recoges, por qué y durante cuánto tiempo lo conservas, en un lenguaje que el visitante entienda y no con fórmulas legales copiadas. Alguien que se registra contigo una sola vez en una quincena no leerá diez párrafos, pero sí notará si le pides un número de identidad nacional para reservar una mesa.

La visión de Origami

Encontramos este patrón a menudo al revisar sistemas existentes: una regla de validación escrita hace tres años para una situación que entonces era cierta y que luego se quedó en el código como una decisión permanente que nadie volvió a revisar. El fallo no es que un desarrollador se equivocara. Es que la suposición nunca se escribió en ningún sitio revisable, así que pasó a formar parte de la estructura en lugar de ser un ajuste.

Por eso, cuando construimos un sistema, separamos las reglas de validación del código y las tratamos como configuración, y siempre guardamos los números de móvil en formato internacional aunque hoy todos los clientes sean locales. El coste en el momento de construir es casi nulo. El coste dos años después, cuando abres una sucursal en Dammam que atiende a visitantes de Baréin, o cuando llega un torneo a tu ciudad, es la diferencia entre una hora de configuración y un proyecto de cambio que se mide en semanas. Aplicamos el mismo principio en todo lo que construimos dentro de nuestros servicios: una suposición que hoy es válida se escribe como un ajuste, no como una condición en una línea de código.

Lo que sobrevive al 6 de octubre

El torneo termina el seis de octubre. Lo que corregiste, no. El Reino acoge grandes eventos de forma continua, y las temporadas, los congresos y los torneos son ya un elemento permanente del calendario y no una excepción en él. Un sistema que hoy acepta a un visitante de fuera del Reino lo aceptará en el próximo evento sin trabajo adicional.

Empieza esta semana por el paso ejecutable más pequeño: abre tu sitio o tu aplicación e intenta completar una compra entera con un número de móvil real del Golfo y una tarjeta no saudí. Si funciona, estás preparado. Si te detienes en un campo concreto, acabas de encontrar por dónde se iban a ir dos semanas de ventas.

Fuentes