Как настроить правильную техподдержку (helpdesk, service desk на коленке)

Оглавление

Экономический эффект поддержки

Что это и для чего нужно 

Основные правила хорошей поддержки

• Правила работы. Как работаем

• Доступность и точки входа. Где работаем

• Интерфейс. В чем работаем

• Сервисы. По каким направлениям работаем

• Взаимодействия. Как общаемся в процессе работы

• Гомеостаз. Как поддерживается рабочее состояние процесса

• Регламент и бизнес-процессы. Чем руководствуемся при работе

• Приоритеты. Как выстраиваем очередь задач

• База знаний. Где и как храним информацию

Заключение

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

Экономический эффект поддержки

Начнем с того, что часто пропускается при рассмотрении будущего процесса поддержки - такое внедрение обычно стартует из разряда «как все достало, давайте внедрять». Рассмотрим эффекты для компании от поставки адекватного процесса «service desk» 

1. Косвенный. Как и от любых внедрённых бизнес-процессов вы получаете положительный эффект «в долгую». 
   1. В виде высвобожденного времени специалистов, которое сейчас тратится на хаотическую обработку заявок. Если вы читаете эту статью, такие заявки у вас, скорее всего, есть :) Будет система со сроками, будет автоочередь задач - все негативные моменты ручной диспетчеризации, жалобы по поводу забытых заявок уйдут, ответственности станет больше
   2. В виде дополнительной расположенности клиентов к вам - продлять поддержку, совершать доп. продажи лояльному клиенту проще
   3. Снижается вес риска ухода специалиста - если поддержка перестаёт быть уникальным знанием, то новые сотрудники быстрее входят в работу и это принципе возможно без краха системы
   4. Оцифровка и объективность данных - система фиксирует сроки обработки, ответственных, количество запросов, себестоимость заявок и прочее. Арбитраж ситуаций с недовольным клиентом («мне ни разу не помогли!»), с перегрузкой специалистов работой («не успели, потому что у нас 1000 задач!») и т.д. решаются по данным, а не по эмоциям. Можно планово масштабировать сервисы при необходимости. 
   5. Снижение излишних затрат. Частый пример, вопрос выходит за рамки поддержки, но специалист все равно его делает - по факту лишние затраты времени на пост-согласование с клиентом стоимости и возможности оплаты вообще, вместо предварительного согласования.
   6. Качество продукта растет. Процесс предоставления поддержки - это практически бесконечный процесс улучшений. Сейчас вы создадите одну версию, через месяц поймете, что, например, запросы вида «А как месяц закрыть?» должны решаться в другие сроки и не в режиме аврала - запустите их по иному маршруту сервиса. Если под качеством понимать соответствие заявленным стандартам, то тенденция безусловно будет положительной.
2. Прямой. Тут больше подходит для внешнего клиента, но и для для внутреннего иногда применимо
   1. Соответствие лимитам. Количество услуг поддержки должно оказываться согласно тем договоренностям, что вы выставили. Если клиент свой лимит исчерпал, то система должна на это реагировать - предложить продлить сервис, перенести вопрос на другой период (в зависимости от того, что вы в процессе предусмотрите). 
   2. Контроль стоимости обращения. Это относится к инцидентной системе управления, задача системы - уметь инциденты создавать. Например, «превышен лимит затрат в 10 часов специалиста на заявку» - такой инцидент получит руководитель по факту его происхождения, а не случайно найдет в отчете через месяц. 
   3. Своевременное пополнение бюджета. «Здоровая» компания должна получать стабильное финансирование с определенной частотой. То есть, не «менеджер решил проверить, у кого поддержка заканчивается и сделать всем счета», а «система заранее подготовила счета клиентам согласно их запросам и запустила процесс контроля оплаты».

Картинка из разряда «Как процесс поддержки представить на графике». Подробнее о показателях дальше по тексту

к оглавлению

Что это и для чего нужно 

Техподдержка - это сервис решений вопросов пользователей по взаимодействию в определенной среде. Суть этого определения в том, что 

