Поддержка вашей продукции: как обеспечить техническую поддержку

Дизайн и разработка
28 октября 2011

Является ли ваша продукция файлом с открытым исходным кодом, веб-приложением или доступной для скачивания программой, вам необходимо обеспечить ее техническую поддержку. В статье мы рассматриваем данную тему на основании опыта поддержки продукта нашей компании. Perch — система управления контентом (CMS), которую мы продаем доступной к скачиванию и установке на хостинге. Наша поддержка — главный фактор в успешном продвижении продукта не только из-за того, что клиентам нравится оперативная система поддержки, а потому, что для улучшения продукта мы учитываем пожелания своих пользователей.

Не следует недооценивать важность технической поддержки

В своей статье “You’re Pricing It Wrong: Software Pricing Demystified” в Smashing Magazine Эран Гальперин (Eran Galperin) пишет:
«Коммерческий продукт, поставляемый вместе с технической поддержкой, будет пользоваться большим успехом у потребителей, которым важно знать, что кто-то, если потребуется, сможет помочь им при первой необходимости».

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

Трезво оцените потраченное время

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

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

Способы проведения технической поддержки

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

  • Телефон,
  • Электронная почта,
  • Социальные сети,
  • Система отслеживания ошибок,
  • Чат в реальном времени.

Телефон

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

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

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


Фото: Opensourceway.

Электронная почта

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

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

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

Социальные сети

Техническая поддержка при помощи социальных сетей стала настолько распространенной, что многие большие компании чаще отвечают в Twitter, чем обычным способом. Социальные сети должны стать частью вашей системы поддержки, но они не должны стать единственным способом которым вы можете помочь людям. Очень полезно имея возможность быстро отвечать людям, у которых возникла проблема или появился вопрос о нашем продукте. Мы установили поисковики в наших Twitter клиентах, так что, как только кто-то упоминает Perch, мы можем ответить. Если человек упоминает, что он пользуется демо-версией, мы просто говорим: «Сообщите, если появятся какие-то вопросы!» и все. Важно, чтобы вы не надоедали потенциальным заказчиков; просто дайте им возможность неофициально спросить обо всем, что придет им в голову.

Если у вас есть персонал, ответственный за оказание технической поддержки в Twitter, убедитесь, что он может помочь людям. Многие крупные компании уполномочили персонал технической поддержки Twitter, который может только направлять людей, отвечать на сайте компании, это чаще вредит, чем помогает! Компания КомпT-Mobile в Великобритании отлично осуществляет Twitter поддержку при помощи аккаунта @TmobileUKhelp. Технический персонал компании могут решать большинство проблем, с которыми справляются операторы телефонной службы поддержки как только клиент подтвердил их идентичность с помощью прямого сообщения. Маленькие компании могут предоставлять поддержку с помощью соцсетей на довольно высоком уровне, часто — даже лучше больших компаний. Если заказчики с помощью Twitter дают выход своему разочарованию, то пара быстрых и полезных сообщений может превратить их «Я так недоволен» в «Вау! Отличная техническая поддержка!» Как правило, люди с понимание относятся к проблемам до тех пор, пока им быстро оказывают помощь.

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

Система отслеживания ошибок

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

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

Пример из жизни. Когда два года назад мы запустили Perch как сервисную систему обслуживания, мы использовали размещенную у себя программу Tender. Tender – довольно простая система, которая позволяет пользователям прикреплять как публичные запросы (их видит и на них может ответить любой, не только сотрудник поддержки) или частные (видимые только для службы поддержки).

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

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

Решив, что наш первоначальный выбор программы Tender не совсем то, что нам нужно, мы составили список пунктов, которые мы хотели бы видеть в системе поддержки.

  1. Система с запросами и форумами — все вместе (было бы идеально иметь возможность распечатывать документацию в этой же системе).
  2. Отличная поддержка ответов нескольких пользователей на вопросы.
  3. Система, которая должна поддерживать HTML, примеры кодов отправленные заказчиком и наши ответы.
  4. Статистика, которая позволяет отслеживать запросы и затраченное время, и тому подобное.

