Dschidda richtet vom 23. September bis 6. Oktober 2026 den 27. Arabischen Golfpokal aus, mit acht Nationalmannschaften in zwei Gruppen, die im Stadion der King Abdullah Sports City und im Prinz-Abdullah-Al-Faisal-Stadion spielen. Das ist eine Sportnachricht, und für die meisten Menschen endet sie dort.

Darin steckt jedoch eine operative Geschichte, die jedes Restaurant, jedes Hotel, jedes Geschäft, jedes Transportunternehmen und jede Klinik in und um Dschidda betrifft. Zwei volle Wochen lang verändert sich, wer als Kunde vor Ihrer Kasse steht. Die teilnehmenden Mannschaften kommen aus dem Irak, Oman, Kuwait, den Vereinigten Arabischen Emiraten, Katar, Bahrain und dem Jemen, und jede bringt Fans mit, deren Mobilnummern mit 964, 968, 965, 971, 974, 973 und 967 beginnen. Sieben Ländervorwahlen außer der einen, für die Ihre Systeme gebaut wurden.

Die stille Annahme, auf der die meisten saudischen Systeme beruhen

Nach dem nationalen Nummerierungsplan des Königreichs beginnt eine lokale Mobilnummer mit 05 und hat zehn Ziffern. Das ist eine klare regulatorische Tatsache, und sie ist nicht das Problem. Das Problem ist, wie diese Tatsache als starre Validierungsregel in den Code gewandert ist: ein Feld, das jede Eingabe abweist, die nicht aus zehn Ziffern besteht, die mit null fünf beginnen.

Die Regel wirkt richtig, weil sie das ganze Jahr über für 99 Prozent der Kunden funktioniert. Dann kommen zwei Wochen wie diese, und die Regel ist kein Schutz mehr, sondern eine verschlossene Tür. Der Unterschied ist wichtig: Schutz weist fehlerhafte Eingaben ab, diese Regel dagegen weist einen echten Kunden ab, der Sie bezahlen will.

Schlimmer noch: Das Muster steckt nicht nur im Telefonfeld. Es wiederholt sich überall dort, wo ein Entwickler angenommen hat, der Kunde sei in Saudi-Arabien ansässig:

  • Das Mobilnummernfeld. Eine Validierung, die an 05 oder an eine feste Länge von zehn Ziffern gebunden ist, weist eine Nummer aus dem Golf ab, bevor sie überhaupt Ihren Server erreicht.
  • Der Bestätigungscode. Selbst wenn das Feld die Nummer akzeptiert, hat Ihr Messaging-Anbieter den internationalen Versand für Ihr Konto möglicherweise nicht aktiviert, sodass der Kunde eine Nummer eingibt und auf eine Nachricht wartet, die nie ankommt.
  • Die Zahlungsseite. Ein Gateway, das nur für Mada konfiguriert ist. Der Besucher hat eine Karte einer Bank aus dem Golf in einem internationalen Kartennetz und sieht eine Ablehnung, die er sich nicht erklären kann.
  • Das Ausweisfeld. Eine verpflichtende zehnstellige nationale Ausweis- oder Aufenthaltsnummer, die mit einer Eins oder einer Zwei beginnt. Der Besucher hat einen Reisepass, und das Formular bietet keine dritte Option.
  • Die Adresse. Eine geschlossene Liste mit ausschließlich saudischen Städten und eine verpflichtende Postleitzahl im lokalen Format, in einem Formular, das überhaupt keine Adresse braucht, weil die Bestellung in der Filiale abgeholt wird.
  • Die Sprache. Eine rein arabische Oberfläche auf einem kritischen Pfad wie Buchung oder Zahlung. Besucher aus dem Golf lesen Arabisch, ein Teil der reisenden Fans und ihrer Begleiter jedoch nicht.

Warum nichts davon in Ihren Berichten auftaucht