1. Это сервис - у него есть свой порядок предоставления, рамки и правила. (По каким каналам и вопросам можно получать ответы, в какие сроки будет ответ)
2. Сервис оказывается персонально - конкретному человеку (пользователю среды) по его конкретному вопросу. Это не обучение пользованием продуктом, это не справочник с общим доступом. Да, такие функции тоже должны быть в системе. Да, ответом техподдержки может быть ссылка на статью, решающая вопрос пользователя. Но как нельзя поддержкой называть общедоступную документацию, так и нельзя общаться с эмоциями вроде «У меня тут отчет запрашивают какой-то… А времени нет!».
3. Среда должна быть определена. Ваша поддержка может быть точкой входа как для вопросов по 1С, по Windows, по почтовику, так и по предоставлению 2-НДФЛ, запросов на отпуск и т.д. Вы сами определяете спектр вопросов, которые будете решать в рамках этого процесса. У нас, например, и задачи собираются, и консультации оказываются и документы запрашиваются через «одно окно». 

Можно ли жить без такого сервиса? Да, бесспорно. Будет ли при этом у ваших сотрудников и клиентов меньше вопросов? Нет, они просто будут действовать как умеют (или вовсе не действовать, а жаловаться на тяжелую долю). Будут слать письма по почте с копией на всех и вся, тратить время своего начальника, бегать по офису и «пытаться решить вопрос». Кстати, гораздо хуже узнать через несколько лет работы, что ваши юристы тратят на один договор «от двух дней», вместо того, чтобы делать его за 30 минут в настроенной программе - просто потому, что однажды «что-то сломалось, а куда с этим идти-то, мы не знаем…», чем уметь обрабатывать такие ситуации. 

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

• Приказы уровня «по 1С обращаться напрямую к Андрею и не дергать бухгалтерию!», «2-НДФЛ выдается каждый четверг в порядке очереди в кабинете 218»

• Попытки свести поддержку в почту: «Пишите на help1c@supercompany.ru по 1С», «Не пишите на help1c@supercompany.ru по вопросам резервов, ими заведует кладовщик!». Бонусом получаем письма [RE:117 Ошибка!!!], где ведется переписка по разным вопросам за несколько месяцев - и уже никто не помнит, что нужно в итоге, обращения стихийно возникают в процессе и умирают.

• Супер-идеи - «Сейчас мы в 1С быстро напилим Заявку, сделаем статусы и будет счастье». Это действительно работает, пока есть 2-3 запроса в неделю. С ростом различных сервисов, вы начинаете постепенно захлебываться в количестве различных статусов «В работе», «Ожидает», «Передан в бухгалтерию» и т.д. - их, оказывается, тоже надо поддерживать. Добавить новый сервис - та еще головная боль, как это все работает знал только Петрович, который уволился на прошлой неделе. Иногда вашему монстру «Заявке» надо одновременно быть в двух статусах, например, «Согласована» и «В очереди на следующий месяц» - о таком лучше вообще не думать.

• Мы все поняли. Давайте развернем нормальный helpdesk. «Но только чтобы с там и договора согласовывать можно было! А еще нужен календарь!» и подбор «идеальной системы» на пару лет, в которой есть все-все-все и еще немного

• …

Как и с любым бизнес-процессом тут нужно работать итерациями, внедрять мелкие части процесса в работу, но делать это часто. Например, наш процесс оказания поддержки проработан и автоматизирован на 136 попугаев и 57% - есть куда расти

Но это нисколько не мешает нам работать по этому процессу уже сейчас - система настроена и обеспечивает качественное выполнение.

Мы построили довольно хорошую системы поддержки наших клиентов внутри своего основного продукта «Процессы 3». Она ни разу не претендует на звание «единственно верная и покрывающая любой кейс система поддержки», у нас тоже есть недовольные клиенты (претензии, кстати, тоже пришлось научиться обрабатывать), но все-таки одно неоспоримое преимущество у нее есть: наша система на 99% кастомизируема. Она построена на бизнес-процессах с дополнительными фишками вроде работы через браузер, почту, telegram, всеми любимыми статусами, календарями, отчетами, настраиваемыми рабочими местами и т.д. Даже сейчас мы меняем наши процессы работы поддержки прямо по ходу пьесы и от этого никто не страдает. 

Переходим к тому, что обязательно должно быть в системе поддержки и как это должно использоваться (все, о чем пойдет речь дальше - настроено в системе, а не запрограммировано кодом). Мы осознанно не будем углубляться в методологию, ваши пользователи, скорее всего, даже мельком про ITIL и иже с ним не слышали. 

