Как мы организовывали поддержку Unidraw

Привет! Я Сергей, ведущий специалист поддержки в Т-Банке. За шесть лет прошел путь от обслуживания клиентов до поддержки и развития продуктов управления совместной работой.

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

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

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

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

Чтобы соответствовать ожиданиям пользователей, поддержка должна:

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

• Общаться на понятном языке. Когда получаешь скриптовые ответы в стиле «Ваше обращение очень важно для нас…», желание взаимодействовать отпадает сразу. 

• Давать однозначное решение каждого запроса. Поддержка может ответить быстро, внимательно выслушать и посочувствовать. Но какой в этом толк, если она не решает проблемы? На все вопросы должен прозвучать точный ответ, чтобы каждую проблему разобрали и решили.

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

Проблемы стартового процесса

До появления Unidraw мы работали в Whiteboard — внутреннем сервисе Т-Банка. Небольшой бюджет проекта не позволял построить комплексную поддержку, и мы общались с пользователями в чате в Time — корпоративном мессенджере компании. 

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

Для внутреннего сервиса поддержка может позволить «короткое плечо», когда на запросы отвечает разработчик, потому что все свои и говорят примерно на одном языке, со своими шутками и прибаутками. Разработчику не надо думать, как правильно подбирать слова, и можно легче договориться и понять друг друга.

С Unidraw процесс поддержки нужно было выстраивать на другом уровне, и вот почему: 

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

• Воспользоваться Unidraw может кто угодно. Например, школьник, который делает задание по составлению генеалогического древа, или архитектор для описания схемы работы высоконагруженного сервиса. Разработчику будет трудно общаться со всеми пользователями на одном языке, потому что придется переключаться со сложной инфраструктурной задачи на вопрос из разряда «А как у вас тут красивые стрелки рисовать?». Человеческий фактор и распределение внимания между задачами снизит качество общения, а у пользователя сложится впечатление, что он пришел не вовремя и поддержке не до него.

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

Этот список не полный, хотя и отражает набор проблем, которые не позволят соответствовать критериям качества. Так сформировалась потребность в первой линии поддержки. 

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

Шаг 1. Визуализировать логику поддержки 

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

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

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

В Unidraw можно вставлять ссылки в текст, если скопировать ссылку через ctrl (cmd) + c и, выделив нужный текст, вставить ссылку под него с помощью ctrl (cmd) + v. Это позволяет сделать переход на схеме сразу к документации и нужным системам.

В схеме логики поддержки Unidraw три области событий:

• пользователя;

• первичной поддержки (первая линия);

• команды разработки (вторая линия).

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

Шаг 2. Определить типы входящих сообщений и логику их тиражирования

Мы в команде поддержки Unidraw определили типы обращений от пользователей, для которых нужен свой процесс действий и ответов. Вот эти типы.

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

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

Консультация. Пользователь может задать вопрос или попросить подсказать решение задачи. В этом случае важно дать полный ответ и зафиксировать результаты консультации. Мы развиваем Unidraw так, чтобы для полноценной работы с ним не требовались подсказки и документация, поэтому каждая консультация — кейс для анализа и улучшения продукта. После анализа вопросов часто задаваемые переходят в разряд доработок с переквалификацией в виде «Запрос на улучшение» или ответ на них переносится в FAQ. В него еще могут попасть ответы на необычные вопросы.

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

Для схемы использовали нотации из BPMN, логика строится на типах блоков «Задание», «Или», «Сложный оператор (Cases)». Для нас этого оказалось достаточно.

Для каждого типа обращения описали логику действий под все ситуативные варианты. Часто этот процесс в командах поддержки называется проектированием процедур. Затем согласовали логику со всеми участниками процесса. 

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

Шаг 3. Определить места для коммуникации

Для начала мы изменили окно обращения пользователей в приложении. 

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

1. Отзыв. Пользователь может дать обратную связь.

2. Поддержка. Пользователь сообщает, что ему нужна помощь.

В окне обратной связи добавили поле E-mail — адрес, по которому первичная поддержка может обратится, чтобы рассказать о состоянии задачи, или ответить на срочный вопрос, — та самая точка коммуникации с пользователем.

Написанное сообщение пользователя попадает в систему Service Desk, где уже определяется тематика обращения и с ним работает первая линия поддержки.

В зависимости от типа логики первая линия собирает информацию и сразу отвечает пользователю или cначала передает запрос на вторую линию — разработчикам, заводя задачу в Jira. Для этого в Jira есть типы задач Request, при создании которых добавляется ссылка на запрос из Service Desk. Эти типы задач позволяют первой линии быстро просматривать, готовы решения для пользователей или нет.

В некоторых случаях логика обработки сообщений требует быстрых ответов. Для этого мы завели канал в Time, где автоматически добавляются сообщения из Service Desk. Специалисты первой линии могут вызвать инженеров в этот чат в тред с сообщением и попросить помочь ответить на технический вопрос или срочно решить проблему. Этот канал помогает разработчикам и инженерам с вопросом «И куда мне с этим идти?», потому что все можно уточнить друг у друга в чате.

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

