Building for Saudi Customers? Test the Sign-Up Journey Before You Launch
In Short
Building for Saudi customers? Learn how to test and optimize the sign-up journey for local users before launching to improve usability, conversions, and customer experience.
Share :
Building for Saudi Customers Test the Sign-Up Journey Before You Launch
An Indian product team may translate its website into Arabic, yet a customer from Saudi Arabia might be unable to register successfully. A telephone number field with the wrong country code or a confusing verification prompt or an error can stop the customer from completing the signup process. Preparation for launch consists of checking every stage of the signup process, from the moment of inputting the phone number to the point of finishing verification, including the moment when the message is delayed.
Take, for instance, a hypothetical Indian team working on an appointment-booking application for customers based in Saudi Arabia. Visitors can browse the available appointments and log in to their accounts to manage the bookings. The team is considering the possibility to sign in using a Saudi phone number and one-time password (OTP) via SMS.
Decide whether a number is needed
In the beginning, you should specify what collection and verification will make possible. The phone number for requesting a call back, phone-based login, and phone number used for marketing purposes fulfill different tasks, so one need does not imply another. If it is possible for customers to try the service without a phone number, they can be allowed to do it.
Regarding the invented booking service, the team should work out whether it is right for users to access their accounts by phone number or it is better to use less extensive information. If phone numbers will be used, ask the user at the relevant stage. Always explain why do you need the phone number. Use wording such as “Please provide a working mobile number so that we can send you the SMS code required to log in to your account”..
Make Saudi number entry clear
Add "Saudi mobile number" as a field and explain the scope of what it supports before the customer submits it. A country-picking drop-down list should represent only the countries permitted for that verification type. In other words, the team's actual location in India and the customer's location should not silently decide what country code is affixed to that number.
According to the International Telecommunication Union, the country code for Saudi numbers is +966. A Saudi mobile number consists of nine digits after that, and it starts with 5. Thus, the domestic format 05X XXX XXXX corresponds to the international +966 5X XXX XXXX; the domestic leading zero is lost. Here, X represents a digit; these are format patterns, and they don't mean that one can use those digits for testing.
Review both language journeys
Carefully look at the labels, explanations, buttons, wait messages, errors and guidance in Arabic and English. Find a fluent reader of Arabic and let him check the working screens. It might happen that a good translation does not clarify the next steps, especially if the user is moving from the number field to the SMS field and the code input screen.
The recommendations of the World Wide Web Consortium on bidirectional text do matter here. An Arabic interface should be displayed in the right-to-left way while the numbers of the phone and the integer digits in the code remain in the right order. Check the plus sign with the country code, the masked number and punctuation marks. Just aligning the text to the right is not enough. When the language is changed, the number that was entered and the current verification status should remain unchanged.
Try Western and Arabic-Indic digits with the keyboards customers are likely to use. Define and test any conversion of equivalent digits, preserving leading zeros in codes; do not assume a service handles phone-number input and OTP input identically. Allow code pasting and supported autofill, with manual entry still available. Make labels and errors usable with a keyboard and screen reader. W3C's form guidance calls for understandable feedback and corrective instructions: put the error beside the relevant field, make it available to assistive technology and avoid relying on colour alone.
Plan for expiry and retries
For a technical baseline, NIST's Digital Identity Guidelines in SP 800-63B-4 set a ten-minute maximum for completing authentication with an SMS code. They also require each code to be accepted only once and failed attempts to be limited. Choose an appropriate lifetime within that ceiling and make the screen reflect the deadline enforced by the server. Refreshing the page or changing its language should not extend the code's validity.
Consider resending as a process in itself. Set a time when the other request becomes possible and apply the same time frame and sending limitations to the server as well. Upon issuing a replacement account code, clarify the previous one. A reasonable approach for this hypothetical product is that the only code currently in effect can end the sign-up procedure, and the application must follow this principle regardless of its supplier's keeping the older verification requests active.
Keep a cumulative ceiling of wrong tries for all resends and repeated actions. NIST specifically states that new password generation cannot reset emergency attempts. Send limits must be applied to the same figure seen under its different formats.
Make the difference between an invalid password and expired one and between invalid password and temporary prohibition against sending it. "This is an expired password. Take a new one and proceed" offers suggestions; "Failed" doesn't add anything to the customer's knowledge and creates the potential for the confusion relating to previous recognitions.
A screen that works is necessary for a delay in delivery. Allow the customer to check or modify the destination, hold on, ask for another code if able, or get assistance. Never give an ETA that the service cannot validate, and do not accuse the device unless proven. Check the outcome of the delivery request before sending it again if it times out. An old message may arrive after the new one, so the message should not be treated as the present one.
Keep delivery and verification separate
A provider accepting a message for sending, a delivery report and a completed verification are different events. Delivery reports have provider-specific meanings and may not always be available. Neither acceptance nor a delivery report establishes that the customer entered the correct code. Complete the verification step only after a trusted server-side check succeeds for the intended number and the active sign-up attempt. A change of number requires a fresh check.
For this delivery step, Tawked is a potential OTP component to evaluate: its verification product documents SMS code delivery to Saudi mobile numbers. The product team remains responsible for connecting the verification result to its own account rules, interface and support process.
Analyze each stage separately in scrutinizing the journey of the user. The messages generated for an interrupted sign-up still count as incomplete sign-up. Record the timing and failure information with the use of the identifiers that are not sensitive including the OTP information.
An accepted code indicates that there is access to that specific phone number at that specific time but does not prove legal identity, citizenship or residency, thus there is no need for the label "Identity certified". The SMS verification method does not remove phishing, SIM-swapping, and device hacking concerns. Sensitive functions must involve a method of authentication that will eliminate those risks.
Provide help without weakening recovery
Add a support service that can be accessed without completing the failed SMS step. This will give us the possibility of finding out an estimated time to contact the client if a message was missed together with the type of error displayed. Staff members should not ask for the OTP in any form of communication.
The process of correcting a phone number after an incomplete registration is not the same as changing the number of a verified account. If the account is verified, recovery methods should be used. The client’s claim that he or she has not received the message is not a reason to grant access to the account to anyone.
Prelaunch checklist
The following are illustrative test cases and expected behaviours for the fictional team's plan, not results of live tests. Use controlled test accounts and numbers the team is authorised to use, and simulate failure conditions deliberately.
Illustrative test case | Expected user-facing behaviour |
Enter the same Saudi mobile number in domestic and international forms, including pasted spaces. | Show one consistent destination. Include +966 once and omit the domestic zero in the international form. Let the customer correct the number. |
Try an Indian +91 number or a Saudi fixed-line number. | Explain that this verification route accepts Saudi mobile numbers. Offer correction before requesting an SMS. |
Use Arabic and English screens, try both digit styles, and switch languages midway. | Keep the number and code in the correct order. Apply the defined input rules and preserve the current step and deadline. |
Navigate by keyboard and screen reader; paste the complete code. | Provide usable labels, errors and next actions. Accept whole-code paste, including when the design uses separate digit boxes. |
Enter an incorrect, expired or previously used code. | Explain the permitted next step. A used code cannot complete another verification, and an expired code cannot revive the attempt. |
Request repeated resends, refresh the screen and start again. | Show accurate waiting or retry guidance. Resends and new starts do not remove the application's cumulative limits. |
Let an older SMS arrive after a replacement code. | Enforce the stated replacement policy. Explain why the earlier code cannot complete this sign-up attempt. |
Receive a delivery report without entering a valid code. | Keep verification incomplete. Leave code entry and appropriate help available. |
Delay delivery or simulate a failed send request. | Preserve useful progress. Offer the appropriate wait, correction, resend or support action without claiming verification succeeded. |
Seek help after losing access to the number. | Make help accessible before sign-in. Ask for non-secret details and follow the recovery process without requesting the OTP. |
Prior to launching, provide a member of your team not on the screen design team with these cases without any assistance. Ask them to disclose why this number is required, where they would expect the code to go, and how they would handle it if it did not do so. Any response that involves needing a developer next to them indicates areas for the team to work on before the Saudi customer gets to that screen.