Основные правила хорошей поддержки

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

• Правила работы. Как работаем
• Доступность и точки входа. Где работаем
• Интерфейс. В чем работаем
• Сервисы. По каким направлениям работаем
• Взаимодействия. Как общаемся в процессе работы
• Гомеостаз. Как поддерживается рабочее состояние процесса
• Регламент и бизнес-процессы. Чем руководствуемся при работе
• Приоритеты. Как выстраиваем очередь задач
• База знаний. Где и как храним информацию

Разберем каждый из этих пунктов с небольшими примерами

к оглавлению

Правила работы

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

1. Место оказания поддержки. Куда пользователю нужно идти, чтобы получить помощь. Например, «Единый портал технической поддержки доступен по адресу www… Регистрация на портале происходит … ». Обязательно назовите этот ресурс, чтобы избежать дальнейшую подмену понятий, например «… (далее [Портал])».
2. Состав поддержки. На какие вопросы пользователь получит ответ, на какие - нет. Не нужно обнадеживать себя - все равно вопросы будут не только из этого списка, поэтому и нужна квалификация вопросов, которую рассмотрим дальше, но правила следует описать все равно. Например, «На портале вы получите ответы на вопросы по функциям и возможностям Продукта, сможете зарегистрировать нового контрагента и согласовать договор» или «Вы получите доступ к сервисам технической поддержки по 1С, согласования договоров, инициации процедуры проверки контрагента, согласно Приказу №…». Важно простыми словами описать что будет - лучше написать меньше, а в инструкциях первой линии техподдержки уже прописать детальную квалификацию - Ваша задача не отпугнуть пользователя, но и не дать ложных надежд, что поддержка все сделает за него. Важно, что если вы даете клиенту (внутреннему или внешнему) вариативность сервисов, то следует в соглашении прописать эту вариативность «Критическими являются вопросы, поставленные с пометкой СРОЧНО. Вопросы генерального директора всегда ставятся с пометкой СРОЧНО». 
3. Предмет поддержки. То есть, "как действовать для получения помощи». Нужно договориться, что будет «центром» обсуждения и уметь его правильно наполнить. Обычно запрос оформляется в Тикет (в нем фиксируется тема, добавляются файлы и описывается проблема). Тут самая важная часть - для клиента на один вопрос один тикет, но с разными статусами. Статусы показывают, что сейчас происходит с тикетом. У вас же по этому тикету создаются задачи - много, разные и без статусов. Так достигается максимальная кастомизируемость обработки заявки пользователя. Разные типы обращения должны обрабатывать разные люди по разным маршрутам, но клиенту это не интересно - у него есть вопрос, который должен быть решен, детали не волнуют. Еще раз - клиент создает Тикет, в тикете статусами отображается, на каком мы этапе. По тикету создаются задачи на сотрудников поддержки, задачи не видны клиенту. Мы подробнее это разберем позже, пока зафиксируем так. Соответственно, для клиентов поддержки желательно описать, как именно ставить задачи, что означают статусы и как будут приходить уведомления об их смене. 
4. Максимальные сроки реакции. Пользователь должен знать примерные сроки реакции на вопросы. Например, «Техническая поддержка предоставляется в размере до 3 вопросов в день от пользователя, гарантированный срок ответа - 3 рабочих дня. Срок поддержки может быть изменен в связи с загруженностью службы». Это не значит, что вы не будете принимать больше 3 вопросов в день, это не значит, что на запрос «все пропало» вы будете неторопливо кликать на крестик закрытия окна, т.к. «Еще не пришло время». Это сроки для клиента, а ваши специалисты должны работать минимум в 3 раза быстрее. Вы должны влезть в этот срок в случае полного провала, когда умерли последние бэкапы и уволились все сотрудники, проще говоря :) Важно, что если у вас с клиентами вариативность сервисов, то в соглашении следует прописать эту вариативность «Реакция на критический запрос - 1 час, реакция на вопрос генерального директора - 1 час, без учета выходных дней». 
5. Исключения из правил. Здесь следует описать, что делать, если что-то пойдет не так. Например, если поддержка не отвечает, пользователя не устраивает оказанный сервис или ваш портал недоступен. Например, «При недоступности Портала … направляйте запрос по электронной почте … с пометкой Технической поддержке», «Если у вас возникли вопросы по качеству оказания сервиса, то оставьте ваш комментарий по электронной почте …». 

