Сегодня Absher возглавил поисковые запросы в Саудовской Аравии, и причина не в сбое и не в мимолётном заголовке. Причина — набор сервисов, которые Главное управление паспортов добавило на платформу за последние недели. Главный из них — Absher Safar, который позволяет путешественнику создать электронный запрос на поездку и самостоятельно пройти формальности до прибытия на сухопутный пограничный переход. Рядом с ним — Tawassul, который позволяет пользователю подать запрос на завершение паспортной операции, которую не удалось завершить электронно, не посещая паспортный офис.

Новость касается путешественников, но лежащий в её основе принцип относится к любой организации с очередью: клинике, автосервису, приёмке товара, шоуруму, даже службе поддержки. Паспортное управление здесь не добавило ещё один экран. Оно перераспределило, где и когда выполняется работа. Именно эту часть стоит копировать.

Работа переместилась, а не исчезла

В традиционной модели всё происходит у окна: проверка личности, данные пассажира, соответствие транспортного средства, оплата, досмотр, а затем решение. Окно несёт всё это одновременно, поэтому очередь растёт с каждым прибытием — не потому, что решение принимается медленно, а потому, что всё, что предшествует решению, происходит в один и тот же момент.

Absher Safar перенёс всё, что можно сделать заранее, в приложение Absher Individuals: путешественник создаёт запрос на поездку, добавляет едущих с ним, подтверждает личность через Nafath, а по прибытии на переход включает Bluetooth и проходит подтверждение местоположения через Nafath. Момент прибытия по-прежнему существует, но из точки ввода данных он превратился в точку проверки. В этом разница между очередью, которая растёт вместе с числом полей, и очередью, которая растёт вместе с числом машин.

Этот ход почти дословно переносится в другие виды бизнеса. Клиент автосервиса, который до приезда описывает неисправность, загружает фотографии и бронирует время, превращает приёмку из долгого диагностического разговора в передачу ключей. Поставщик, который присылает отгрузочный манифест и номера партий до прибытия грузовика, превращает ворота склада из точки пересчёта в точку сверки.

Почему идея проваливается без надёжной идентификации

Большинство попыток переложить работу на клиента терпят неудачу по причине, которая не является технической. Причина — доверие. Когда вы не знаете, кто на самом деле ввёл данные, вы перепроверяете их по прибытии — значит, вы добавили шаг клиенту и не сэкономили ни одного себе. В итоге получается система, которая просит клиента заполнить форму, а затем повторить её перед сотрудником.

Ответ, на котором построило решение паспортное управление, — привязка запроса к национальной цифровой идентичности: верификация проходит через Nafath до прибытия, а подтверждение местоположения на переходе устанавливает, что человек, подавший запрос, — это тот, кто действительно прибыл, и в нужное место. Именно это делает заранее введённые данные надёжными и позволяет убрать шаг у окна, а не дублировать его.

В частной компании практическим аналогом служит реальная проверка вместо открытой формы: аутентифицированный вход для постоянных клиентов, код подтверждения, привязанный к проверенному номеру мобильного телефона, или интеграция с Nafath там, где контекст действительно требует подтверждённой личности. Правило простое. Не переносите шаг на время до прибытия, если не можете доверять его результату по прибытии.

Tawassul: признать, что автоматизация не охватит каждый случай

Более умная половина пакета — не Absher Safar, а Tawassul. Исходная посылка в том, что некоторые паспортные операции по той или иной причине застревают в электронном виде, и вместо того чтобы оставлять визит в офис единственным выходом, застрявшее дело теперь имеет определённый цифровой путь, по которому запрос подаётся и отслеживается.

Именно здесь корпоративные проекты цифровизации ошибаются чаще всего. «Счастливый путь» автоматизируется безупречно, а исключение остаётся вовсе без пути. Каждый застрявший клиент оказывается в группе WhatsApp или у сотрудника, которого он случайно знает. Сложные случаи — как раз те, что формируют впечатление клиента, — решаются вне системы, без записи, без срока ответа и без назначенного ответственного.

  • Относитесь к исключению как к полноценному случаю: застрявшему запросу нужны тип записи, ответственный и статус, а не сообщение в чате.
  • Разместите вход в него там же: клиент, застрявший в вашем приложении, должен найти выход внутри приложения, а не искать номер телефона.
  • Измеряйте время исключений отдельно: общее среднее скрывает застрявшие дела. Отслеживайте время закрытия исключений отдельно.
  • Питайте проектирование исключениями: повторяющийся один и тот же затор — это дефект «счастливого пути», а не повод нанять больше сотрудников поддержки.

Сначала одна площадка

Обратите внимание на последовательность: сервис запустили на мосту короля Фахда в качестве первого этапа, затем распространили на сухопутный переход Салва. Он не заработал на всех переходах в один день.

Это проектирование, а не административная осторожность. Одна площадка даёт вам реальный случай во всей его сложности — слабая связь, старые устройства, непредсказуемое поведение пользователей — в масштабе, который ещё можно откатить. Компания, которая включает новую систему во всех филиалах в один день, не находит свои проблемы быстрее; она находит их все сразу, и отступать некуда.

Взгляд Origami

В проектах с клиентами мы видим, что большинство очередей — это проблема не мощности, а последовательности. Человек у окна тратит большую часть времени на сбор информации, которая могла бы поступить за день до клиента, а остальное — на её проверку. Когда руководитель жалуется на загруженность, предлагаемое решение — всегда ещё один сотрудник или ещё один экран, тогда как настоящая проблема в том, что точка контакта несёт работу, которая ей не принадлежит.

Порядок, который мы рекомендуем при построении любого пути обслуживания: отделить то, что можно сделать заранее, от того, что действительно требует присутствия; строить проверку на идентичности, которой можно доверять, чтобы шаг не повторялся; спроектировать путь для исключений до запуска «счастливого пути»; затем запуститься в одном филиале и провести измерения, прежде чем расширяться. Тот же порядок можно прочитать в этом сервисе. Разница лишь в том, что его масштаб — национальный, а ваш — один филиал.

Практический вывод

Возьмите свою самую частую операцию и запишите её шаги так, как они происходят сегодня, затем отметьте каждый шаг, который мог бы произойти до прибытия клиента. Если большинство шагов можно перенести, но все они по-прежнему происходят на стойке регистрации, вам нужна не большая мощность — вам нужна другая последовательность. И начните с вопроса, который решает выполнимость: когда клиент прибывает, могу ли я доверять тому, что он ввёл до прибытия? Если ответ — нет, начинайте с проверки, а не с формы.

Источники