Что такое служба поддержки
Как работает служба поддержки онлайн-сервиса
Карина Вильяверде, специалист по работе с клиентами Preply.com, специально для «Нетологии» написала колонку о том, как все устроено в хорошем саппорте, какой должен быть сотрудник, и что делать клиенту, чтобы получить от общения со службой поддержки максимум пользы.
У пользователей любого сервиса всегда возникают вопросы, сомнения или проблемы с использованием продукта — именно этих клиентов крайне легко потерять. Исправить ситуацию и вернуть лояльность пользователя помогает грамотно организованная служба поддержки.
Выбор канала коммуникации
Чтобы организовать службу поддержки, нужно в первую очередь определиться, как вы будете общаться с пользователями. Выбирать есть из чего: электронная почта, телефон, WhatsApp и Viber или отдельное окно чата на сайте. Решение определяется спецификой работы.
Так, оптимальным каналом связи с клиентами может быть уже традиционный чат на сайте, который будет приносить порядка 95% обращений. Не отказывайтесь от телефона — его выбирают пользователи, которые предпочитают привычные, консервативные решения. Но стоит рассмотреть и альтернативные каналы.
Ситуация: службам поддержки не хватает визуальных возможностей — приходится долго объяснять то, что можно было бы показать одной картинкой. С другой стороны, для хорошей работы важно «живое» общение. Получается, при общении по телефону клиенту сложно объяснить, что пошло не так. Он может прислать скриншот по почте, но при этом процесс замедлится и общение станет неживым. Разорвать этот круг можно с помощью нового формата связи. К примеру, видеоконсультация по Skype позволит совместить живой разговор и визуальную демонстрацию проблемы.
Канал общения может быть любым, если это решает конкретные вопросы клиентов.
Признаки хорошего работника саппорта
Важно нанимать в службу поддержки специалистов с эмпатией, которые хотят помогать людям. Да, технические навыки и знания тоже имеют значение, но это второстепенно.
Если сотрудник хочет помогать клиентам, он что угодно выучит, надо только ему помочь: поделиться информацией и опытом. Если же специалисту неинтересно решать чужие проблемы или он не заинтересован в продукте, работа его не радует — тут знания бесполезны. Вы будете постоянно тратить время на искусственную мотивацию, но ничего не изменится.
Если говорить о конкретных навыках, на которые стоит смотреть в резюме, то я советую отталкиваться от того, кто именно необходим проекту и в каких условиях он будет работать. Когда проект международный, то чем больше языков знает сотрудник службы поддержки, тем полезнее он для клиентов. Для другого проекта, возможно, мультиязычность не так значима, зато важны знания различных мобильных платформ или операционных систем.
Всегда учитывайте свою специфику работы.
Распределение нагрузки
Зачастую работники службы поддержки — универсальные солдаты, которые консультируют по любым вопросам. Один и тот же сотрудник может помогать клиенту с регистраций, а через пару минут — решать вопрос с технической ошибкой.
Но с опытом и ростом аудитории приходит понимание: сегментировать работу необходимо.
В случае мультиязычных форматов основное деление происходит по языковому признаку: русский, украинский, английский, испанский, португальский, французский.
В других случаях может использоваться и деление по сферам. Чаще всего оно неофициальное: одним больше нравится решать вопросы, касающиеся финансов или операций на сайте, другие предпочитают проверять профили и верифицировать их. Возможно, для вашего проекта такое функциональное деление будет более продуктивным.
Еще один вариант сегментирования службы поддержки — по группам пользователей. Такое сегментирование может выражаться по-разному: обслуживание «обычных» клиентов или премиум-сегмента, персональные услуги или корпоративные программы, разовые покупки или постоянная подписка.
Но в любом случае, с сегментированием саппорта или без него, существуют «горячие» периоды, когда вся служба поддержки или отдельные ее направления не справляются с потоком обращений. Например, на работу службы поддержки влияет сезонность. Если проект работает в образовательной сфере, летом наблюдается период «затишья», зато осенью — море обращений. В разгар сезона каждую минуту понимаешь, насколько нужны универсальные ответы. Поэтому советую уделить часть времени работе над базой знаний — разделом FAQ — где пользователь сможет самостоятельно найти нужную информацию, инструкцию.
Контроль качества, штрафы и поощрения
Качество работы оцениваем по нескольким KPI. Постоянно отслеживаем скорость ответа и показатель удовлетворенности NPS (Индекс потребительской лояльности). Еще периодически стоит проводить встречи, как внутри команды, так и кросс-функциональные: например, с продуктовой командой или командой разработки. Это помогает в обучении сотрудников и поднимает уровень квалификации каждого.
В некоторых компаниях используют системы штрафов или поощрений. Я к штрафам отношусь скептически. Рекомендую рассчитывать на сознательность и ответственность каждого, а не разрабатывать сложную систему наказаний. Впрочем, можно понять и те компании, которые с помощью штрафов контролируют и регламентируют работу команд. Если в проекте одновременно занято 100 человек и больше — такие методы работают. То есть, категорически отказываться от системы штрафов не обязательно, но не стоит воспринимать ее как главный и единственно возможный способ управления командой.
Если говорить о поощрении, то это отличная идея. Признание заслуг — нужный способ показать, что компания ценит труд каждого.
Конфиденциальность
Часто пользователи спрашивают, насколько конфиденциально общение и все, что происходит внутри сайта. Порой специфика проекта предполагает, что люди будут присылать копии официальных документов. Например, дипломы, чтобы проверить квалификацию преподавателя. Другие сервисы просят паспорта, фото платежных карт и другие важные сведения. Но не все хотят «светить» документы в сети.
Рекомендую не требовать документы, если есть такая возможность: оставьте эту опцию необязательной, на выбор пользователя.
А если уж просите документы, позаботьтесь о безопасности данных. Так, например, если пользователь предоставляет свой диплом, после рассмотрения и подтверждения файл автоматически удаляется в системе. Это позволяет гарантировать, что третьи лица не получат доступа к документам. Советую не хранить конфиденциальные данные клиентов без острой необходимости.
Правила общения со службой поддержки
Напоследок скажу пару слов для тех, кто находится «по ту сторону» — для клиентов. Есть три кита успешного общения с сотрудником службы поддержки.
1. Предоставьте максимально полное описание проблемы/вопроса.
Укажите, что вы хотели сделать, какую функцию для этого применили, что пошло не так. Развернутое изложение проблемы позволит сотруднику службы поддержки сориентироваться, в каких направлениях могли возникнуть ошибки. Он проработает ваш вопрос со всех сторон и даст максимально полезный ответ.
2. Если возможно — сделайте скриншот. Если сразу визуализировать проблему, меньше придется объяснять.
На картинке стоит отметить, что именно вам непонятно, какая опция не работает, какую кнопку вы нажимали. В некоторых случаях проще сделать два-три скриншота и пронумеровать их, чтобы показать динамику ситуации. Это освободит вас от необходимости расписывать длинную историю.
3. Обращайте внимание на время работы службы поддержки — не все службы работают 24/7.
Если вам не отвечают по одному каналу, не стоит сразу же испытывать другой — возможно, сейчас просто нерабочие часы. Чтобы получить ответ как можно быстрее, не дублируйте обращение из чата на почту. Лучше уточните свой запрос, подготовьте скрины, детализируйте проблему. И как только начнется рабочий день, сотрудник получит ваше подробное сообщение и сможет на него эффективно отреагировать. Еще один вариант — воспользоваться базой знаний проекта, чтобы попытаться решить проблему самостоятельно. Обычно это намного проще, чем кажется.
Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.
Рекомендации от экспертов. Блог Okdesk
Сложные технические инструменты проникают в жизнь обычных людей и рядового бизнеса. Поддержка — плотно ассоциируется со службой производителя ПО и оборудования или исполнителей проекта (например, разработки и дальнейшего обслуживания сайта), которая помогает пользователям правильно настроить и эксплуатировать сложный продукт, а также быстро устранять возникающие неполадки.
Так ли это? Чем вообще занимается техподдержка? Как она связана с продажами компании? Кому нужно задуматься о ее организации и многое другое в нашей заметке.
Функции техподдержки
Техподдержка — это, фактически, инструмент постпродажного обслуживания, если оно предусмотрено. Пользователи контактируют с ее сотрудниками либо после покупки оборудования или сервиса, либо по завершении проекта — это может быть создание программного решения, сайта или даже внедрение целой инфраструктуры — к примеру, комплексной системы видеонаблюдения.
Задача поддержки — принимать обращения клиентов, у которых возникают проблемы, фиксировать их и решать (в момент обращения или после — в соответствии с Соглашением об уровне сервиса — SLA). Иногда для решения проблемы клиента достаточно ответа на вопрос, а в других случаях требуется передать заявку профильному специалисту, который разберется в проблеме, даст развернутое объяснение и вернет работоспособность решению.
Каким бы ни было обращение, от специалистов поддержки требуется восстанавливать работу обслуживаемой инфраструктуры, ПО или услуги в кратчайшие сроки, для чего используются механизмы управления инцидентами. Формальное определение понятия «как можно быстрее» обеспечивает упомянутое выше соглашение об уровне сервиса — SLA, которое поддержка старается соблюдать или даже превосходить.
Помимо общения с клиентами, поддержка реализует важную функцию получения обратной связи от пользователей (обычно этим занимаются диспетчеры или «первая линия поддержки»), т.е. обеспечивает информацией отдел развития бизнеса — дает предложения по изменению существующих параметров продукта, услуги или проекта, а также по добавлению новых функций и опций. Особенно эта связь важна на рынке B2B, где покупатель решения (отдел закупок) чаще всего не совпадает с его пользователем (рядовые сотрудники).
Техподдержка как инструмент допродаж (upsell)
Качество поддержки влияет не только на повторные продажи, но и на появление новых клиентов. Чужие отзывы о том, что производитель хорошего решения игнорирует запросы пользователей вряд ли пройдут мимо тех, кто еще только интересуется ассортиментом аналогичных продуктов на рынке. И наоборот, решение, чьи клиенты говорят, что все их вопросы решаются буквально «на лету», получает всё большую популярность. Ведь потенциальным покупателям необходимо, чтобы бизнес работал с минимальным количеством сбоев, не влияющих на финансовые показатели.
Таким образом, техническая поддержка — это еще и инструмент повышения лояльности существующих и будущих клиентов.
Раз уж мы говорим о лояльности, то в сегменте поддержки можно выделить клиентскую и техническую. Вторая — обеспечивает решение именно технических проблем («у меня здесь не работает»), первая же работает над выстраиванием долгосрочных взаимоотношений с клиентами с целью повышения совокупного дохода, полученного от одного «контакта». Об их разнице мы уже подробно писали.
Структура поддержки
Для обеспечения лучшего уровня сервиса при сохранении разумных затрат на содержание отдела поддержки внутри него принято выделять несколько линий, разделяя между ними существующие обязанности.
Чаще всего можно выделить:
Часто в дополнительные линии (четвертую, пятую) выделяют представителей разработчиков и сторонних контрагентов, если в продукте или проекте задействованы чужие решения. Однако во многих компаниях ограничиваются лишь двумя линиями, относясь к остальным специалистам, как к партнерам по решению отдельных проблем.
Системы техподдержки
В современном мире поддержка, как и любая другая сфера взаимоотношения с клиентами, требует автоматизации — к этому подталкивает сам рынок и достаточно сложные процессы обслуживания. Клиенты привыкли, что даже в крупных ритейлерах или финансовых организациях их узнают по ID, моментально вспоминая историю взаимоотношений, и не требуют по 10 раз повторять одну и ту же историю. Того же они хотят и от сервиса в области B2B. Для удовлетворения этого клиентского ожидания компании используют программные инструменты — системы автоматизации класса helpdesk.
Системы автоматизации процессов поддержки значительно отличаются друг от друга. При выборе — важно не запутаться. Подробнее о том, как выбрать решение подобного класса читайте в отдельной заметке
Okdesk — удобная и функциональная система автоматизации техподдержки. Сотни компаний ежедневно используют лучшие практики в своей деятельности.
Служба технической поддержки
Служба технической поддержки или техподдержка (Technical support, Helpdesk, Service desk) — сервисная структура, разрешающая проблемы пользователей с компьютерами (как аппаратным, так и программным обеспечением) и оргтехникой. Важная функциональная составляющая ITIL (библиотека инфраструктуры информационных технологий), позволяющая выявить проблемные участки инфраструктуры ИТ, оценить эффективность работы подразделения ИТ.
Содержание
Методология организации службы технической поддержки
Служба технической поддержки на каждом предприятии может быть построена разнообразными способами (имеется в виду реализации процессов поддержки). Существует несколько моделей службы поддержки, например: централизованная, локальная, виртуальная — с единым телефонным центром и т. д. Служба технической поддержки может быть организована как в целях обслужить внешних клиентов (аутсорсинг обслуживания компьютеров и т. п.), так и внутренних (подразделение ИТ-департамента на крупных предприятиях).
В описании концепции ITIL, построенной на процессном подходе, Service Desk является единственным описанным функциональным подразделением. Это исключение сделано ввиду большой важности подразделения техподдержки при внедрении практическом использовании современных ИТ-подходов и методик.
Правильно организованная техподдержка (Service Desk) всегда начинается с регистрации всех обращений конечных пользователей, служит единой точкой для общения пользователя с ИТ-службой. Наиболее популярные решения по практической организации техподдержки часто строятся на базе Call-center (иногда даже пользователи их отождествляют). Он является начальной точкой контактов конечных пользователей со службой техподдержки и служит источником информации об их фактической удовлетворенности уровнем сервиса, что дополняет информацию о технических параметрах качества обслуживания компании-клиента (внешнего или внутреннего).
На больших предприятиях или в крупных компаниях-аутсорсерах служба технической поддержки часто организована по следующему многоуровневому принципу:
См. также
Примечания
Ни в коем случае не стоит путать операторов CallCenter (диспетчеров) со специалистами первой линии поддержки. Задача первых — простая регистрация обращений. Специалисты же первой линии — дают ответ на простые вопросы пользователей.
«Поддержка», как много в этом слове…
Итак, продолжаю серию статей «из творческого отпуска», на сей раз мы рассмотрим такие «страшные» вещи, как «сопровождение продуктов», «техническая поддержка», «служба поддержки» и т.д.
В данной статье не будут рассматриваться вопросы управления коллективом, развертывания системы администрирования обращений и детали работы начальников отделов поддержки. Статья скорее является своеобразным введением в проблематику «поддержки IT продуктов»
С чего все начинается
что есть служба поддержки и для чего она нужна?
Хотя вопрос звучит просто, но ответ на него дать не так то и просто. И причиной этому является далеко не сложность этой сферы деятельность. Причина в том, что тут присутствует маленькая особенность — «служба поддержки», равно как и «поддержка» вообще, не являются универсальными понятиями. Их значения очень сильно зависят от конкретной ситуации, которую мы рассматриваем. И чтобы это показать, я приведу один, очень схематичный пример.
Допустим, у нас есть компания — производитель автобусов, в которой наличествуют отделы «разработки и производства» и отдел «технического обслуживания», который осуществляет гарантийное обслуживание проданных автобусов. Есть также вторая компания — потребитель, которая купила один из автобусов, чтобы возить своих сотрудников по некому маршруту внутри кампуса/офисного городка. Так вот, в данном конкретном примере мы получаем следующую картину:
Но это хорошо видно на примере с автобусами, но, почему-то, совсем не очевидно в случае IT.
Давайте попробуем разобраться несколько подробнее.
Формально, службы поддержки и сопровождения программных продуктов находятся на стыке направлений ITSM и CRM. И, как это обычно бывает, у нескольких нянек — дитя без присмотра. При этом, с организацией работ администраторов, выдачи и обслуживания IT оборудования – сложностей зачастую не возникает. Получается некий парадокс, вроде бы и там и тут – IT сфера, и там и тут вполне себе грамотные сотрудники и руководители, но в одном случае все в принципе работает вполне себе даже приемлемо, а в другом – как получится. В чем же разница? Почему мы можем обеспечить поддержку оборудования, ОС, вебсервисов, но при этом с поддержкой бизнес-платформ, таких как учетные системы, системы анализа данных, документооборота, управления бизнес-процессов и прочих – зачастую возникают сложности? В чем может быть загвоздка?
Возьмем другой пример, чуть более приближенный к нашей тематике. Итак, у нас есть компания, которая использует некую «стандартную» конфигурацию учетной системы (неважно какой). Поскольку конфигурация стандартная, то компания не имеет в штате разработчиков для внесения исправлений и изменений в используемую систему. Вполне очевидно, что у пользователей возникают разного рода проблемы и вопросы с применением данной системы. Пользователи, это люди несколько далекие от IT («продажники», бухгалтера, начальники и т.д.) и вникать в детали, как оно собственно работает внутри, им нелегко, да и просто некогда.
На этом моменте давайте остановимся чуть подробнее. Итак, у нас это чистая компания – потребитель. То есть сама компания не производит продукт, которым пользуется, а покупает его на стороне. В этом случае, если нет своей «службы поддержки», то конечные пользователи сами пытаются решать возникающие проблемы. В результате теряется много времени, нервов, начинаются чудеса с данными и т.д. В общем, все как всегда.
И руководитель вновь организуемой «службы поддержки», задает себе два главных вопроса:
— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?
С ответами сложностей быть не должно. Данная служба создается, чтобы взять на себя работу с производителем/поставщиком и избавить конечных пользователей от ненужных им технических манипуляций. То есть заказчиком (потребителем) результатов работы «службы поддержки» являются конечные пользователи.
Едем дальше, а как же оценивать работу сотрудников этой службы? Скоростью решения проблемы? Скорее нет, чем да, поскольку они не могут, да и не должны лезть вовнутрь конфигурации или платформы учетной системы. Поэтому немного утрируем, и получается, что их задачи тоже вполне очевидны — удостовериться, что:
Итак, на текущий момент мы, в общем, двигаемся в верном направлении. Примерно об этом нам говорят книжки из ITIL, множество прочитанных статей, да и логика тоже это подтверждает. И на самом деле, тут откровений нет. Но они будут дальше.
Итак, у нашего руководителя все получилось хорошо, все счастливы, и уже компания – производитель этой самой учетной системы, пригласила его/ее наладить их «службу поддержки». И вот тут начинаются чудеса. На новом месте он/она вновь задается теми же самыми вопросами, что и ранее:
— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?
И вот в этом случае, ответы уже будут очень сильно отличаться от того, что мы видели ранее. Итак, мы имеем дело с компанией – производителем. То есть компания имеет штат разработчиков, которые придумывают и воплощают в жизнь свои идеи в некоем продукте, которым пользуются другие компании. И получается, что при отсутствии «службы поддержки», именно разработчики вынуждены отвлекаться от своей основной работы и заниматься пустяковыми (по их мнению) проблемами, в то время, когда «вселенная нуждается в идеальной учетной системе». 
Иными словами, в данном случае, заказчиком услуг «службы поддержки» являются уже не пользователи, а разработчики. И им уже не нужно требовать, чтобы сотрудник отдела что-то там собирал и отдавал им, тут уже необходимо, чтобы эта служба была в состоянии сама решать большинство проблем. Понимаете разницу?
Получается, что при похожем названии, и вроде бы, как одной функции, у отделов совершенно разные требования к их работе. То есть мы имеем два полюса, два чистых и совершенно противоположных подхода к организации работы «службы поддержки». К большему сожалению, эту разницу мало кто видит, а из тех, кто видит, ее часто игнорируют.
Ведь тот же ITIL эту разницу не обозначает и подавляющее большинство интерпретаций основаны именно на подходе для компаний – потребителей. По этой причине я предпочитаю вариант «службы поддержки» для компаний – производителей именовать «техническая поддержка», чтобы отличать от «службы поддержки пользователей», «отдела сопровождения ПО» и прочих «service desk» в компаниях-потребителях.
Резюмируя, мы получаем следующую картину:
Очевидно, что в реальной жизни нам приходится использовать некий компромисс и смешение этих двух противоположностей, но, тем не менее, зная эти «ингредиенты» руководитель уже сможет подготовить свой собственный рецепт, наиболее полно соответствующий условиям конкретной организации, выстроить соответствующие процессы и подготовить SLA, которые будет отвечать интересам всех заинтересованных сторон (включая отдел поддержки/сопровождения).
К чему обычно приходим
Ну и в качестве бонуса, небольшой список неудачных подходов к организации работы службы поддержки.
С другой же стороны, когда к Вам обращается некий «Федор», это далеко не всегда комфортно, поскольку Вы не знаете этого человека, его никто не представлял, чтобы разводить «панибратство» и вообще, как Вы можете быть уверены, что «Федор» это его реальное имя?
Поэтому всегда, при любом ответе компании в подписи должны быть, как минимум, фамилия и имя человека, отправившего сообщение. Даже если данное письмо/сообщение идет от коллектива в целом. Кроме того, если обращение начал обрабатывать один сотрудник, то он и ведет работу по данному конкретному инциденту до конца, без постоянного переключения участников со стороны компании. Смена допускается лишь при необходимости (например, заболел, или перегружен более важными запросами, или же работу «подхватили» сотрудники «технической поддержки») и новый ответственный сотрудник всегда должен представиться и указать будет ли он до конца работать по заявке, или же только временно ее обрабатывает. Вообще, все это очень странно и создается впечатление, что основами административной работы многие менеджеры просто не владеют.
Но чаще всего создание CMDB просто игнорируют, храня информацию в разрозненных файликах, письмах и даже на бумажках. Сложность в том, что критериев выбора конфигурационных/изменяемых параметров не приводится в руководствах ITIL (например, в той же третьей книге «ITIL Service Transition»). Есть только классификация и некие примеры, взятые для случаев администраторской работы. Поэтому от квалификации, опыта и чутья архитектора внедрения ITIL — зависит буквально все.
Надеюсь, это хоть немного пролило свет на то, что «знание ITIL/ITSM» само по себе ничего не гарантирует и требует в первую очередь понимания, что есть поддержка, для чего она нужна в данном конкретном случае и что является признаком успешности ее работы.
Кроме этого, анализ работы служб поддержки позволяют оценить и качество работ внешних поставщиков услуг и/или отдела разработки. Эту часть анализа деятельности зачастую вообще игнорируют.
На этом у меня все. Ваши комментарии и аргументированные замечания – всячески приветствуются.
Всем удачи и успехов.
1. «Мерзлый» песик — отсюда
2. «Суровый» пес отсюда
3. Call-центр: отсюда
4. Автобусный сервис отсюда