Важность поддержки пользовательского интерфейса – CodesCode

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

Любая компания, которая продает программное обеспечение непосредственно конечным пользователям и стремится к масштабированию до значительного размера, в конечном итоге потребует наличие специализированной службы поддержки. Если эта служба поддержки будет успешно поддерживать людей, использующих программное обеспечение, им потребуется некоторый вид пользовательского интерфейса поддержки (UI).

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

«56% людей по всему миру прекратили взаимодействие с компанией из-за плохого опыта обслуживания клиентов». — Microsoft

Что должно быть в моем UI поддержки?

«Мы только что достигли нашего 100-го пользователя, и наши разработчики устали запускать скрипты для разблокировки учетных записей пользователей. Мы собираемся приостановить разработку функций на неделю и создать некий пользовательский интерфейс поддержки, чтобы помочь нам обслуживать платформу. С чего начать?»

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

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

Действия администратора: Предоставьте своей службе поддержки возможность для всех изменений, которые клиент может сделать в настройках своей учетной записи. Сброс пароля, настройки конфиденциальности, настройки уведомлений, а также изменение контактной и платежной информации являются некоторыми ключевыми примерами.
Ограничения на роль/действие: Создайте ограничения или систему безопасности для каждого из этих действий поддержки. Возможность привязывать действия к различным уровням пользователей службы поддержки позволит избежать проблем в будущем при расширении службы поддержки. Возможность создания новых пользователей службы поддержки с различными правами снизит вероятность того, что кто-то без должных знаний изменит что-то, что ему не положено.
Администраторский и режим только для чтения: Это следует продумать с самого начала. Даже если изначально планируется, что вся поддержка будет иметь полный доступ, разработчикам также должна быть доступна какая-то часть, если они когда-нибудь захотят войти и помочь в отладке некоторых проблем клиентов. Также следует иметь возможность привязывать функциональность или вышеперечисленные действия к некоторым уровням пользователей с самого начала.
Управление пользователями службы поддержки: Это просто управление пользователями, которые имеют доступ к этому пользовательскому интерфейсу поддержки. Как правило, администраторы должны быть единственными, кто может создавать пользователей службы поддержки. Здесь также можно применять ограничения для пользователей.
Журналирование действий клиента: Я расскажу об этом подробнее в будущем блоге, но здесь можно вести журнал всех относящихся к клиенту активностей и облегчить доступ к ним для службы поддержки. Оно должно содержать легко читаемые журналы, относящиеся к конкретному клиенту или пользователю. Это может устранить необходимость для службы поддержки подключаться к серверам журналов или выполнять сложные запросы к базе данных. Это позволит нанять поддерживающий персонал, не знающий SQL или не умеющий читать сложные строки журналов на сервере.
Отчетность: В некоторый момент вам придется предоставлять отчеты о использовании вашей платформы и клиентской базе. Создание функциональности отчетов, которая сообщает информацию о пользователях продукта, сэкономит много времени вашей команде разработчиков, которое они бы потратили на повторные запуски одних и тех же выгрузок из базы данных. Если возможно, эти отчеты следует строить на основе некоторой запланированной фоновой задачи (cron job), чтобы они не нагружали ваши системы при увеличении размеров отчетов или запросов пользователей.

Что должно выглядеть?

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

Что может произойти, это то, что дизайн вашего UI поддержки будет скопирован из UI, которым пользуются ваши клиенты. Это также полностью допустимо и может быть более безтрениярным вариантом. Использование некоторых страниц (экрана входа, представлений списка, панелей управления и т. д.) может сэкономить время вашей команде разработчиков и уменьшить затраты на изменения в будущем.

Постоянные улучшения пользовательского интерфейса

Хорошо, это построенно. Я могу забыть об этом сейчас, верно?

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

Многие компании создают базовый пользовательский интерфейс поддержки, когда продукт достигает достаточного масштаба для его необходимости. У них может быть “один и сделано” подход к UI поддержки, и любые дополнительные улучшения всегда опускаются по приоритету в пользу разработки функционала или улучшения опыта клиента.

Зависит от того, как вы расставляете приоритеты, планируете и выполняете работу в своей команде (Agile, Kanban и т. д.), вы должны легко отложить определенное количество разработки функционала на каждый квартал/спринт/PI и попытаться потратить эту емкость на функции, которые запрашивает поддержка клиента.

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

Изменения в пользовательском интерфейсе поддержки, происходящие из функциональной разработки – что-то, обнаруженное через анализ влияния, не должны быть сделаны на основе этой емкости для команды поддержки. Она должна быть сохранена для самих специалистов по поддержке.

Если у вас есть задачи, поставленные разработчикам от команды поддержки, простой вопрос в конце задачи, который позволит пополнить эту емкость, может быть следующим:

“Может ли что-нибудь быть добавлено/изменено в пользовательском интерфейсе поддержки, чтобы решить эту проблему в будущем?”

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

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