Экономия времени сотрудников и клиентов — главная цель любого цифрового сервиса для бизнеса. Если личный кабинет для B2B запустили, а менеджеры по-прежнему решают все вопросы с помощью почты и звонков, то цифровизацию нельзя назвать эффективной.
Такой неутешительный результат может получиться, когда команда разработки недостаточно погрузилась в бизнес-процессы и не описала, как и что делают пользователи с помощью нового ресурса. В статье расскажем, как сделать личный кабинет полезным в работе и интуитивно понятным для всех участников процесса.
Точную и измеряемую оценку эффективности личного кабинета можно дать с помощью языка данных. Важно замерить несколько ключевых метрик и следить за их динамикой. Контрольные точки — запуск личного кабинета, обновления сервиса, первые месяцы работы, полгода работы. Это поможет понять, как быстро окупятся инвестиции. Опирайтесь на несколько метрик:
Успешность выполнения сценария — рассчитывается в процентах от числа всех пользователей, начавших сценарий.
Доля операций, успешно завершенных без участия менеджера — учитывается в процентах от числа всех начатых операций этого типа.
Конверсия ЛК — рассматривается доля целевых действий, выполненных через него.
Время выполнения операции — замеряется время получения документа.
Но оценить личный кабинет на уровне «хорошо или плохо» можно и по косвенным признакам. Вот они:
документы по-прежнему отправляются по почте;
клиент звонит менеджеру, чтобы узнать статус заявки;
вы не понимаете, как администрировать кабинет, и регулярно обращаетесь к подрядчику.
Если новый сервис набрал хотя бы один из трех пунктов, есть повод глубже исследовать его работу. Например, провести интервью с пользователями.
Причина неэффективности личного кабинета обычно одна и та же: раздел спроектировали как витрину. Она рассчитана на базовый сценарий — просмотр каталога, повтор заказа, скачивание счета. Как только процессов становится слишком много, процесс возвращается в почту.
Различные роли пользователей в B2B-кабинете — это и различные уровни доступа, и неодинаковые функции: что пользователь видит, что меняет, что подписывает и за что отвечает перед третьей стороной. Если мы говорим о сервисах типа «бизнес для бизнеса», то этой третьей стороной обычно выступает головная компания, регулятор (представитель надзорного органа) или конечный заказчик.
Как спроектировать эффективную ролевую модель? Первое правило — искать роли в процессе, а не в организационной структуре компании. Ролевая модель почти никогда не совпадает с должностями: это две разные структуры, каждая со своими целями. Роли на сайте создаются под основные сценарии его использования — обработка заявки, формирование документов, сборка заказа — в то время как система должностей отражает бизнес-процессы. Обе системы могут быть мало похожи между собой: например, должность «менеджер по закупкам» на сайте может распадаться на три роли с разным доступом к контенту, а два разных отдела схлопываться в одну роль «снабженец». Поэтому набор ролей собирают из интервью, где вы описываете реальный процесс сделки, а подрядчик переводит его на язык пользовательских сценариев.
Второе правило — не плодить роли без нужды. Ведь каждая новая роль — это не только дополнительные часы работы дизайнеров и разработчиков, но еще и дополнительное время на обучение сотрудников. Мы в Uplab используем простой критерий: если роль отличается от другой только одним переключателем, то нужно их объединить и предусмотреть настройки. К примеру, при разработке системы отчетности по выбросу парниковых газов ГИС «Энергоэффективность» мы сделали так, что в кабинете эмитента (компании, отчитывающейся за выброс газов) можно выбрать один из трёх статусов, в зависимости от того, к какой системе отчётности относится организация. Аналитики Uplab сделали вывод, что дробить это на три роли не нужно: достаточно одной с тремя режимами. В итоге набор экранов у них общий, а отчеты выводятся разные.
Хорошая ролевая модель всегда получается компактной, и каждая роль в ней закрывает свой сценарий работы. Это было нашим принципом при разработке портала Алюминиевой Ассоциации. Организация объединяет больше 140 компаний-участников, но мы проанализировали процесс и выделили только шесть основных сценариев работы с платформой и шесть ролей.
Составить подробные инструкции и загрузить их в личный кабинет нового сервиса — неэффективный путь: пользователю проще написать в техподдержку разработчика, чем искать ответ на свой вопрос в документах. А чтобы действительно снизить нагрузку на поддержку и сократить время выполнения операций, важно добавить в ЛК набор понятных статусов. Понятными их делает указание ответственных и сроков, а также использование «языка пользователя».
В 2022 году мы запустили для благотворительного фонда «Милосердие» портал грантового конкурса «Стальное дерево». Заявку разложили на шесть шагов: человек заполняет, сохраняет, уходит и возвращается позже, а перед отправкой открывает предпросмотр.
Замечание куратора подсвечивает нужный шаг красным, и пользователь видит, куда вернуться — без письма и звонка в поддержку. Эксперты фонда работают не с пачкой файлов, а со сводной таблицей. Всего в системе четыре кабинета: для участника, куратора, эксперта и администратора.
Результат: обработка конкурсных заявок ускорилась в 20 раз, а подходящих стало в полтора раза больше. Понятные требования на каждом шаге и возможность сохранить изменения доводят до отправки тех заявителей, кто раньше бросал форму на середине.
Еще две вещи, которые обычно забывают. Во-первых, статус в базе и статус на экране лучше писать разными словами: pending_validation превращается в «проверяем данные, ответим до 20 августа». Во-вторых, дедлайны — автоматические уведомления о приближении срока — очень полезны: они снимают часть обращений заранее, а не тогда, когда клиент уже опоздал.
Если пользователям приходится вручную вводить много данных (адреса, коды по разным классификаторам и так далее), неизбежны ошибки и незавершенные сценарии. Поэтому очень важно добавлять в систему различные справочники и вовремя обновлять их. Роль администратора нормативно-справочной информации и регламент обновления нужно обязательно прописать в документах по проекту, ведь без этого данные устареют за год.
На портале Алюминиевой Ассоциации таких справочников больше двадцати. Без них фильтр по направлению, региону и типу продукции не работал бы на выборке из 140 с лишним организаций.
Разработчики B2B-сервисов часто изучают G2B и G2C системы (государственные сервисы для компаний и граждан), потому что они работают в схожих условиях: высокая нагруженность и сложные сценарии пользователей. Проблема с тем, чтобы сделать пользователей «самостоятельными», остро стоит и там, и там. Мы отметили для себя несколько решений, типичных для государственных сервисов, которые можно использовать и в коммерческих личных кабинетах. Разберем те из них, которые сработают для российского рынка.
Доступность интерфейса для людей с инвалидностью заложена в ГОСТ Р 52872-2019: для государственных сервисов он обязателен к исполнению. Для коммерческих компаний это рекомендательный документ, но если его не соблюдать, компания может получить судебные иски по дискриминации или отказ на участие в ряде тендеров. Контрастность текста, навигация с клавиатуры и работа со скринридером — опции, которые несложно добавить на этапе дизайна и разработки, чтобы предотвратить такие неприятности.
Авторизация работает на единой системе идентификации и аутентификации — ЕСИА. Она снимает задачу проверки пользователя целиком: человек входит логином от Госуслуг, а его организация уже подтверждена государством. Коммерческой организации это позволяет сэкономить на собственной процедуре верификации и отдельном контуре с паролями и восстановлением доступа. Как именно это работает, мы писали в отдельной статье.
Подключение к ЕСИА проходит через регламентную процедуру и согласование. Сценарий привычен аудитории. В 2025 году ежедневная аудитория Госуслуг выросла на 40% и достигла 14 млн человек, а всего на портале 120 млн пользователей.
В государственных системах обмен идет через СМЭВ — систему межведомственного электронного взаимодействия. Ценность этих протоколов в том, что структура запроса стандартизована независимо от архитектуры внешней системы.
Тот же подход применяется и к самим данным: не заставлять пользователя вводить руками то, что лежит в реестре. Адреса, коды и реквизиты в государственном сервисе приходят из ГАР и классификаторов. В коммерческом кабинете ту же работу делают ЕГРЮЛ и справочники учетной системы.
Зачастую первая версия личного кабинета, спроектированная для MVP сервиса или его ранней версии, содержит всего четыре элемента: роль заявителя, роль проверяющего, один сквозной путь от заявки до решения, статусы с уведомлениями.
Каталог, дашборды и аналитика ждут второй итерации, когда станет видно, чем реально пользуются. Такой подход с постепенным добавлением функций поможет не растянуть сроки и избавит от добавления функций, которыми не пользуются. Сценарии дешевле проверять до написания кода, пользуясь для этого прототипами и тестируя их на контрольных группах.
Расскажите про свой бизнес-процесс — мы предложим схему кабинета и оценим сроки.
Комментарии к статье
Комментарии: 0