Блог Okdesk
Многие компании уже выбрали Okdesk
Новости04 дек. 2016

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

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

В разработке системы мы находим баланс между планами развития на несколько лет вперёд и текущими "хотелками" наших активных пользователей. Очевидно, что нужно поддерживать как лояльность тех, кто уже доверил нашему сервису свой бизнес (улучшать созданные функции, повышать удобство работы и т.д.), так и развивать те функциональные блоки, которые ориентированы на компании, чьи проблемы мы решаем не в полной мере. Задача кажется легкой, если у вас есть большое количество рук, голов и времени — но в реальности всё обстоит иначе.

В этой статье подробный рассказ, о том, как мы решаем описанные выше проблемы.

Система службы поддержки. Как мы развиваем Okdesk?

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

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

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

Разработка сервиса для автоматизации. Опыт

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

Таким образом, в backlog-е продукта есть крупные “стратегические” блоки, и накапливаются задачи по улучшению созданных ранее функций меньших масштабов. Новые и большие модули важны для расширения областей использования продукта (выход на новые отрасли, целевые аудитории и т.д.). Улучшения необходимы для удобной и полноценной работы в системе (рост лояльности текущих клиентов и сокращение оттока).

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

Для сохранения баланса между крупными блоками и "улучшайзерами" наш продуктовый backlog разделен по типам задач. При этом в каждый релиз мы включаем задачи всех типов: как правило, одну большую и несколько улучшений сделанного ранее. Так, развитие нашей системы службы поддержки идет “по двум направлениям”. Это позволяет повышать удовлетворенность действующих клиентов и привлекать новых, чьи задачи мы ранее мы не могли автоматизировать.

Пожелания клиентов — важный аспект разработки продукта

Обратная связь от пользователей — важный источник ключевых требований к развитию системы службы поддержки. Абсолютно все пожелания фиксируются и анализируются. Именно на их основе в дальнейшем мы принимаем решение о реализации новых возможностей.

Нет сомнений, что feedback от пользователей важен. Однако, здесь есть одно существенно "но". В текущем контексте пользователи бывают принципиально двух типов — платные и не клиенты.

Когда “не клиенты” тестируют систему, они часто дают обратную связь в виде списка требований в стиле: “доработайте это... и тогда я заплачу”. Мы никогда не беремся за реализацию таких "хотелок". Ведь чаще всего подобные пожелания не являются причиной отказа в оформлении подписки на сервис. Причина на самом деле бывает любой: от "нет денег" до "устраивает текущее положение дел". Наша статистика неумолима — процент тех, кто просто не начинает использование любого платного сервиса даже в течение года достаточно высокая. Поэтому, если пользователь говорит “я бы купил, если бы вы сделали…”, мы отвечаем “мы сделаем, если вы купите…”. Когда такой пользователь становится клиентом — с его требованиями мы начинаем работать полноценно. В качестве вывода: настоящую ценность имеют пожелания, тех, кто перешел на этап “Успешная продажа” в воронке продаж. У клиентов нет причины, чтобы искать изъяны или недоделки. Они сообщают о том, что им мешает или чего не хватает в системе в рамках ежедневной работы и бизнес задач.

Требования и пожелания клиентов. Как с этим работать?

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

Разработка облачного решения. Как избежать ошибок?!

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



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

 
Время Uptime за последние
12 месяцев – 99,97
17 тыс
Количество клиентов, которых
поддерживают с помощью Okdesk
 
Активное развитие. Новый
релиз каждые 3-5 недель