Например, у нас основные моменты прописаны в договоре (это место, сроки и состав в сжатом и упрощенном виде). Дополнительно есть «Соглашение по сервису», которое рассказывает пользователю больше информации об услуге. Даже если вы оказываете поддержку для внутреннего клиента, то все равно такое соглашение нужно - все должны понимать, что, в каком объеме и сроках вы производите. 

Ну а клиентам мы записали и отправили простое видео с общим обзором «их стороны работы», посмотреть можно тут

к оглавлению

Доступность и точки входа

Система поддержки должна быть доступна пользователям в «онлайне» в виде приложения со своим интерфейсом. Идеально, если это будет браузер, который открыт почти всегда. Неплохой вариант, если это будет сервис внутри 1С или другой системы. Гораздо хуже, если вы решите поддерживать пользователей исключительно через почту, по телефону или мессенджеры. Важно! Задать вопрос и получить на него ответ можно через мессенджеры, звонки и письма, но обрабатывать эти обращения вы должны именно системно. Поддержка других каналов, скорее, бонус системы. У нее нет обязательного требования «оказывать поддержку там, где пользователю удобно», напротив, продуктом поддержки будет «вовремя обеспеченный знанием о продукте пользователь». Всегда нужно сначала выстроить систему поддержки с одним, но понятным входом заявки, затем уже анонсировать, что точек входа несколько.

Наши «Процессы» загружены в УНФ и опубликованы в вебе (забегая вперед, такой сценарий возможен и в отдельной базе, и внутри старенькой УТ 10.3). У нас прием заявок идет 

• Через специальное настроенное рабочее место клиента. Об этом знают все наши пользователи

• Некоторые заявки мы принимаем через форму обратной связи на сайте и письма. Об этом знают некоторые

• Задачу можно поставить в telegram-боте. Об этом знают единицы (вот, кстати, пример того, как можно с telegram систему подружить)

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

к оглавлению

Интерфейс 

Кто вообще работает в системе оказания технической поддержки? Тут по классике управления бизнес-процессами (если не знаете эту удобную классификацию, приходите к нам на бесплатные вебинары):

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

У каждой из этих ролей должен быть свой интерфейс, у каждой роли свои потребности от системы. Минимальный состав элементов управления будет такой:

Инициатор тикета должен иметь возможность:

• Создать тикет по нужному сервису
• Посмотреть прошлые тикеты
• Видеть оперативные оповещения от других пользователей системы (преимущественно, от специалистов)
• Смотреть статьи базы знаний - правила и регламенты работы, важные новости

Рабочий стол клиента поддержки

Специалисты:

• Видеть задачи по разным тикетам в порядке автоматического приоритета. Специалист не должен думать, что делать следующим шагом, всегда берем то, что имеет больший приоритет. В задаче специалиста уже содержится необходимая для решения тикета информация в зависимости от уровня поддержки - если это первый уровень, то это описание клиента, доступы к нему. Для второго уровня уже выводится оформленный комментарий от первого уровня поддержки.
• Иметь доступ к статьям базы знаний и документации. Многие вопросы решаются просто ссылкой на документацию. Чтобы продолжать и дальше работать в этой удобной манере, документация должна быть пополняемой - это должно управляться прямо по выполнению процесса поддержки (ставиться задача на пополнение документации на первую линии поддержки).
• Планировать работы по тикетам. Некоторые тикеты решаются в несколько приёмов и не за 5 минут. Работа по таким тикетам должна быть внесена в календарь для оценки занятости служб поддержки
• Видеть личные показатели работы. «А насколько я в этом месяце исполняю план / закрыл задач / допустил ошибок?» - эта информация первое руководство к действиям ответственного сотрудника, которое должно быть перед глазами всегда
• Видеть оперативные оповещения от других пользователей. Это обычная лента оповещений, как хроника в Facebook - уведомления в порядке их свежести

Оперативная страница специалиста-разработчика

Планирование задач специалиста-разработчика

Внешний вид задачи со встроенной справкой

Одна из рабочих страниц специалиста первой линии поддержки

Руководитель

• Видеть происшествия, которые возникли по ходу процесса поддержки. Система должна мониторить важные вещи (потенциальные проблемы, как уже говорили выше) и оперативно создавать на руководителя задачу для ручного управления.
• Видеть показатели процесса поддержки. Это может быть счетчики по важным областям, показатели работы сотрудников и т.д.