Hier liegt die eigentliche Gefahr. Wenn Ihr Formular die Nummer eines Besuchers abweist, passiert nichts Messbares. Keine fehlgeschlagene Bestellung im Dashboard, kein Fehler in den Logs, kein Support-Ticket. Der Kunde versucht es zweimal, schließt den Tab und geht zum Wettbewerber, dessen Formular die Nummer akzeptiert hat. Sie sehen das Ergebnis als Umsatzzahl, die in einer geschäftigen Woche etwas unter Ihren Erwartungen liegt, und erklären sie mit irgendeiner anderen Erklärung.

Systeme protokollieren Erfolg sehr detailliert und schweigen über das, was scheiterte, bevor es begann. Eine abgeschlossene Bestellung hinterlässt eine vollständige Spur vom ersten Klick bis zur Rechnung, während ein Besucher, den die Validierung im Browser gestoppt hat, den Server nie erreicht und keine Spur hinterlassen hat. Deshalb liegt die erste Korrektur hier nicht im Formular, sondern in der Messung: Protokollieren Sie Validierungsfehler als eigenes Ereignis, mit dem Feldnamen und dem Grund der Abweisung, ohne die Eingabe selbst zu speichern. Eine Woche davon zeigt Ihnen genau, welches Feld Kunden abweist, und es ist dieselbe Art von Transparenz, die wir in dem Single Point of Failure, den Sie in Ihrer Architektur nicht sehen, behandelt haben.

Was sich vor dem 23. September tatsächlich beheben lässt

Fünf Tage reichen nicht, um ein System neu zu bauen, aber sie reichen mehr als aus, um die sechs oben genannten Hürden zu beseitigen, denn die meisten davon sind Konfiguration und keine Entwicklung. Die folgende Reihenfolge geht von der größten Wirkung abwärts:

  • Öffnen Sie das Mobilnummernfeld für das internationale Format. Eine Auswahl der Ländervorwahl, die standardmäßig auf Saudi-Arabien steht, und Nummern, die in einem einheitlichen internationalen Format mit führendem Pluszeichen gespeichert werden. Das ist eine Änderung in einer einzigen Schicht, und sie löst das Problem für jedes Land statt für sieben.
  • Testen Sie die Zustellung der Bestätigung an eine echte Nummer aus dem Golf vor dem Turnier. Gehen Sie nicht davon aus, dass sie aktiviert ist. Senden Sie einen Code an eine echte Nummer in einem teilnehmenden Land und prüfen Sie, ob er innerhalb von Sekunden ankommt. Der Test dauert Minuten und deckt einen Fehler auf, der Sie zwei Wochen kosten würde.
  • Aktivieren Sie internationale Karten und mobile Wallets. Klären Sie mit Ihrem Zahlungsanbieter, welche Kartennetze auf Ihrem Konto tatsächlich freigeschaltet sind, nicht welche in Ihrem Tarif theoretisch verfügbar sind. Fügen Sie eine Wallet-Option hinzu, falls Sie keine haben, denn das ist der schnellste Weg für einen Besucher, der keine Kartennummer auf einer Website eingibt, die er noch nie benutzt hat.
  • Machen Sie das Ausweisfeld optional oder ergänzen Sie den Reisepass als Alternative. Wenn das Feld aus einem gesetzlichen Grund existiert, schreiben Sie das daneben und akzeptieren Sie ein Reisepassformat. Wenn es aus Gewohnheit existiert, löschen Sie es diese Woche.
  • Befreien Sie die Adresse von der geschlossenen Liste. Machen Sie die Stadt zu einem Freitextfeld und die Postleitzahl optional, besonders bei Bestellungen ohne Lieferung.
  • Übersetzen Sie nur den kritischen Pfad. Die Speisekarte oder Produktliste, die Buchungsschritte, die Zahlungsseite und die Anfahrtsseite. Sie brauchen nicht bis Dienstag die ganze Website übersetzt. Sie brauchen einen Besucher, der kaufen kann.

