Между ними не было даже перегородки...

Шестнадцать лет назад я оформлял прописку своему новорождённому сыну в паспортном столе. Отстоял очередь к окошку. Операционист что-то сделала и сказала: «А теперь вам к начальнику паспортного стола».

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

Это было до сервисного прорыва МФЦ и Госуслуг, которые теперь стали привычной частью жизни. Сцена запечатлилась в памяти: два человека сидят рядом, а переход между этапами одной услуги обеспечиваю я. Своими ногами и временем.

И в ИТ наличие единого окна само по себе не гарантирует бесшовный сервис для пользователя.

Для пользователя корпоративный портал или портал самообслуживания - один интерфейс. А за ним гарантировано стоят несколько систем, разные продуктовые команды, подрядчики. В решении вопроса могут участвовать и коллеги из ИБ. У всех свои задачи, зоны ответственности, иногда даже разные системы автоматизации работы с обращениями.

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

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

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

В моей практике такие вопросы помогали решать сводные группы координаторов. В виртуальную группу входили представители нужных вертикалей: поддержки, продуктовых команд, ИБ, интеграторов и подрядчиков.

Такая группа подключалась за первой линией, когда обращение требовало совместного разбора. У её участников могло быть немного полномочий, но каждый мог предъявить факты со своей стороны. Нужные представители уже находились в одной группе, поэтому перебрасывать заявку между ними теряло смысл.

За движение вопроса к решению отвечал я - руководитель поддержки пользователей и владелец процесса управления обращениями. Участники помогали разобраться в проблеме, а ответственность за организацию взаимодействия оставалась у меня. Пользователю не требовалось самому собирать эту группу или добиваться продолжения разговора.

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

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

Дополнительные сведения иногда необходимы. Показать ошибку, объяснить желаемый результат, проверить, что работа восстановилась, это нормальное участие пользователя. А вот разыскивать исполнителей и пересказывать им переписку, которая уже есть у ИТ, ему приходится из-за того, как мы организовали обслуживание.

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

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

Пользователь не должен заполнять ролевую пустоту между участниками сервиса. Организовать их взаимодействие - наша работа.