Для чего нужна служба технической поддержки
Рекомендации от экспертов. Блог Okdesk
Сложные технические инструменты проникают в жизнь обычных людей и рядового бизнеса. Поддержка — плотно ассоциируется со службой производителя ПО и оборудования или исполнителей проекта (например, разработки и дальнейшего обслуживания сайта), которая помогает пользователям правильно настроить и эксплуатировать сложный продукт, а также быстро устранять возникающие неполадки.
Так ли это? Чем вообще занимается техподдержка? Как она связана с продажами компании? Кому нужно задуматься о ее организации и многое другое в нашей заметке.
Функции техподдержки
Техподдержка — это, фактически, инструмент постпродажного обслуживания, если оно предусмотрено. Пользователи контактируют с ее сотрудниками либо после покупки оборудования или сервиса, либо по завершении проекта — это может быть создание программного решения, сайта или даже внедрение целой инфраструктуры — к примеру, комплексной системы видеонаблюдения.
Задача поддержки — принимать обращения клиентов, у которых возникают проблемы, фиксировать их и решать (в момент обращения или после — в соответствии с Соглашением об уровне сервиса — SLA). Иногда для решения проблемы клиента достаточно ответа на вопрос, а в других случаях требуется передать заявку профильному специалисту, который разберется в проблеме, даст развернутое объяснение и вернет работоспособность решению.
Каким бы ни было обращение, от специалистов поддержки требуется восстанавливать работу обслуживаемой инфраструктуры, ПО или услуги в кратчайшие сроки, для чего используются механизмы управления инцидентами. Формальное определение понятия «как можно быстрее» обеспечивает упомянутое выше соглашение об уровне сервиса — SLA, которое поддержка старается соблюдать или даже превосходить.
Помимо общения с клиентами, поддержка реализует важную функцию получения обратной связи от пользователей (обычно этим занимаются диспетчеры или «первая линия поддержки»), т.е. обеспечивает информацией отдел развития бизнеса — дает предложения по изменению существующих параметров продукта, услуги или проекта, а также по добавлению новых функций и опций. Особенно эта связь важна на рынке B2B, где покупатель решения (отдел закупок) чаще всего не совпадает с его пользователем (рядовые сотрудники).
Техподдержка как инструмент допродаж (upsell)
Качество поддержки влияет не только на повторные продажи, но и на появление новых клиентов. Чужие отзывы о том, что производитель хорошего решения игнорирует запросы пользователей вряд ли пройдут мимо тех, кто еще только интересуется ассортиментом аналогичных продуктов на рынке. И наоборот, решение, чьи клиенты говорят, что все их вопросы решаются буквально «на лету», получает всё большую популярность. Ведь потенциальным покупателям необходимо, чтобы бизнес работал с минимальным количеством сбоев, не влияющих на финансовые показатели.
Таким образом, техническая поддержка — это еще и инструмент повышения лояльности существующих и будущих клиентов.
Раз уж мы говорим о лояльности, то в сегменте поддержки можно выделить клиентскую и техническую. Вторая — обеспечивает решение именно технических проблем («у меня здесь не работает»), первая же работает над выстраиванием долгосрочных взаимоотношений с клиентами с целью повышения совокупного дохода, полученного от одного «контакта». Об их разнице мы уже подробно писали.
Структура поддержки
Для обеспечения лучшего уровня сервиса при сохранении разумных затрат на содержание отдела поддержки внутри него принято выделять несколько линий, разделяя между ними существующие обязанности.
Чаще всего можно выделить:
Часто в дополнительные линии (четвертую, пятую) выделяют представителей разработчиков и сторонних контрагентов, если в продукте или проекте задействованы чужие решения. Однако во многих компаниях ограничиваются лишь двумя линиями, относясь к остальным специалистам, как к партнерам по решению отдельных проблем.
Системы техподдержки
В современном мире поддержка, как и любая другая сфера взаимоотношения с клиентами, требует автоматизации — к этому подталкивает сам рынок и достаточно сложные процессы обслуживания. Клиенты привыкли, что даже в крупных ритейлерах или финансовых организациях их узнают по ID, моментально вспоминая историю взаимоотношений, и не требуют по 10 раз повторять одну и ту же историю. Того же они хотят и от сервиса в области B2B. Для удовлетворения этого клиентского ожидания компании используют программные инструменты — системы автоматизации класса helpdesk.
Системы автоматизации процессов поддержки значительно отличаются друг от друга. При выборе — важно не запутаться. Подробнее о том, как выбрать решение подобного класса читайте в отдельной заметке
Okdesk — удобная и функциональная система автоматизации техподдержки. Сотни компаний ежедневно используют лучшие практики в своей деятельности.
Как построить идеальную службу поддержки: от найма до ответа в чате
К 2020 году компании уже поняли, что им нужна служба поддержки. Довольный клиент = рост прибыли. Но не все смогли построить команду, которая будет человеческим лицом компании и длить сотрудничество с клиентом.
Маркетинг и продажи привлекают клиентов, саппорт — дружит и поддерживает отношения. Служба поддержки — это способ сократить расстояние между компанией и конечным пользователем, а не отдел по борьбе с клиентами. После обращения в поддержку должно стать понятно, спокойно и приятно. Но чаще всего человек получает отписку, шаблонный ответ, долгое ожидание, сложные формулировки.
Идеальная поддержка состоит из двух ингредиентов: личные качества специалиста и четко прописанные правила.
Просто набрать людей у метро и посадить за компьютер не получится.
Соберите базу знаний на основе частых вопросов от пользователей.
В первую неделю сотрудник изучит продукт и посмотрит, как работают другие. Затем можно приставить наставника на пару недель, чтобы помогал с поиском ответов и верными формулировками.
С третьей недели начните разбор обращений, давайте комментарии, разбирайте сложные кейсы. Это позволит быстрее разобраться как в матчасти, так и в тональности коммуникации. В ином случае рискуете погубить классного саппорта из-за отсутствия обратной связи, инструкций и необходимой информации для работы.
Спустя месяц позвольте сотруднику сделать саморазбор. Если саппорт не видит собственных ошибок — это дорога к деревянным ответам и «отпискам».
Начните с основного — частых вопросов пользователей и кейсов. Далее дополняйте по мере появления новых обращений, продуктов, изменений. База должна быть живой и постоянно пополняться. Доверить это можно старшим саппортам или, если команда еще небольшая, руководителю заняться самому. Завести базу знаний лучше на платформе, где будет возможность искать ответ по ключевым словам.
Например, Notion. Он одновременно заменяет множество других популярных софтов для организации работы — Google Docs, Evernote, GitHubWiki, Trello, Jira, Google Sheets и другие. В него можно встроить уже существующие у вас инструменты и интегрировать Slack для отправки обновлений коллегам.
Пропишите регламент — кому передать, где и у кого найти ответ, кто ответственный за каждое направление, в которое может понадобиться обратиться. Это поможет избежать размытых ответов и нерешенных проблем.
Ясные критерии помогут как руководителю, так и сотруднику. Руководитель сможет понять слабые места, чтобы увеличить качество сервиса с помощью обучения сотрудников. Сотрудник сможет видеть свое развитие, что послужит дополнительной мотивацией. Оценка позволит понять, кто не пройдет испытательный срок. Также хорошо сделать KPI, от которых будет зависеть зарплата сотрудников.
Четко определите и пропишите тональность коммуникации. Она едина для компании, но у каждого канала связи с пользователем есть свои особенности.
В соцсетях важно быстро реагировать, особенно на негатив. Главная задача — перевести решение проблемы из публичного поля и передать в поддержку.
При общении на почте терпимым будет ответ до 12 часов. Если человек пишет на почту, скорее всего он готов подождать. Важно сразу отправлять автоматический ответ, что письмо получили и назвать сроки ответа. Но в любом случае — чем быстрее, тем лучше.
Люди проверяют почту в определенное время, поэтому нужно сокращать количество писем в цепочке и не растягивать решение одного вопроса на несколько дней. Сведите к минимуму уточняющие вопросы и сразу давайте ответ для нескольких сценариев. Здесь ответ может быть объемнее, чем в других каналах, и так человек сразу получит решение.
Общение в чате предполагает быстрый ответ, пока пользователь онлайн. Общение может состоять из большого количества коротких сообщений. Ответ должен умещаться в один экран телефона либо окно чата, чтобы клиенту не пришлось скроллить и теряться в полотне ответа. Если же ответ все-таки требует объема, то разбивайте его на несколько сообщений. Это еще и поможет сократить время ответа — пока человек читает первую часть, пишите вторую. Важно предупредить в конце первого сообщения, что вы дополняете ответ, чтобы пользователь оставался на связи и не спешил задавать уточняющие вопросы.
Поддержку по телефону пора оставить в прошлом. Она может понадобиться только в нескольких случаях — срочный вопрос, который невозможно решить в переписке из-за технических проблем на сайте/в чате/в приложении. Для пользователей в преклонном возрасте, которым проще позвонить, чем писать.
Большинство вопросов возможно решить только в переписке, потому что нужно идентифицировать пользователя, разобраться в его вопросе/проблеме. Если это нетипичный случай, то сходить за ответом в другой отдел или передать вопрос специалисту второй линии. Поэтому имеет смысл вшить в скрипт разговора рекомендацию писать сразу в поддержку, чтобы ускорить решение вопроса.
Вводить бота имеет смысл для типичных вопросов, когда вы понимаете, что существенно снизите нагрузку и сократите штат. Здесь уже речь о тысячах обращений в день. Да, в большинстве случаев боты бесят. Но если можно его ввести без потери качества, то почему бы и нет.
Действительно передавайте все пожелания — будь то отзыв о вашем приложении, рассылке или опечатке на сайте. Если десятки человек в день пишут с вопросом, где найти ссылку или как зарегистрироваться, то это повод подумать, как лучше доносить информацию до клиента. Одна добавленная строка в рассылке писем может снизить нагрузку на саппорт и облегчить жизнь пользователям.
Организуйте работу. Если обращения пользователей не может решить только саппорт и это предполагает передачу вопросов в другие отделы, то важно, чтобы информация не терялась по пути. Иначе может получиться так, что саппорт ушел за ответом и не вернулся, потому что пропустил сообщение от коллеги.
Используйте Slack для общения. Он лучше, чем телеграм. Можно поставить напоминание от бота заглянуть в сообщение, сохранить информацию в закладки, ответить в тред, чтобы не вести параллельно несколько обсуждений. Подробнее об этом написали в блоге Нетологии.
Если выявлены баги или проблемы, с которыми не могут справиться сотрудники поддержки, то подумайте об организации задач в таск-менеджерах, типа Jira, Wrike и других.
Важно не ответить, а решить запрос. Многие имитируют службу поддержки. С этой функцией справился бы FAQ на сайте. Крутая поддержка — когда клиент получил точный ответ здесь и сейчас, плюс ему дали полезной информации на будущее, чтобы облегчить пользование продуктом. Плохая поддержка — отправляет пользователя искать ответ самостоятельно стандартной отпиской в дебрях приложения или сайта.
Если человек спрашивает в чате банковского приложения, где поблизости снять наличные, то нужно не просто отправить его смотреть на карту, а дать несколько адресов. При этом рассказать, где в следующий раз найти самостоятельно банкоматы.
Не молчите. Случилось что-то подозрительное — отработайте все типичные варианты похожих кейсов, чтобы отсечь их, и передавайте коллегам. Так проблему можно будет решить задолго до того, как она станет массовой. Не забудьте сообщить об ошибке в общем канале, чтобы все сотрудники поддержки оперативно узнавали и сообщали актуальную информацию пользователям.
Плохой саппорт — отвечает по скрипту и шаблонами. Хороший — проявляет эмпатию и понимает клиента.
OneTwoTrip, здесь хорошим ответом было бы не «уточнение информации», а проявление сочувствия.
«Поддержка», как много в этом слове…
Итак, продолжаю серию статей «из творческого отпуска», на сей раз мы рассмотрим такие «страшные» вещи, как «сопровождение продуктов», «техническая поддержка», «служба поддержки» и т.д.
В данной статье не будут рассматриваться вопросы управления коллективом, развертывания системы администрирования обращений и детали работы начальников отделов поддержки. Статья скорее является своеобразным введением в проблематику «поддержки 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. Автобусный сервис отсюда
Описание обязанностей и требований к специалисту техподдержки
Содержание
Описание и что значит техническая поддержка
Техническая поддержка (technical support) — это служба, в которую пользователи продукта или услуги могут обратиться за оказанием технической поддержки по решению возникшей проблемы, а также за получением дополнительной информации по интересующему вопросу.
Стоит также отметить, что служба технической поддержки может быть организована и для обслуживания сотрудников компании внутри организации, например, если сотрудникам нужна техническая помощь с компьютерной техникой (сломался компьютер/принтер) или неработающим программным обеспечением.
Отдельно можно выделить техническую поддержку клиентов (или клиентская поддержка). Такой вид поддержки имеет стратегическую направленность и нацелен на выстраивание долгосрочных отношений с клиентами.
Насколько легко освоить профессию?
Часто на начальном этапе (первая линия поддержки) работодатели не требуют наличие глубоких технических знаний. Главное, это умение работать с ПК, с технической документацией и специализированным программным обеспечение. Поэтому, очень часто, студенты и начинающие IT специалисты начинают свой карьерный путь именно с работы специалистом технической службы. В последнее время все чаще компании требуют хороший уровень английского языка.
Чтобы начать работать специалистом технической поддержки второго уровня, необходим запас технических знаний (например часто в описаниях вакансий можно встретить требование опыта системного администратора Linux или Windows от года).
Уровень зарплат
Плюсы и минусы работы специалистом технической поддержке
Обязанности и задачи технической поддержки
Навыки и требования к специалисту технической поддержки
Карьерный рост специалиста технической поддержки
Как и практически во всех IT специальностях, градация у Technical support следующая:
— junior (первая линия технической поддержки или technical support level 1)
— middle (вторая линия технической поддержки или technical support level 2)
— senior (третья линия технической поддержки или technical support level 3)
Основное отличие между градациями карьерного роста специалистов техподдержки — сложность решения задач.
Как правило, первый уровень — уровень для молодых и начинающих специалистов, в обязанности которых входит решение совсем простых задач, составление тикетов, ответы по телефону клиентам;
Уровень 2 — на этом уровне работают более опытные специалисты, которые способны решать более менее сложные задачи;
Уровень 3 — здесь работают специалисты с высшей категорией квалификации. В круг их обязанностей входит решение задач, с которыми не справился 2 уровень технической поддержки.
Виды технической поддержки
Техподдержку можно разделить на 3 направления:
Оказание услуг технической поддержки может быть предоставлена как на бесплатной, так и на платной основе. Платная техническая поддержка предоставляется на определенный срок по определенной цене и может включать в себя следующие услуги:
Наиболее часто за оказанием технической поддержки можно обратиться через чат, электронную почту, форму “обратной связи”, телефон, панель управления, и как правило, по рабочим дням.
В случае, обращения пользователя, специалисты из техподдержки обязаны выяснить нюансы проблемы, найти и предложить способы решения этой проблемы, а также дать рекомендации по дальнейшему предотвращению подобной проблемы.
Обработка обращений пользователей и клиентов происходит с помощью программного обеспечения, например, Helpdesk и Salesforce.
Цели технической поддержки
Проблемы технической поддержки
Не смотря на все основные преимущества работы специалистов в службе технической поддержки, существует ряд определенных проблем. К наиболее частым проблемам относятся:
Курсы для специалистов технической поддержки
Онлайн портал Linux Training Center предлагает набор курсов по изучению Linux, прохождение которых поможет людям без опыта и новичкам в IT уже через 1,5-2 месяца обучения устроится на работу в службу технической поддержки. Работающие специалисты технической поддержки могут существенно расширить свое понимание IT мира и прокачать свои знания. Кроме того, изучение Linux на глубоком уровне даст возможность перехода в более разносторонние IT специальности, такие как “системный администратор” или “DevOps инженер”.