Direkt nach den Korrekturen kommt die Frage der Kapazität. Diese Spitze verteilt sich nicht über den Tag, sondern konzentriert sich auf zwei kurze Zeitfenster vor und nach jedem Spiel, was sich sehr ähnlich verhält wie das Muster, das wir in dem Zahltag und der Spitze, deren Datum Sie bereits kennen, beschrieben haben, mit einem Unterschied: Diese Menge bewegt sich zusätzlich geografisch, in eine Richtung, zur selben Zeit.

Die Daten, die Sie in diesen zwei Wochen erheben

Ein Besucher von außerhalb des Königreichs, der sich in Ihrem System registriert, bedeutet personenbezogene Daten, die dem Gesetz zum Schutz personenbezogener Daten (PDPL) unterliegen, genau wie die Daten eines lokalen Kunden. Der praktische Punkt ist einfach: Erheben Sie kein Feld, das Sie nicht nutzen werden. Jedes zusätzliche Feld in einem eilig gebauten Formular ist eine Verpflichtung, die Sie noch Monate nach dem Ende des Turniers begleitet.

Geben Sie auf Ihrer Datenschutzseite an, was Sie erheben, warum und wie lange Sie es aufbewahren, in einer Sprache, die der Besucher versteht, statt in kopierten juristischen Standardformulierungen. Jemand, der sich in zwei Wochen ein einziges Mal bei Ihnen registriert, liest keine zehn Absätze, aber er merkt, wenn Sie für eine Tischreservierung eine nationale Ausweisnummer verlangen.

Die Sicht von Origami

Wir begegnen diesem Muster häufig, wenn wir bestehende Systeme prüfen: eine Validierungsregel, die vor drei Jahren für eine damals zutreffende Situation geschrieben wurde und dann als dauerhafte Entscheidung im Code blieb, die niemand mehr überprüft hat. Der Fehler ist nicht, dass sich ein Entwickler geirrt hat. Er liegt darin, dass die Annahme nie an einer überprüfbaren Stelle festgehalten wurde und so Teil der Struktur wurde statt einer Einstellung.

Deshalb trennen wir beim Bau eines Systems die Validierungsregeln vom Code und behandeln sie als Konfiguration, und wir speichern Mobilnummern immer im internationalen Format, auch wenn heute jeder Kunde lokal ist. Die Kosten beim Bau liegen nahe null. Die Kosten zwei Jahre später, wenn Sie eine Filiale in Dammam eröffnen, die Besucher aus Bahrain bedient, oder wenn ein Turnier in Ihre Stadt kommt, sind der Unterschied zwischen einer Stunde Konfiguration und einem Änderungsprojekt, das in Wochen gemessen wird. Dasselbe Prinzip wenden wir auf alles an, was wir im Rahmen unserer Leistungen bauen: Eine Annahme, die heute gilt, wird als Einstellung geschrieben, nicht als Bedingung in einer Codezeile.

Was den 6. Oktober überdauert

Das Turnier endet am sechsten Oktober. Der Teil, den Sie behoben haben, nicht. Das Königreich richtet laufend Großveranstaltungen aus, und Saisons, Konferenzen und Turniere sind inzwischen ein fester Bestandteil des Kalenders statt einer Ausnahme darin. Ein System, das heute einen Besucher von außerhalb des Königreichs akzeptiert, akzeptiert ihn auch bei der nächsten Veranstaltung ohne weiteren Aufwand.

Beginnen Sie diese Woche mit dem kleinsten umsetzbaren Schritt: Öffnen Sie Ihre Website oder App und versuchen Sie, einen vollständigen Kauf mit einer echten Mobilnummer aus dem Golf und einer nicht saudischen Karte abzuschließen. Wenn es funktioniert, sind Sie bereit. Wenn Sie an einem bestimmten Feld hängen bleiben, haben Sie gerade gefunden, wohin zwei Wochen Umsatz verschwunden wären.

Quellen