Мы добились того, что во всех системах — Service Desk, Time и Jira — 

есть метрики по скорости ответа, которые нужны для анализа процесса. 

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

Шаг 4. Подготовить базу знаний

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

Для структурирования документации я создавал шаблоны по разным разделам, например:

• Безопасность.

• Инициативы.

• Исследования.

• RoadMap.

• Релизы.

• Инструкции поддержки.

• Предложения от пользователей.

• Внутреннее FAQ.

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

Несмотря на древовидную структуру и встроенный поиск в Confluence, cистема документации оказалась сложной, поэтому я использовал доску Unidraw: добавил ссылки на разделы в блоки логики ссылкой под текст. Теперь специалисту первой линии поддержки при поиске решения можно перейти в нужный раздел документации прямо с доски в Unidraw.

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

До того, как команда разработки запустила FAQ в отдельном разделе сайта, в качестве быстрого решения использовали сам Unidraw: разместили ответы прямо на доске FAQ Unidraw. Минус это способа: доска не индексируется поисковыми роботами, например Яндекса или Гугла, а пользователи часто ищут информацию через поиск. 

Чтобы у первой и второй линии поддержки вся важная информация была под рукой, ссылку на документацию и доску с логикой в Unidraw я добавил в канал в Time, где они и общаются. Хорошо, что в Time можно привязать нужные ссылки прямо в шапке описания канала.

Остался последний этап — презентация и финальное согласование со всеми сторонами процесса поддержки.

Шаг 5. Финально согласовать и запустить процесс

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

Я подготовил презентацию так, чтобы она полностью строилась вокруг доски Unidraw, где расписана логика всего процесса поддержки.

Полная схема процесса, который у нас получился:

На общем созвоне я передал ссылку участникам, чтобы они зашли на доску и финально перепроверили логику и ссылки из доски на документацию и Jira для заведения задач.

Я детально рассказал последовательность логики, показал, как работают ссылки из доски. Мы проговорили о SLA для каждой из сторон процесса коммуникации, по ответам по каждой цепочке логики. После рассказа по каждому узлу логики спрашивал: «Есть ли вопросы или необходимость доработки?» 

Еще я показал, как проходят сообщения от Service Desk, появляются задачи в чате в Time, что можно в треде отвечать на запросы, общаясь друг с другом.

Финал презентации — демонстрация сводных метрик, которые собираются с систем, участвующих в процессе поддержки. Среди них метрики:

• отправки формы из приложения; 

• Service Desk; 

• бота чата в Time;

• Jira. 

Дополнительно я рассказал, как читать метрики для улучшения процессов поддержки и следить за SLA, используя их.

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

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

С этого момента спроектированный процесс поддержки заработал.

Метод по шагам

Мы с вами прошли по методу, который я применяю для построения процессов поддержки. Кратко перечислю шаги:

1. Подготовить визуализацию на Unidraw.

2. Определить: 

   • Типы входящих обращений.

   • Их тематику и логику для тиражирования.

   • Вероятный срок для ответа — сколько пользователь будет ждать, это пригодится при формировании SLA.

   • Логику обработки сообщений для тематик.

3. Определить каналы исходящих — как пользователи получат ответ:

   • Есть ли у вас информация, куда писать пользователю?

   • Есть ли готовый формат для того, как писать ответы пользователю?

4. Определить места для коммуникации участников процесса:

   • Где будет ваша документация.

   • Система для общения типа чата для быстрых решений.

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

5. Подготовить базу знаний. Создать:

   • Структуру и шаблоны к внутренней документации.

   • Внутренний раздел документации для первой линии с FAQ.

   • FAQ для пользователей для частых или необычных вопросов от пользователей на сайте сервиса. Проверить, что он индексируется поисковыми системами.

6. Связать ссылками описание процесса с узлами коммуникации:

   • Добавить ссылки на документацию к логике на доске Unidraw.

   • Добавить ссылку на доску с логикой в Ubidraw и документацию в чате в Time.

7. Провести финальную встречу, чтобы все согласовать и зафиксировать договоренности по SLA с участниками процесса. 

8. Получить обратную связь о проектировании.

Мои рекомендации

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

Не стоит заморачиватся над тем, как правильно рисовать логику, — можно использовать простые и доступные инструменты, такие как доски в Unidraw. Меня в свое время вдохновил подход Андрея Шапиро, который создал метод «Карты процесса-опыта, проектирование услуги через ее визуализацию», где он описывает интересный опыт построения услуги очень простыми визуальными методами.

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

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

Чтобы прописать конкретные условия для взаимодействия разных команд, нужно заранее утвердить SLA между участниками, а для этого придется научится собирать метрики. Если у вас нет готового фреймворка по метрикам для процессов, рекомендую рассмотреть Kanban-метрики. Мой коллега Павел Ахметчанов и сообщество Kanban-менеджеров как раз собирает их на открытой доске Unidraw «Kanban-метрики».

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