Оперативная информация

Динамика по количеству новых тикетов по дням

График затраченного времени поддержки по дням по клиентам

Контроль тикетов - доска из карточек «ожидают нас», «ожидаем мы»

Картина рабочего дня специалистов

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

• План / факт работ (день и неделя). Сколько запланировали и сколько успели из этого сделать
• Просрочено задач в разработке. Сколько задач второй линии вышли из своего срока и по ним нужно разбираться с ходом работ
• Количество ошибок за 14 дней. Баги, которые мы допустили в процессе разработки
• Тикеты в работе. Общее количество тикетов, которое находится сейчас в работе для оценки общего уровня загруженности
• Просроченные тикеты. Количество тикетов, процессы по которым просрочены. Должно быть 0
• Время по клиентам. Сколько времени по поддержке потратили на тех или иных клиентов в день
• Рабочий день сотрудников. Карта дня сотрудников, где видны отметки времени работы по задачам
• Канбан-доска по активным тикетам в ключе «на чьей стороне мячик»
• Динамика тикетов по дням возникновения. Чтобы отслеживать пики запросов

Показатели процесса - это как приборная доска, вы можете обращать внимание на что-то иное, главное, чтобы было на что обращать внимание :)

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

к оглавлению

Сервисы 

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

У нас есть несколько вариантов сервисов в рабочем месте клиента:

1. Вопрос по функционалу. Это самый сложный процесс, выдаваемый наружу. Тут внутри и вопросы к первой линии поддержки по функционалу Процессов, и указания багов, и предложения по доработкам.

2. Запрос документов. Если нужно получить от нас какие-то сканы или оригиналы

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

Для запуска каждого сервиса пользователю нужно нажать на соответствующую кнопку - тогда система создаст и откроет для заполнения тикет. Пользователь его наполнит (может в несколько этапов это делать, пока статус не поменяет, тикет будет в «черновиках»), прикрепит вложения и запустит в работу. Система тикет подхватит и запустит его в обработку. О том, как система обеспечивает получение пользователем ответа, рассмотрим в разделе «Регламенты». 

Это старт обычного процесса поддержки - по вопросу клиента

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

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

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

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

к оглавлению

Взаимодействия

В ходе получения поддержки пользователю нужно всего три вещи:

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

2. Знать дату следующего шага. Это не обязательно дата и время, до которого пользователь получит ответ (тут уже от ваших соглашений зависит). Клиент чувствует себя спокойно, если знает, что «с его вопросом до такого-то числа что-то случится».

3. Получить ответ на свой вопрос в указанный срок

С пользователем должно быть налажено взаимодействие в рамках его вопроса. Клиент должен знать, что если он сделает такой такой-то набор действий, то его запрос примут в обработку. О том, что его запрос увидели, он узнает так-то и так-то. У пользователя сразу же рождается в голове «мини-проверка» - если мне не ответили в такое-то время, то что-то не так и стоит проверить, а туда ли я написал. К тому же, у пользователя должна быть возможность общаться в рамках своей заявки с «живыми людьми» - в комментариях к тикету важно иногда что-то спросить или уточнить срок.

У нас общение идёт в рамках тикета. Пользователь после создания тикета отправляет его в «плавание» по определенному маршруту. Система создаёт нашим специалистам задачи, что-то транслирует обратно в тикет. Но часто у пользователя возникают вопросы по ходу, например «А может быть вот так надо?». Чтобы такой вопрос не ломал цепочку задач бизнес-процесса (технически, процесс уже может быть далеко у программистов на анализе), в таком случае ответственный сотрудник поддержки подключается в тикет и отвечает на этот вопрос либо о том, что для анализа требуется время, либо принимая ответ пользователя и завершая процесс. Все вопросы клиента попадают в общую ленту рабочего места стола специалиста поддержки и обрабатываются по мере поступления. Тут не вводится дополнительных сложных правил - клиенты бывают разговорчивые и наоборот молчаливые - максимальный срок ответа 1-2 часа в рабочем интервале, часто обрабатывается раньше. Пользователь получит ответ оповещение об ответе на почту (или в telegram) - сможет так же на это письмо в почте ответить и оно прилетит обратно в задачу в 1С. 

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

