Absher Safar and the Operational Lesson in Moving Work Ahead of the Counter

Absher Safar and the Operational Lesson in Moving Work Ahead of the Counter

Absher topped search in Saudi Arabia today, and the reason is neither an outage nor a passing headline. It is a set of services the General Directorate of Passports has added to the platform in recent weeks. The headline one is Absher Safar, which lets a traveler create an electronic travel request and complete the formalities independently before reaching the land crossing. Alongside it is Tawassul, which lets a user submit a request to finish a passport transaction that could not be completed electronically, without visiting a passport office.

The news is about travelers, but the principle underneath it belongs to any organization with a queue: a clinic, a workshop, a receiving dock, a showroom, even a support desk. What the Passports Directorate did here was not add a screen. It redistributed where and when the work happens. That is the part worth copying.

The work moved; it did not disappear

In the traditional model everything happens at the window: identity check, passenger details, vehicle compliance, payment, inspection, then the decision. The window carries all of it at once, which is why the queue grows with every arrival — not because the decision is slow, but because everything preceding the decision happens in the same moment.

Absher Safar moved everything that could be done in advance into the Absher Individuals app: the traveler creates the travel request, adds the travelers with them, verifies identity through Nafath, and on reaching the crossing enables Bluetooth and completes location verification through Nafath. The moment of arrival still exists, but it changed from a data-entry point into a verification point. That is the difference between a queue that grows with the number of fields and one that grows with the number of cars.

The move transfers almost literally into other businesses. A workshop customer who describes the fault, uploads photos and books a slot before arriving turns intake from a long diagnostic conversation into a key handover. A supplier who sends the shipment manifest and batch numbers before the truck arrives turns the warehouse gate from a counting point into a matching point.

Why the idea fails without trustworthy identity

Most attempts to push work onto the customer fail for a reason that is not technical. It is trust. When you do not know who actually entered the data, you re-verify it on arrival — so you have added a step for the customer and saved none for yourself. You end up with a system that asks the customer to fill in a form and then repeat it in front of a clerk.

The answer the Passports Directorate built on is binding the request to a national digital identity: verification runs through Nafath before arrival, and location verification at the crossing establishes that the person who filed the request is the one who actually showed up, in the right place. That is what makes pre-entered data dependable, and what allows the step at the window to be removed rather than duplicated.

In a private business the practical equivalent is real verification instead of an open form: an authenticated login for repeat customers, a confirmation code tied to a verified mobile number, or a Nafath integration where the context genuinely calls for a confirmed identity. The rule is simple. Do not move a step ahead of arrival unless you can trust its output on arrival.

Tawassul: admitting that automation will not cover every case

The smarter half of the package is not Absher Safar; it is Tawassul. The premise is that some passport transactions stall electronically for one reason or another, and rather than leaving the office visit as the only remedy, the stalled case now has a defined digital path where the request is raised and followed up.

This is where corporate digitization projects most often go wrong. The happy path gets automated beautifully and the exception is left with no path at all. Every stuck customer ends up in a WhatsApp group or with one employee they happen to know. The hard cases — precisely the ones that shape the customer's impression — are handled outside the system, with no record, no response time and no named owner.

• Treat the exception as a first-class case: a stalled request needs a record type, an owner and a status, not a message in a chat thread.
• Put its entrance in the same place: a customer who gets stuck in your app should find the way out inside the app, not hunt for a phone number.
• Measure exception time separately: an overall average hides stuck cases. Track time-to-close for exceptions on their own.
• Feed the design from exceptions: the same stall repeating is a defect in the happy path, not a case for more support staff.

One site first

Note the sequence: the service launched at King Fahd Causeway as a first phase, then extended to the Salwa land crossing. It did not go live at every crossing on one day.

That is design, not administrative caution. A single site gives you a real case in full complexity: weak connectivity, older devices, unpredictable user behavior — at a size you can still reverse. A company that switches on a new system across every branch on one day does not find its problems faster; it finds all of them at once, with nowhere to fall back to.

The Origami view

Across client projects we find that most waiting lines are not a capacity problem but a sequencing problem. The person at the window spends most of their time collecting information that could have arrived a day before the customer, and the rest verifying it. When a manager complains about congestion, the proposed fix is always another employee or another screen — while the real issue is that the point of contact is carrying work that does not belong to it.

The order we recommend when building any service path: separate what can be done in advance from what genuinely requires presence; build verification on an identity you can trust so the step is not repeated; design the exception path before you launch the happy path; then go live at one branch and measure before expanding. That is the same order you can read in this service. The only difference is that its scope is national and yours is a branch.

A practical takeaway

Take your most frequent transaction and write out its steps as they happen today, then mark every step that could happen before the customer arrives. If most of the steps are movable and yet all of them still occur at reception, you do not need more capacity — you need a different sequence. And start with the question that settles feasibility: when the customer arrives, can I trust what they entered before arriving? If the answer is no, start with verification, not with the form.

Sources

• Absher platform — services available through Absher Individuals and Absher Business, and usage requirements.
• Ministry of Interior — General Directorate of Passports — the Absher Safar announcement and its rollout phases across land crossings, and the Tawassul service for completing passport transactions.
• Nafath national single sign-on — digital identity and biometric verification.
• Digital Government Authority — digital transformation measurement — the methodology for assessing maturity of government digital services.