Мы начали исследовать и спросили в Twitter: какие системы поддержки нравятся людям. Лидирующую позицию занял Zendesk, и если бы не длительное исследование с форматированием кода, возможно, мы бы пользовались Zendesk. В этом продукте мне очень понравились внедренные социальные сети; однако использовать эту программу помешала проблема фрагментов кода.

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

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

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

Чат в реальном времени

Поддержка, основаная на чате в режиме реального времени, - особенность некоторых тикетных систем, также доступна как отдельный сервис (Olark). Мы пользуемся чатом Perch, но чаще для консультаций перед продажей, чем для реальной поддержки. Было бы хорошо иметь возможность быстро отвечать на вопросы, как в Twitter, но для более длинных ответов и образцов кодов, намного проще иметь дело с живым человеком.

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

Как снизить количество запросов о поддержке и затраченное на них время

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

Создайте заявку на обслуживание отдельно от вашего продукта

Работая с Perch мы стараемся рассматривать запросы о поддержке как признак того, что что-то требует улучшения, пояснения к продукту или сопутствующему справочному материалу. Отслеживая запросы и видя, где появляется изображение, которое показывает, что в определенном месте люди столкнулись с проблемой, мы можем предотвратить ее возникновение или предоставить лучший справочный материал.

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

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

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

Очевидно, что создавая справочные материалы насколько это возможно отдельно от вашего продукта насколько это возможно, приносит нам пользу. Чем меньше поддержки нам приходится оказывать по лицензии, тем более рентабелен наш продукт. А еще это производит на наших заказчиков лучшее впечатление. Запутаться и просить о помощи даже не зарегистрировавшись в системе – не самое хорошее первое впечатление.

Включите в продукт систему устранения ошибок или диагностическую информацию.

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

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

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

Если много пользователей, которые запрашивают помощь, просят рассказать как следать что-то, что ваша программа не выполняет, стоит подумать о возможности добавить эту функцию. В то время как у вас может быть четкое представление о том, что ваша пограмма делает, а что нет, вы должны немного приспособиться. В нашем случае Perch – "действительно маленькая CMS",созданная для небольших сайтов. Когда мы ее запускали, мы думали, что пользователям не понадобятся такие функции как отмена операций, создание и редактирование чертежей, или предпросмотр. Однако вскоре мы поняли что нашим пользователям эти функции необходимы, поэтому мы придумали как их добавить, не увеличивая систему. Используйте просьбы о поддержке в создании справочника. Как только мы понимаем, что кто-то спрашивает о том, что Perch не выполняет, мы спрашиваем: "как вы представляете раоту этой функции?"

Обеспечьте разнообразный справочный материал

Люди учатся пользоваться приложениями по-разному. Мне нравится читать документацию и эксперементировать с кодом. Для многих людей – особенно визуалов – больше помогает наглядная демонстрация.

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

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

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

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


Изображение предоставлено : Opensourceway.

Как постепенно сократить предоставляемую поддержку для старых версий программы

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

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

Обновления для систем безопасности часто оставляют доступными после этой даты, на случай, если в старой версии продукта обнаружатся недостатки, но не вносятся никакие изменения. Например, базовая поддержка Майкрософт для Windows XP Professional завершилась в 2009 году, однако расширенная поддержка (в которую входят обновления для систем безопасности) будет длиться до 2014 года.

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

И в заключение

Вопрос, который нам часто задавали о Perch "дейтвительно ли поддержка – єто кошмар?" Для разработчиков программного обеспечения слишком просто рассматривать поддержку как необходимое зло, часть работы, которую нужно закончить как можно быстрее или даже ппередать кому-то другому. Если вы именно так обспечиваете поддержку, вы упускаете возможность по-настоящему вместе с пользователями улучшить продукт. Вы также проходите мимо усовершенствований, которые могли бы сделать, прислушиваясь к запросам пользователей.

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

Оригинал статьи: Rachel Andrew (www.smashingmagazine.com)
Похожие статьи
Комментарии (0)