今日、サウジアラビアの検索ランキングで Absher がトップになりましたが、その理由は障害でも一過性の見出しでもありません。旅券総局がここ数週間でプラットフォームに追加した一連のサービスです。その目玉が Absher Safar で、旅行者は電子渡航申請を作成し、陸路の国境検問所に着く前に手続きを自分で完了できます。これと並んで Tawassul があり、利用者は電子的に完了できなかった旅券手続きを終えるための申請を、旅券事務所を訪れることなく提出できます。

このニュースは旅行者に関するものですが、その根底にある原則は待ち行列を抱えるあらゆる組織に当てはまります。クリニック、整備工場、入荷ドック、ショールーム、さらにはサポートデスクもそうです。旅券総局がここで行ったのは、画面を一つ追加することではありません。仕事がどこで、いつ行われるかを配分し直したのです。真似する価値があるのはこの部分です。

仕事は移動したのであって、消えたわけではない

従来のモデルでは、すべてが窓口で行われます。本人確認、乗客情報、車両の適合確認、支払い、検査、そして最後に判断です。窓口はこれらすべてを同時に担うため、到着のたびに行列が伸びていきます。判断が遅いからではなく、判断に先立つすべてが同じ瞬間に起きているからです。

Absher Safar は、事前にできることをすべて Absher Individuals アプリに移しました。旅行者は渡航申請を作成し、同行者を追加し、Nafath で本人確認を行い、検問所に着いたら Bluetooth を有効にして Nafath で位置確認を完了します。到着の瞬間は今も存在しますが、それはデータ入力の場から確認の場へと変わりました。入力項目の数に比例して伸びる行列と、車の台数に比例して伸びる行列の違いはここにあります。

この手法は、ほぼそのまま他の業種にも移し替えられます。来店前に不具合を説明し、写真をアップロードし、時間枠を予約する整備工場の顧客は、受付を長い診断の会話から鍵の受け渡しへと変えます。トラックの到着前に出荷明細とロット番号を送るサプライヤーは、倉庫のゲートを数量を数える場から照合する場へと変えます。

信頼できる本人確認がなければ、このアイデアは失敗する

仕事を顧客側に移そうとする試みの多くは、技術的ではない理由で失敗します。それは信頼です。誰が実際にデータを入力したのか分からなければ、到着時にそれを再確認することになります。つまり顧客には手順を一つ増やし、自分の手順は一つも減らしていないのです。結局、顧客にフォームを記入させ、その後また担当者の前で同じことを繰り返させるシステムができあがります。

旅券総局が土台にした答えは、申請を国のデジタルアイデンティティに紐づけることです。到着前に Nafath で認証を行い、検問所での位置確認によって、申請を出した人物が実際に正しい場所に現れた本人であることを確認します。これこそが事前入力データを信頼できるものにし、窓口での手順を重複させるのではなく削除することを可能にしているのです。

民間企業における実務上の対応策は、開かれたフォームではなく本物の確認です。リピーター向けの認証済みログイン、確認済みの携帯電話番号に紐づいた確認コード、あるいは本当に確認済みの身元が必要な場面での Nafath 連携などです。ルールは単純です。到着時にその結果を信頼できないなら、その手順を到着前に移してはいけません。

Tawassul：自動化がすべてのケースを網羅しないと認めること

このパッケージのより賢い半分は Absher Safar ではなく Tawassul です。前提となっているのは、一部の旅券手続きが何らかの理由で電子的に行き詰まるということです。そして事務所への来訪を唯一の解決策として残すのではなく、行き詰まった案件には、申請を提出して進捗を追える明確なデジタル経路が用意されました。

企業のデジタル化プロジェクトが最もよく失敗するのはここです。正常系は見事に自動化されるのに、例外にはまったく経路がありません。行き詰まった顧客は皆、WhatsApp のグループや、たまたま知っている社員のもとにたどり着きます。難しい案件――まさに顧客の印象を形づくる案件――は、記録も応答時間も担当者の指名もないまま、システムの外で処理されるのです。

  • 例外を正式な案件として扱う：行き詰まった申請に必要なのは、チャットのスレッド内のメッセージではなく、記録の種別、担当者、ステータスです。
  • その入口を同じ場所に置く：アプリで行き詰まった顧客は、電話番号を探し回るのではなく、アプリの中で出口を見つけられるべきです。
  • 例外の処理時間を別に計測する：全体平均は行き詰まった案件を覆い隠します。例外の完了までの時間を単独で追跡してください。
  • 例外を設計に還元する：同じ行き詰まりが繰り返されるのは正常系の欠陥であり、サポート要員を増やす理由ではありません。

まずは一拠点から

順序に注目してください。このサービスは第一段階としてキング・ファハド・コーズウェイで開始され、その後サルワ陸路検問所に拡大されました。すべての検問所で同じ日に稼働したわけではありません。

これは行政上の慎重さではなく、設計です。一つの拠点は、通信の弱さ、古い端末、予測できない利用者の行動といった複雑さをすべて備えた実際のケースを、まだ元に戻せる規模で提供してくれます。新しいシステムを全支店で同じ日に稼働させる会社は、問題を早く見つけるのではなく、退く場所もないまま、すべての問題を一度に見つけることになります。

Origami の視点

顧客とのプロジェクトを通じて、待ち行列の大半は処理能力の問題ではなく、順序の問題だと私たちは見ています。窓口の担当者は、顧客より一日早く届いていてもよかった情報の収集に時間の大半を費やし、残りをその確認に費やしています。管理者が混雑に不満を述べると、提案される解決策はいつも社員をもう一人、あるいは画面をもう一つ増やすことです。しかし本当の問題は、接点が本来そこに属さない仕事を背負っていることなのです。

どのようなサービス経路を構築する場合でも、私たちが推奨する順序は次のとおりです。事前にできることと本当に来訪が必要なことを分ける。手順が繰り返されないよう、信頼できる身元の上に確認の仕組みを築く。正常系を立ち上げる前に例外経路を設計する。そして一つの支店で稼働させ、拡大する前に計測する。これはこのサービスから読み取れる順序とまったく同じです。違いは、その範囲が全国であり、あなたの範囲が一つの支店であるという点だけです。

実践的な教訓

最も頻度の高い手続きを一つ取り上げ、その手順を現在行われているとおりに書き出し、顧客が到着する前に行える手順すべてに印をつけてください。大半の手順が移動可能なのに、それでもすべてが受付で行われているなら、必要なのは処理能力の増強ではなく、別の順序です。そして実現可能性を決める問いから始めてください。顧客が到着したとき、到着前に入力された内容を信頼できるか。答えが「いいえ」なら、フォームからではなく、確認から始めてください。

出典