что такое служба поддержки пользователей
Рекомендации от экспертов. Блог Okdesk
Сложные технические инструменты проникают в жизнь обычных людей и рядового бизнеса. Поддержка — плотно ассоциируется со службой производителя ПО и оборудования или исполнителей проекта (например, разработки и дальнейшего обслуживания сайта), которая помогает пользователям правильно настроить и эксплуатировать сложный продукт, а также быстро устранять возникающие неполадки.
Так ли это? Чем вообще занимается техподдержка? Как она связана с продажами компании? Кому нужно задуматься о ее организации и многое другое в нашей заметке.
Функции техподдержки
Техподдержка — это, фактически, инструмент постпродажного обслуживания, если оно предусмотрено. Пользователи контактируют с ее сотрудниками либо после покупки оборудования или сервиса, либо по завершении проекта — это может быть создание программного решения, сайта или даже внедрение целой инфраструктуры — к примеру, комплексной системы видеонаблюдения.
Задача поддержки — принимать обращения клиентов, у которых возникают проблемы, фиксировать их и решать (в момент обращения или после — в соответствии с Соглашением об уровне сервиса — SLA). Иногда для решения проблемы клиента достаточно ответа на вопрос, а в других случаях требуется передать заявку профильному специалисту, который разберется в проблеме, даст развернутое объяснение и вернет работоспособность решению.
Каким бы ни было обращение, от специалистов поддержки требуется восстанавливать работу обслуживаемой инфраструктуры, ПО или услуги в кратчайшие сроки, для чего используются механизмы управления инцидентами. Формальное определение понятия «как можно быстрее» обеспечивает упомянутое выше соглашение об уровне сервиса — SLA, которое поддержка старается соблюдать или даже превосходить.
Помимо общения с клиентами, поддержка реализует важную функцию получения обратной связи от пользователей (обычно этим занимаются диспетчеры или «первая линия поддержки»), т.е. обеспечивает информацией отдел развития бизнеса — дает предложения по изменению существующих параметров продукта, услуги или проекта, а также по добавлению новых функций и опций. Особенно эта связь важна на рынке B2B, где покупатель решения (отдел закупок) чаще всего не совпадает с его пользователем (рядовые сотрудники).
Техподдержка как инструмент допродаж (upsell)
Качество поддержки влияет не только на повторные продажи, но и на появление новых клиентов. Чужие отзывы о том, что производитель хорошего решения игнорирует запросы пользователей вряд ли пройдут мимо тех, кто еще только интересуется ассортиментом аналогичных продуктов на рынке. И наоборот, решение, чьи клиенты говорят, что все их вопросы решаются буквально «на лету», получает всё большую популярность. Ведь потенциальным покупателям необходимо, чтобы бизнес работал с минимальным количеством сбоев, не влияющих на финансовые показатели.
Таким образом, техническая поддержка — это еще и инструмент повышения лояльности существующих и будущих клиентов.
Раз уж мы говорим о лояльности, то в сегменте поддержки можно выделить клиентскую и техническую. Вторая — обеспечивает решение именно технических проблем («у меня здесь не работает»), первая же работает над выстраиванием долгосрочных взаимоотношений с клиентами с целью повышения совокупного дохода, полученного от одного «контакта». Об их разнице мы уже подробно писали.
Структура поддержки
Для обеспечения лучшего уровня сервиса при сохранении разумных затрат на содержание отдела поддержки внутри него принято выделять несколько линий, разделяя между ними существующие обязанности.
Чаще всего можно выделить:
Часто в дополнительные линии (четвертую, пятую) выделяют представителей разработчиков и сторонних контрагентов, если в продукте или проекте задействованы чужие решения. Однако во многих компаниях ограничиваются лишь двумя линиями, относясь к остальным специалистам, как к партнерам по решению отдельных проблем.
Системы техподдержки
В современном мире поддержка, как и любая другая сфера взаимоотношения с клиентами, требует автоматизации — к этому подталкивает сам рынок и достаточно сложные процессы обслуживания. Клиенты привыкли, что даже в крупных ритейлерах или финансовых организациях их узнают по ID, моментально вспоминая историю взаимоотношений, и не требуют по 10 раз повторять одну и ту же историю. Того же они хотят и от сервиса в области B2B. Для удовлетворения этого клиентского ожидания компании используют программные инструменты — системы автоматизации класса helpdesk.
Системы автоматизации процессов поддержки значительно отличаются друг от друга. При выборе — важно не запутаться. Подробнее о том, как выбрать решение подобного класса читайте в отдельной заметке
Okdesk — удобная и функциональная система автоматизации техподдержки. Сотни компаний ежедневно используют лучшие практики в своей деятельности.
Как работает служба поддержки онлайн-сервиса
Карина Вильяверде, специалист по работе с клиентами Preply.com, специально для «Нетологии» написала колонку о том, как все устроено в хорошем саппорте, какой должен быть сотрудник, и что делать клиенту, чтобы получить от общения со службой поддержки максимум пользы.
У пользователей любого сервиса всегда возникают вопросы, сомнения или проблемы с использованием продукта — именно этих клиентов крайне легко потерять. Исправить ситуацию и вернуть лояльность пользователя помогает грамотно организованная служба поддержки.
Выбор канала коммуникации
Чтобы организовать службу поддержки, нужно в первую очередь определиться, как вы будете общаться с пользователями. Выбирать есть из чего: электронная почта, телефон, WhatsApp и Viber или отдельное окно чата на сайте. Решение определяется спецификой работы.
Так, оптимальным каналом связи с клиентами может быть уже традиционный чат на сайте, который будет приносить порядка 95% обращений. Не отказывайтесь от телефона — его выбирают пользователи, которые предпочитают привычные, консервативные решения. Но стоит рассмотреть и альтернативные каналы.
Ситуация: службам поддержки не хватает визуальных возможностей — приходится долго объяснять то, что можно было бы показать одной картинкой. С другой стороны, для хорошей работы важно «живое» общение. Получается, при общении по телефону клиенту сложно объяснить, что пошло не так. Он может прислать скриншот по почте, но при этом процесс замедлится и общение станет неживым. Разорвать этот круг можно с помощью нового формата связи. К примеру, видеоконсультация по Skype позволит совместить живой разговор и визуальную демонстрацию проблемы.
Канал общения может быть любым, если это решает конкретные вопросы клиентов.
Признаки хорошего работника саппорта
Важно нанимать в службу поддержки специалистов с эмпатией, которые хотят помогать людям. Да, технические навыки и знания тоже имеют значение, но это второстепенно.
Если сотрудник хочет помогать клиентам, он что угодно выучит, надо только ему помочь: поделиться информацией и опытом. Если же специалисту неинтересно решать чужие проблемы или он не заинтересован в продукте, работа его не радует — тут знания бесполезны. Вы будете постоянно тратить время на искусственную мотивацию, но ничего не изменится.
Если говорить о конкретных навыках, на которые стоит смотреть в резюме, то я советую отталкиваться от того, кто именно необходим проекту и в каких условиях он будет работать. Когда проект международный, то чем больше языков знает сотрудник службы поддержки, тем полезнее он для клиентов. Для другого проекта, возможно, мультиязычность не так значима, зато важны знания различных мобильных платформ или операционных систем.
Всегда учитывайте свою специфику работы.
Распределение нагрузки
Зачастую работники службы поддержки — универсальные солдаты, которые консультируют по любым вопросам. Один и тот же сотрудник может помогать клиенту с регистраций, а через пару минут — решать вопрос с технической ошибкой.
Но с опытом и ростом аудитории приходит понимание: сегментировать работу необходимо.
В случае мультиязычных форматов основное деление происходит по языковому признаку: русский, украинский, английский, испанский, португальский, французский.
В других случаях может использоваться и деление по сферам. Чаще всего оно неофициальное: одним больше нравится решать вопросы, касающиеся финансов или операций на сайте, другие предпочитают проверять профили и верифицировать их. Возможно, для вашего проекта такое функциональное деление будет более продуктивным.
Еще один вариант сегментирования службы поддержки — по группам пользователей. Такое сегментирование может выражаться по-разному: обслуживание «обычных» клиентов или премиум-сегмента, персональные услуги или корпоративные программы, разовые покупки или постоянная подписка.
Но в любом случае, с сегментированием саппорта или без него, существуют «горячие» периоды, когда вся служба поддержки или отдельные ее направления не справляются с потоком обращений. Например, на работу службы поддержки влияет сезонность. Если проект работает в образовательной сфере, летом наблюдается период «затишья», зато осенью — море обращений. В разгар сезона каждую минуту понимаешь, насколько нужны универсальные ответы. Поэтому советую уделить часть времени работе над базой знаний — разделом FAQ — где пользователь сможет самостоятельно найти нужную информацию, инструкцию.
Контроль качества, штрафы и поощрения
Качество работы оцениваем по нескольким KPI. Постоянно отслеживаем скорость ответа и показатель удовлетворенности NPS (Индекс потребительской лояльности). Еще периодически стоит проводить встречи, как внутри команды, так и кросс-функциональные: например, с продуктовой командой или командой разработки. Это помогает в обучении сотрудников и поднимает уровень квалификации каждого.
В некоторых компаниях используют системы штрафов или поощрений. Я к штрафам отношусь скептически. Рекомендую рассчитывать на сознательность и ответственность каждого, а не разрабатывать сложную систему наказаний. Впрочем, можно понять и те компании, которые с помощью штрафов контролируют и регламентируют работу команд. Если в проекте одновременно занято 100 человек и больше — такие методы работают. То есть, категорически отказываться от системы штрафов не обязательно, но не стоит воспринимать ее как главный и единственно возможный способ управления командой.
Если говорить о поощрении, то это отличная идея. Признание заслуг — нужный способ показать, что компания ценит труд каждого.
Конфиденциальность
Часто пользователи спрашивают, насколько конфиденциально общение и все, что происходит внутри сайта. Порой специфика проекта предполагает, что люди будут присылать копии официальных документов. Например, дипломы, чтобы проверить квалификацию преподавателя. Другие сервисы просят паспорта, фото платежных карт и другие важные сведения. Но не все хотят «светить» документы в сети.
Рекомендую не требовать документы, если есть такая возможность: оставьте эту опцию необязательной, на выбор пользователя.
А если уж просите документы, позаботьтесь о безопасности данных. Так, например, если пользователь предоставляет свой диплом, после рассмотрения и подтверждения файл автоматически удаляется в системе. Это позволяет гарантировать, что третьи лица не получат доступа к документам. Советую не хранить конфиденциальные данные клиентов без острой необходимости.
Правила общения со службой поддержки
Напоследок скажу пару слов для тех, кто находится «по ту сторону» — для клиентов. Есть три кита успешного общения с сотрудником службы поддержки.
1. Предоставьте максимально полное описание проблемы/вопроса.
Укажите, что вы хотели сделать, какую функцию для этого применили, что пошло не так. Развернутое изложение проблемы позволит сотруднику службы поддержки сориентироваться, в каких направлениях могли возникнуть ошибки. Он проработает ваш вопрос со всех сторон и даст максимально полезный ответ.
2. Если возможно — сделайте скриншот. Если сразу визуализировать проблему, меньше придется объяснять.
На картинке стоит отметить, что именно вам непонятно, какая опция не работает, какую кнопку вы нажимали. В некоторых случаях проще сделать два-три скриншота и пронумеровать их, чтобы показать динамику ситуации. Это освободит вас от необходимости расписывать длинную историю.
3. Обращайте внимание на время работы службы поддержки — не все службы работают 24/7.
Если вам не отвечают по одному каналу, не стоит сразу же испытывать другой — возможно, сейчас просто нерабочие часы. Чтобы получить ответ как можно быстрее, не дублируйте обращение из чата на почту. Лучше уточните свой запрос, подготовьте скрины, детализируйте проблему. И как только начнется рабочий день, сотрудник получит ваше подробное сообщение и сможет на него эффективно отреагировать. Еще один вариант — воспользоваться базой знаний проекта, чтобы попытаться решить проблему самостоятельно. Обычно это намного проще, чем кажется.
Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.
«Поддержка», как много в этом слове…
Итак, продолжаю серию статей «из творческого отпуска», на сей раз мы рассмотрим такие «страшные» вещи, как «сопровождение продуктов», «техническая поддержка», «служба поддержки» и т.д.
В данной статье не будут рассматриваться вопросы управления коллективом, развертывания системы администрирования обращений и детали работы начальников отделов поддержки. Статья скорее является своеобразным введением в проблематику «поддержки 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. Автобусный сервис отсюда
Саппорт IT-продукта, часть 1: чаты, роли сотрудников, боты и отношения с разработкой
Даже идеальному продукту пользователи могут вкатить «кол», если у него нет качественного саппорта. Разбираемся, что лучше — телефон или умные боты.
Кирилл Молоков
В поддержке — более трёх лет. Саппортил несколько IT-стартапов и медиасервисы «Яндекса» на первой и второй линиях. На момент публикации — руководитель поддержки GoLogin.
Консалтинговые компании и топ-менеджеры наперебой рассказывают, насколько важен классный саппорт. Однако на практике организация качественной поддержки нередко оказывается где-то в самом конце бэклога — это также подтверждают средние зарплаты по отрасли и очень низкие требования к скиллам в вакансиях.
И вроде бы это логично: в приоритете явно будут разработка, менеджмент, дизайн и тот же маркетинг — ведь чтобы саппортить продукт, его нужно создать и запустить продажи. Но именно сотрудники службы поддержки напрямую общаются с клиентами, повышают их лояльность и укрепляют репутацию компании, гася негатив.
А лояльность бизнесу очень даже выгодна: 5% клиентов, которых удалось удержать, легко могут увеличить доходы на 25% (отчёт Bain & Company). При этом клиентская база, лояльная к бренду, обходится дешевле, чем привлечение новой аудитории.
Казалось бы: просто возьми и запили нормальный саппорт. Однако опыт взаимодействия пользователей с компаниями удручает: толковых служб поддержки практически нет, а 79% людей считают, что их пожелания и жалобы просто игнорятся (исследование Harris Interactive).
Плохой саппорт может испортить репутацию компании, снизить доверие, оттолкнуть клиентов, разрушить стартап и даже известную компанию с длинной историей.
Я несколько лет проработал в техподдержке и расскажу, что лучше — голосовая линия или умные боты, как подружить саппорт и разработку и по какому принципу удобно делить роли сотрудников в общении с клиентами.
Кол-центры vs онлайн-чаты: испортился ли телефон?
В TikTok-мемах о зумерах и миллениалах, которые готовятся к телефонному звонку с друзьями так же долго и со страхом, как и к собеседованию, есть доля правды: поколения Y и Z действительно не любят общаться с компаниями по телефону.
В пользу письменного общения с клиентами говорит и свежий отчёт Comm100: 82% респондентов нравится общаться с саппортом через онлайн-чаты. А вот удовлетворённость телефонными звонками почти в 2 раза ниже — всего 44%.
У телефонной или голосовой службы поддержки есть пара неоспоримых преимуществ: голосом проще решить сложную проблему, а сам факт общения с живым человеком как бы говорит: «Да, мы вас ценим и занимаемся проблемой — честное пионерское!» Ну и, конечно, старая гвардия предпочитает телефон чатам и другим бесовским способам пообщаться с компанией 🙂
Однако по другим параметрам онлайн-чаты уделывают звонки. Вот их основные плюсы:
Кстати, онлайн-чаты упрощают работу и самого саппорта:
И конечно, онлайн-чаты дают фору имейл-поддержке: скорость ответов по электронной почте настолько низкая, что в какой-то момент пользователь просто перестаёт вам писать.
Социальные сети тоже теряют актуальность, а вот мессенджеры запросто могут стать «новым чёрным» в саппорте — особенно для e-commerce. При этом операторам поддержки нет нужды переключаться между Telegram и WhatsApp — все мессенджеры можно объединять и контролировать в хелпдесках вроде Zendesk, Chat2Desk, Paldesk.
Выводы:
Я, робот: нужны ли умные чат-боты
В 2021 году продвинутые чат-боты справляются с некоторыми задачами быстрее и эффективнее людей: моментальные ответы, поддержка в режиме 24/7, экономичность и максимальная «стрессоустойчивость». Чат-боты уже способны решить 66% клиентских запросов, однако у них есть ряд недостатков, из-за которых пользователи до сих пор предпочитают общаться с живым оператором.
И всё же чат-боты — это отличное решение, когда речь идёт о рутинных задачах. Их стоит попробовать хотя бы для самых частых и простых вопросов — например, уточнения тарифов, набора функций или настроек аккаунта. Но более сложные кейсы, в которых нужны эмпатия и критическое мышление, лучше оставить людям.
Кстати, будьте осторожны с настройкой чат-бота, если не хотите, чтобы из его ответов понаделали мемов о тупом ИИ. Например, у ВТБ отличный робот-помощник, и они даже попытались сделать его «эмоциональным». Только эмоциональность эта оказалась какой-то неуместной и неловкой: я несколько дней не мог решить проблему, использовал многоточия, а робот ничего не мог понять, не помогал, но сыпал смайликами 🙂
Выводы:
No pasaran: линии и роли сотрудников в саппорте
«Сейчас я переключу вас на специалиста техотдела…» — фраза, которая порой заставляет нас охать, ахать, закатывать глаза и вообще испытывать самые странные эмоции. Если вы думали, что ваш саппорт «уж точно таким не будет!», то у меня для вас неприятные новости.
Обязанности саппорта распределяются между разными специалистами не ради фрустрации клиентов. Невозможно взвалить все задачи на одного сотрудника — снижается его эффективность, а в случае ухода такого работника, служба поддержки может встать на несколько дней.
Надо также понимать, что большинство саппортеров не умеют писать код. А если бы умели, то стали бы разработчиками. В свою очередь, программисты тоже не могут постоянно мониторить чаты и тем более общаться с клиентами голосом — да и далеко не все пользователи обращаются с техническими проблемами. Поэтому посадить на саппорт, например, крутого питониста — чтобы решал проблемы людей в свободное время — так себе решение.
В общем, лучше всего выстраивать саппорт так, чтобы задачи были распределены между несколькими сотрудниками — в зависимости от сложности и характера проблем. Такая организация называется многоуровневой и подразумевает несколько линий службы поддержки.
Это условная структура: например, многие саппортеры работают сразу на первой и второй линиях, а четвёртая больше относится к задачам менеджеров. Тем не менее чёткая структура помогает лучше отслеживать проблемы пользователей и не тратить лишние ресурсы на кейсы, которые легко решаются на первых линиях. Однако не стоит увлекаться и слишком сильно бюрократизировать весь этот процесс — такая тактика снизит эффективность саппорта, раздует его структуру и встанет «в копеечку».
Вывод:
Саппорт обязательно нужно структурировать. Лучше всего организовывать работу по линиям, фильтруя рядовые кейсы на первых уровнях. Но делать это надо без фанатизма — 10 линий превратят поддержку в бюрократический хаос.
Идите-ка вы в щи: как подружить разработчиков и саппорт
Если верить опросам Rollbar, то 38% разработчиков тратят четверть своего рабочего времени на баг-фиксы. А 26% и вовсе признались, что рутина съедает до 50% их времени.
Причём здесь саппортеры? Поддержка способна приносить баг-репорты для неочевидных сценариев, которые команда разработчиков не может учесть на этапе тестирования. Представьте, что вы разрабатываете приложение для macOS, Windows и Linux. Пять человек пожаловались, что приложение вылетает при нажатии кнопки «Go». Саппортер уже заранее уточнил все детали: ОС, версию приложения, при каких обстоятельствах проявилась ошибка. И теперь, вместо того чтобы пытаться отловить баг сразу на всех операционках, разработчик сразу сядет за Windows и будет разбираться, почему свежая версия крашится при включении VPN.
Я не раз замечал, что этот момент особенно плохо организован в стартапах. На саппорте сидят люди, которые плохо разбираются даже в основах продукта. При этом на их просьбы о помощи айтишники часто задирают нос и объясняют технические вещи самыми непонятными словами.
В итоге саппортеры так и не могут разобраться в проблеме и помочь клиентам, теряют мотивацию, становятся пассивными, а команда разработчиков продолжает пилить какие-то хардкорные фичи, которые непонятны даже продвинутым пользователям. Кто от этого выигрывает? Конкуренты.
Поддержка — как прозрачная среда между пользователем и разработчиками, которая помогает улучшить UX продукта, а организация правильного взаимодействия между саппортом и отделом разработки должна стать одной из приоритетных задач менеджмента.
Даже если саппортер задаёт глупый вопрос, разработчику не стоит закатывать глаза, ведь вопрос саппортера — это почти всегда вопрос клиента. Чем лучше программист вникает в «тупые» вопросы пользователей и объясняет технические аспекты службе поддержки, тем больше прокачиваются его софты. А чем лучше прокачиваются софты, тем более «дружелюбным» для пользователя становится программный продукт.
Да, можно упростить задачу и нанять саппортера-инженера, который способен общаться с технарями на одном языке. Однако для начинающих компаний такой наём вряд ли окажется финансово выгодным — реальных технических проблем у стартапов не так много, а платить квалифицированному сотруднику придётся в несколько раз больше.
Вывод:
Взаимодействие саппорта и разработчиков — это мост, на котором стоит пользователь. А отношения между ними влияют не только на климат в коллективе, но и на качество всего продукта.
Резюмируем
Программное обеспечение для оптимизации работы службы поддержки пользователей.