Так выглядит тикет для клиента

А вот так он смотрится «внутри системы». Специалисты же получают задачи по каждой стадии этого тикета.

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

То есть, у нас есть универсальный документ, один из его видов мы настроили в «тикет», вокруг него прописали процессы, выдающие специалистам задачи. Клиент видит только тикет (в нем идет переписка, устанавливаются статусы, скидываются оповещения), специалисты работают по задачам процесса. Тикет один, задач много - согласно маршруту процесса.

к оглавлению

Регламент и бизнес-процесс

Тут начинается самое интересное :) Нам нужно обеспечить ожидаемые результаты по каждому тикету. Чтобы все тикеты обработались одинаково хорошо, нужно:

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

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

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

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

1. Вопрос по функционалу. Что-то спросили по программе - нужно в обычном режиме посмотреть документацию, ответить на вопрос
2. Ошибка. Случилось что-то некритическое, например, в новом релизе допустили в коде баг, который не даёт создать группу побочного справочника 
3. Критическая ошибка. Любая ошибка, которая делают работу невозможной: 1С перестаёт запускаться, шаблон процесса не создаётся, веб-клиент не открывается. 
4. Предложение по доработке. Что-то из разряда «Было бы здорово, если бы вы добавили отображение всех комментариев в едином месте бизнес-процесса»

Классификацию нужно проводить потому, что она влияет на:

• Сроки процесса
• Схему обработки

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

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

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

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

Для «ошибки» и «критической ошибки» формируется уже задача на разработчиков (следующая линия поддержки), система переносит в неё пояснения от первой линии, назначает задаче срок и приоритет. 

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

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

• Банальные правила работы с клиентом в профессиональном стиле (что делать, чего не делать, вежливо обращаться, но не работать за клиента - помогать в настройке)
• Как квалифицировать обращения, по каким правилам
• Какую информацию нужно у клиента уточнить для воспроизведения ситуации

Разработчики должны знать:

• Правила приоритетов задач (критические решаются быстро и без разбора «кто виноват»)
• Что такое «решить задачу» - некоторые думают, что его задача просто диагностировать ошибку и описать, когда она появляется

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

Вся эта работа описывается несколькими регламентами - правилами работы специалистов, которые зафиксированы в системе, в дополнение система сама по этим регламентам выдает задачи. Для обычной поддержки клиентов по нашему основному продукту есть регламент «Поддержка» (инициатива идет от пользователя). По проектным работам, где важна другая оперативность работ, используется регламент «Оперативная поддержка» (инициаторы запросов - система автотестирования или пользователи). Мы сейчас рассматриваем общий случай с обычной поддержкой, если интересен второй - пишите.

к оглавлению

Гомеостаз

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

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

Правила: «Для корректного выполнения процесс поддержки должен быть снабжен «процессом-компаньоном», в котором сотрудники должны актуализировать состояние тикетов».

к оглавлению

Приоритеты

Как уже писали выше, сотрудник не должен думать, что и в какую очередь делать. Система приоритеты должна назначать сама. Это простое правило помогает сделать так, чтобы тикеты исполнялись не в зависимости от эмоций, а в порядке, настроенном шаблонами. Здесь сколько важен не сам приоритет, а то, что он в принципе существует и назначается в зависимости от каких-то данных. Например, у нас задачи первой линии исполняются в порядке возникновения, они, как правило, простые. А вот задачи второй линии уже лежат в рамках приоритизации в зависимости того, что внесено в задачу:

Правило: «Необходимо выработать ручные или автоматические правила приоритезации задач и тикетов заранее»

База знаний

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

Обязательные статьи базы:

• Порядок работы с технической поддержкой. Для клиента
• Порядок работы с клиентом по технической поддержке. Для наших специалистов
• Описание-документация по частым вопросам или вашему продукту. Для клиентов (этот вид должен быть автоматически пополняем, но это уже другая история)

Правила: «База знаний должна быть», «База знаний должна содержать актуальную информацию по оказываемым сервисам и работе в них».

к оглавлению

Заключение

Словом, описание нашего процесса поддержки на текущий момент в цифрах можно представить так:

136 - общая оценка в баллах, можно сказать, «выше среднего». Значит, процесс хорошо описан и стабильно работает.

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

к оглавлению

«Простые процессы»