Развитие системы службы поддержки Okdesk: долгосрочная стратегия или пожелания клиентов? (часть 2)

Лучшее
Опубликовано: 19.12.2016
Обновлено: 20.03.2022
Время на чтение: ~8 мин.

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

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

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

Система службы поддержки Пожелания клиентов. Реальные истории. Системные решения.

Перейдем от теории к практике и реальной жизни. В Okdesk имеется панель (dashboard) с оперативной информацией о работе службы поддержки:

Служба поддержки. Оценка качества

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

Оказалось, что бизнес-процесс компании реализован так, что у заявок есть статусы. В этих статусах, например, ожидается ответ от автора обращения, или ожидается поставка запчастей. Запросы, которые "висят" в таких статусах долгий период, считаются системой просроченными (и, соответственно, подсчитываются на одной из плиток). Клиент предложил реализовать настройку параметров фильтрации для плитки. Фактически он хотел исключить заявки в “замороженных” статусах из подсчета. Подойдя к вопросу системно, и "подключив" к рассмотрению другие кейсы и требования, мы нашли иное решение — реализовать в настройках бизнес-процессов параметр “Учитывать время” для статуса. Таким образом, клиент сможет настроить “заморозку” счетчика времени, и отложенные заявки не будут считаться просроченными.

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

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

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

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

Система службы поддержки. Как улучшать отношения с клиентами?

Когда готов новый релиз (в среднем это происходит раз в 3-5 недель), мы проверяем все тикеты в указанном состоянии, и если какая-то часть из них полностью или частично решается новой функциональностью — сообщаем радостную новость пользователям. Пользователи довольны и ощущают нашу заботу :)

Бесплатное тестирование системы службы поддержки!

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

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

Как было сказано в первой части статьи, мы формируем долгосрочный план развития продукта, который может немного изменяться и дополняться. Когда план есть — нужно его реализовывать!

Перед разработкой кода наши аналитики пишут постановки (спецификации или ТЗ). Все требования разбиваются по крупным функциональным модулям и внутри модулей сгруппированы в смысловые блоки. Например, есть крупный блок “01. Модуль учета заявок”. В нем — ряд смысловых блоков “01.01. Карточка заявки”, “01.02. Комментарии к заявкам”, “01.03. Список заявок” и так далее. Отдельно фиксируются изменения в требованиях по каждому релизу. Для каждого требования описываются кейсы, варианты решения и, при необходимости, причины выбора одного из вариантов. Для всех — ведем (и актуализируем при изменениях) список Test-кейсов. Дорогих специализированных инструментов нет — на текущий момент достаточно Google Docs.

По итогам зафиксированного и проанализированного требования, начинаем разработку. Все задачи попадают под процедуру Code Review (один из основателей проекта отвечает за технологическую часть). Далее новая функция "выкатывается" на тестовый сервер для поверхностного визуального тестирования — в нашем случае осуществляет человек, разработавший требование. При наличии замечаний — отправляем на устранение, если замечаний нет — задача уходит на более глубокое ручное тестирование. По итогам устранения всех замечаний новая функциональность покрывается автотестами в соответствии с написанными Test-кейсами.

Когда все задачи текущего релиза готовы — проводим еще одно ручное тестирование версии, где собраны все новые функции. Нет замечаний — скрещиваем пальцы (шутка :)) и выкатываем новые функции.

Система службы поддержки как инструмент управления требованиями

Релизы нашей системы службы поддержки мы выпускаем регулярно, в среднем каждые 3-5 недель. В каждый релиз включается одна большая функция или новый модуль, а также ряд улучшений сделанного ранее. Случается, что некоторые большие функциональные блоки не умещаются в один релиз — например, в конце 2016-го года мы выпустили мобильное приложение для работы с заявками “полевых” сотрудников. На его разработку ушло около 3 месяцев.

Наши "помощники" : Google Docs для документов и управления требованиями, Redmine для управления разработкой, GitHub для кода, Slack для коммуникаций, Okdesk для технической поддержки и работы с обратной связью от клиентов.

Вместо постскриптума

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



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

Поделитесь статьей
Kirill fedulov photo
Кирилл Федулов
Сооснователь и директор по развитию Okdesk. Около 10 лет проработал в компании Naumen, где занимался внедрением ITSM и Service Desk систем в крупнейших российских компаниях (Полюс, Тинькофф, ЛСР и др.). Эксперт по автоматизации процессов техподдержки и сервисного обслуживания.
Популярные материалы
Опыт клиентов
Зачем мигрировать с корпоративной service desk на Okdesk — Опыт «Совтех»
14.09.2022
От экспертов
Help desk система: что это и зачем она нужна вашей компании?
16.09.2022
Лучшее
10 признаков того, что вашей компании нужна новая help desk система
29.07.2022
От экспертов
Как help desk система поможет сделать сервисный бизнес более рентабельным?
29.07.2022
Лучшее
Отличия service desk и CRM: совмещаем две системы в одну
12.09.2022
Руководство: «12 ошибок, которые лишают сервисный бизнес денег»
Полезные материалы
Дважды в месяц о развитии и автоматизации сервиса, техподдержки и выездного обслуживания.
 
Нажимая на кнопку «Подписаться», вы даете согласие на обработку своих персональных данных.
Полезные материалы
Дважды в месяц о развитии сервиса, техподдержки и выездного обслуживания.