для чего нужна техподдержка пользователей
«Поддержка», как много в этом слове…
Итак, продолжаю серию статей «из творческого отпуска», на сей раз мы рассмотрим такие «страшные» вещи, как «сопровождение продуктов», «техническая поддержка», «служба поддержки» и т.д.
В данной статье не будут рассматриваться вопросы управления коллективом, развертывания системы администрирования обращений и детали работы начальников отделов поддержки. Статья скорее является своеобразным введением в проблематику «поддержки 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. Автобусный сервис отсюда
Как построить идеальную службу поддержки: от найма до ответа в чате
К 2020 году компании уже поняли, что им нужна служба поддержки. Довольный клиент = рост прибыли. Но не все смогли построить команду, которая будет человеческим лицом компании и длить сотрудничество с клиентом.
Маркетинг и продажи привлекают клиентов, саппорт — дружит и поддерживает отношения. Служба поддержки — это способ сократить расстояние между компанией и конечным пользователем, а не отдел по борьбе с клиентами. После обращения в поддержку должно стать понятно, спокойно и приятно. Но чаще всего человек получает отписку, шаблонный ответ, долгое ожидание, сложные формулировки.
Идеальная поддержка состоит из двух ингредиентов: личные качества специалиста и четко прописанные правила.
Просто набрать людей у метро и посадить за компьютер не получится.
Соберите базу знаний на основе частых вопросов от пользователей.
В первую неделю сотрудник изучит продукт и посмотрит, как работают другие. Затем можно приставить наставника на пару недель, чтобы помогал с поиском ответов и верными формулировками.
С третьей недели начните разбор обращений, давайте комментарии, разбирайте сложные кейсы. Это позволит быстрее разобраться как в матчасти, так и в тональности коммуникации. В ином случае рискуете погубить классного саппорта из-за отсутствия обратной связи, инструкций и необходимой информации для работы.
Спустя месяц позвольте сотруднику сделать саморазбор. Если саппорт не видит собственных ошибок — это дорога к деревянным ответам и «отпискам».
Начните с основного — частых вопросов пользователей и кейсов. Далее дополняйте по мере появления новых обращений, продуктов, изменений. База должна быть живой и постоянно пополняться. Доверить это можно старшим саппортам или, если команда еще небольшая, руководителю заняться самому. Завести базу знаний лучше на платформе, где будет возможность искать ответ по ключевым словам.
Например, Notion. Он одновременно заменяет множество других популярных софтов для организации работы — Google Docs, Evernote, GitHubWiki, Trello, Jira, Google Sheets и другие. В него можно встроить уже существующие у вас инструменты и интегрировать Slack для отправки обновлений коллегам.
Пропишите регламент — кому передать, где и у кого найти ответ, кто ответственный за каждое направление, в которое может понадобиться обратиться. Это поможет избежать размытых ответов и нерешенных проблем.
Ясные критерии помогут как руководителю, так и сотруднику. Руководитель сможет понять слабые места, чтобы увеличить качество сервиса с помощью обучения сотрудников. Сотрудник сможет видеть свое развитие, что послужит дополнительной мотивацией. Оценка позволит понять, кто не пройдет испытательный срок. Также хорошо сделать KPI, от которых будет зависеть зарплата сотрудников.
Четко определите и пропишите тональность коммуникации. Она едина для компании, но у каждого канала связи с пользователем есть свои особенности.
В соцсетях важно быстро реагировать, особенно на негатив. Главная задача — перевести решение проблемы из публичного поля и передать в поддержку.
При общении на почте терпимым будет ответ до 12 часов. Если человек пишет на почту, скорее всего он готов подождать. Важно сразу отправлять автоматический ответ, что письмо получили и назвать сроки ответа. Но в любом случае — чем быстрее, тем лучше.
Люди проверяют почту в определенное время, поэтому нужно сокращать количество писем в цепочке и не растягивать решение одного вопроса на несколько дней. Сведите к минимуму уточняющие вопросы и сразу давайте ответ для нескольких сценариев. Здесь ответ может быть объемнее, чем в других каналах, и так человек сразу получит решение.
Общение в чате предполагает быстрый ответ, пока пользователь онлайн. Общение может состоять из большого количества коротких сообщений. Ответ должен умещаться в один экран телефона либо окно чата, чтобы клиенту не пришлось скроллить и теряться в полотне ответа. Если же ответ все-таки требует объема, то разбивайте его на несколько сообщений. Это еще и поможет сократить время ответа — пока человек читает первую часть, пишите вторую. Важно предупредить в конце первого сообщения, что вы дополняете ответ, чтобы пользователь оставался на связи и не спешил задавать уточняющие вопросы.
Поддержку по телефону пора оставить в прошлом. Она может понадобиться только в нескольких случаях — срочный вопрос, который невозможно решить в переписке из-за технических проблем на сайте/в чате/в приложении. Для пользователей в преклонном возрасте, которым проще позвонить, чем писать.
Большинство вопросов возможно решить только в переписке, потому что нужно идентифицировать пользователя, разобраться в его вопросе/проблеме. Если это нетипичный случай, то сходить за ответом в другой отдел или передать вопрос специалисту второй линии. Поэтому имеет смысл вшить в скрипт разговора рекомендацию писать сразу в поддержку, чтобы ускорить решение вопроса.
Вводить бота имеет смысл для типичных вопросов, когда вы понимаете, что существенно снизите нагрузку и сократите штат. Здесь уже речь о тысячах обращений в день. Да, в большинстве случаев боты бесят. Но если можно его ввести без потери качества, то почему бы и нет.
Действительно передавайте все пожелания — будь то отзыв о вашем приложении, рассылке или опечатке на сайте. Если десятки человек в день пишут с вопросом, где найти ссылку или как зарегистрироваться, то это повод подумать, как лучше доносить информацию до клиента. Одна добавленная строка в рассылке писем может снизить нагрузку на саппорт и облегчить жизнь пользователям.
Организуйте работу. Если обращения пользователей не может решить только саппорт и это предполагает передачу вопросов в другие отделы, то важно, чтобы информация не терялась по пути. Иначе может получиться так, что саппорт ушел за ответом и не вернулся, потому что пропустил сообщение от коллеги.
Используйте Slack для общения. Он лучше, чем телеграм. Можно поставить напоминание от бота заглянуть в сообщение, сохранить информацию в закладки, ответить в тред, чтобы не вести параллельно несколько обсуждений. Подробнее об этом написали в блоге Нетологии.
Если выявлены баги или проблемы, с которыми не могут справиться сотрудники поддержки, то подумайте об организации задач в таск-менеджерах, типа Jira, Wrike и других.
Важно не ответить, а решить запрос. Многие имитируют службу поддержки. С этой функцией справился бы FAQ на сайте. Крутая поддержка — когда клиент получил точный ответ здесь и сейчас, плюс ему дали полезной информации на будущее, чтобы облегчить пользование продуктом. Плохая поддержка — отправляет пользователя искать ответ самостоятельно стандартной отпиской в дебрях приложения или сайта.
Если человек спрашивает в чате банковского приложения, где поблизости снять наличные, то нужно не просто отправить его смотреть на карту, а дать несколько адресов. При этом рассказать, где в следующий раз найти самостоятельно банкоматы.
Не молчите. Случилось что-то подозрительное — отработайте все типичные варианты похожих кейсов, чтобы отсечь их, и передавайте коллегам. Так проблему можно будет решить задолго до того, как она станет массовой. Не забудьте сообщить об ошибке в общем канале, чтобы все сотрудники поддержки оперативно узнавали и сообщали актуальную информацию пользователям.
Плохой саппорт — отвечает по скрипту и шаблонами. Хороший — проявляет эмпатию и понимает клиента.
OneTwoTrip, здесь хорошим ответом было бы не «уточнение информации», а проявление сочувствия.
Рекомендации от экспертов. Блог Okdesk
Сложные технические инструменты проникают в жизнь обычных людей и рядового бизнеса. Поддержка — плотно ассоциируется со службой производителя ПО и оборудования или исполнителей проекта (например, разработки и дальнейшего обслуживания сайта), которая помогает пользователям правильно настроить и эксплуатировать сложный продукт, а также быстро устранять возникающие неполадки.
Так ли это? Чем вообще занимается техподдержка? Как она связана с продажами компании? Кому нужно задуматься о ее организации и многое другое в нашей заметке.
Функции техподдержки
Техподдержка — это, фактически, инструмент постпродажного обслуживания, если оно предусмотрено. Пользователи контактируют с ее сотрудниками либо после покупки оборудования или сервиса, либо по завершении проекта — это может быть создание программного решения, сайта или даже внедрение целой инфраструктуры — к примеру, комплексной системы видеонаблюдения.
Задача поддержки — принимать обращения клиентов, у которых возникают проблемы, фиксировать их и решать (в момент обращения или после — в соответствии с Соглашением об уровне сервиса — SLA). Иногда для решения проблемы клиента достаточно ответа на вопрос, а в других случаях требуется передать заявку профильному специалисту, который разберется в проблеме, даст развернутое объяснение и вернет работоспособность решению.
Каким бы ни было обращение, от специалистов поддержки требуется восстанавливать работу обслуживаемой инфраструктуры, ПО или услуги в кратчайшие сроки, для чего используются механизмы управления инцидентами. Формальное определение понятия «как можно быстрее» обеспечивает упомянутое выше соглашение об уровне сервиса — SLA, которое поддержка старается соблюдать или даже превосходить.
Помимо общения с клиентами, поддержка реализует важную функцию получения обратной связи от пользователей (обычно этим занимаются диспетчеры или «первая линия поддержки»), т.е. обеспечивает информацией отдел развития бизнеса — дает предложения по изменению существующих параметров продукта, услуги или проекта, а также по добавлению новых функций и опций. Особенно эта связь важна на рынке B2B, где покупатель решения (отдел закупок) чаще всего не совпадает с его пользователем (рядовые сотрудники).
Техподдержка как инструмент допродаж (upsell)
Качество поддержки влияет не только на повторные продажи, но и на появление новых клиентов. Чужие отзывы о том, что производитель хорошего решения игнорирует запросы пользователей вряд ли пройдут мимо тех, кто еще только интересуется ассортиментом аналогичных продуктов на рынке. И наоборот, решение, чьи клиенты говорят, что все их вопросы решаются буквально «на лету», получает всё большую популярность. Ведь потенциальным покупателям необходимо, чтобы бизнес работал с минимальным количеством сбоев, не влияющих на финансовые показатели.
Таким образом, техническая поддержка — это еще и инструмент повышения лояльности существующих и будущих клиентов.
Раз уж мы говорим о лояльности, то в сегменте поддержки можно выделить клиентскую и техническую. Вторая — обеспечивает решение именно технических проблем («у меня здесь не работает»), первая же работает над выстраиванием долгосрочных взаимоотношений с клиентами с целью повышения совокупного дохода, полученного от одного «контакта». Об их разнице мы уже подробно писали.
Структура поддержки
Для обеспечения лучшего уровня сервиса при сохранении разумных затрат на содержание отдела поддержки внутри него принято выделять несколько линий, разделяя между ними существующие обязанности.
Чаще всего можно выделить:
Часто в дополнительные линии (четвертую, пятую) выделяют представителей разработчиков и сторонних контрагентов, если в продукте или проекте задействованы чужие решения. Однако во многих компаниях ограничиваются лишь двумя линиями, относясь к остальным специалистам, как к партнерам по решению отдельных проблем.
Системы техподдержки
В современном мире поддержка, как и любая другая сфера взаимоотношения с клиентами, требует автоматизации — к этому подталкивает сам рынок и достаточно сложные процессы обслуживания. Клиенты привыкли, что даже в крупных ритейлерах или финансовых организациях их узнают по ID, моментально вспоминая историю взаимоотношений, и не требуют по 10 раз повторять одну и ту же историю. Того же они хотят и от сервиса в области B2B. Для удовлетворения этого клиентского ожидания компании используют программные инструменты — системы автоматизации класса helpdesk.
Системы автоматизации процессов поддержки значительно отличаются друг от друга. При выборе — важно не запутаться. Подробнее о том, как выбрать решение подобного класса читайте в отдельной заметке
Okdesk — удобная и функциональная система автоматизации техподдержки. Сотни компаний ежедневно используют лучшие практики в своей деятельности.
Вы проиграете конкурентам, если не будете развивать свою службу поддержки. Посмотрите, как это можно сделать
Руководитель службы поддержки кэшбэк-сервиса «Мегабонус»
Любой бизнес, который обслуживает большое количество клиентов, нуждается в хорошо отлаженной службе поддержки. Особенно бизнес в интернете. Для чего существует и какие задачи решает служба поддержки? Как сделать ее лучше? Александр Иванов, руководитель службы поддержки кэшбэк-сервиса «Мегабонус», отвечает в колонке на все эти вопросы.
Наша служба поддержки состоит из восьми человек, которые каждый день отвечают на вопросы почти 2 миллионов пользователей.
Для чего нужна служба поддержки
Главная задача этой службы – максимально быстро разрешать возникающие у пользователей сложные ситуации. Кроме того, есть и другое, не всегда очевидное предназначение.
Служба поддержки – это голос клиента, который доходит до руководства через ее менеджеров.
При правильном построении рабочего процесса служба поддержки принимает «боль» клиентов, анализирует ее и приходит с четко сформулированными требованиями к разработчикам, чтобы эта боль исчезла навсегда. Это еще один драйвер роста для бизнеса.
Как ускорить время обработки заявок
Процесс подачи заявок продуман заранее. Пользователь задает вопрос и его заявка сразу попадает в определенную очередь, сгруппированную по теме запроса. Это экономит время менеджера службы поддержки, которому не нужно на первом же этапе проводить такую сортировку.
На страницах личного кабинета выделено несколько основных вопросов, часто интересующих пользователей. Ссылки с них ведут раздел «Помощь». Таким образом, пользователь получает информацию, что можно не ждать ответа, а сразу же ознакомиться с нужной информацией.
В обычном режиме специалист службы поддержки отвечает на заявку пользователя от двух до четырех часов. За рабочий день такой менеджер обрабатывает 160 обращений. В среднем за месяц вся служба успевает обрабатывать около 6 тысяч заявок.
Вручную такое количество заявок быстро обработать невозможно. Для ускорения процесса нужно использовать автоматизированную систему обработки тикетов. Мы начинали с собственной системы, но вскоре отказались от ее разработки.
Лучше использовать готовый продукт, а не тратить время и деньги на изобретение велосипеда. Поэтому два года назад перешли на SAAS-модель. Время обработки заявок саппортами сократилось в четыре раза. Кроме того, появилась возможность высвободить ресурс на разработки, которые улучшают основной продукт.
В этом году запустили еще чат – сейчас это самый быстрый способ получить ответ. Среднее время ответа на вопрос пользователя в чате в ходе переписки составляет около 30 секунд. А для решения простой проблемы теперь хватает 3-5 минут.
Как проходить пиковые нагрузки
В процессе работы бывают дни и даже целые недели, когда количество заявок вырастает на 100%, а иногда даже на 200%. Обычно это периоды распродаж в крупнейших маркетплейсах.
Время таких перегрузок чаще всего известно заранее и согласовано с отделом маркетинга. Если ожидается мощная перегрузка, график саппортов составляется таким образом, чтобы в пиковые периоды работало больше людей. Поэтому, когда наступает день «Х», служба поддержки спокойно включается в этот сверхнапряженный процесс.
В моменты пиковых нагрузок скорость ответа, безусловно, важна. Но качество обслуживания при этом не должно страдать. Поэтому менеджер службы поддержки не просто рассылает шаблоны ответов, а обязательно описывает в сообщении, что ему (ей) стало понятно из вопроса пользователя. Это увеличивает осознанность и личную вовлеченность менеджера в процесс обработки заявок.
Как мотивировать людей
Вводите систему оценок. Время обработки заявки зависит от эффективности работы каждого отдельного сотрудника. Мы создали систему отчетов для измерения эффективности работы сотрудников службы поддержки.
Кроме данных о скорости ответа на запросы и количестве заявок, собираем статистику по NPS (Net Promoter Score – индекс лояльности клиентов), которая помогает совершенствовать коммуникации с пользователями.
Внедрение системы NPS помогает по ходу работы узнавать о наличии трудностей и вовремя вносить изменения в рабочий процесс.
Проводите испытания и челленджи для команды службы поддержки. Мы устраиваем челленджи не только во время завалов, но и в «тихие» периоды. Чаще всего это звучит как: «Разгребаем линию в ноль – получаем бонус». Иногда это сладости, иногда дополнительный час отдыха после того, как разгребем. Все зависит от объема и реальной необходимости.
Каким должно быть руководство
Руководство должно быть заинтересовано в развитии сотрудников службы поддержки и прислушиваться к той информации, которая от нее исходит. Нужно давать новые интересные задачи, делегировать больше ответственности и обязательно хвалить за достижения.
Такой подход позволит каждому сотруднику работать автономно – решать большой спектр задач, не взаимодействуя с коллегами. А также стремиться к постоянному развитию. Ведь в рамках службы поддержки, кроме прямого общения, есть огромное количество функций, которые сотрудник может изучить и выполнять.
Например, работа с выплатами, переводы статей на иностранные языки, написание статей раздел «Помощь». Чтобы у менеджера службы поддержки появилась такая возможность – создавайте базы знаний, обучайте, назначайте наставников, используйте удобные системы администрирования.
Специалист службы поддержки – это ценный сотрудник. А сама служба – важный отдел сервиса. Если к этой службе относится без должного внимания и заботы, то бизнес своевременно не получит важную информацию о клиентах, начнет стагнировать и в итоге проиграет.
Где взять лучших специалистов
В этой работе нужна доброжелательность, любовь к людям, желание помочь, умение разобраться в проблеме, быстро обучаться новому, и, конечно, стрессоустойчивость. Как найти такого многогранного специалиста? Все просто – никак. Его можно только воспитать в своем коллективе, создавая условия, постоянно обучая и транслируя ценности компании.
Подбирайте в команду людей отзывчивых, заинтересованных в помощи другим. Эти личные качества помогут как при обучении, так и при столкновении со сложными ситуациями.
И в завершение мы предоставили возможность специалистам службы поддержки «Мегабонус» рассказать все, что они думают о своей работе.
Наташа, специалист службы поддержки
В сервисе «Мегабонус» я работаю довольно давно, около 2,5 лет. Получаю удовольствие от того, что могу быть полезной нашим клиентам. Для этой работы главное, чтобы человек был доброжелательным и общительным. Я люблю разбираться в сложных ситуациях.
Часто приходится помогать пользователям не только в вопросах, касающихся работы сервиса. Например, когда возникают проблемы при оформлении заказов или оплате на сайтах магазинов-партнеров. Также пользователи часто не умеют делать скриншоты, чистить кэш/куки в браузере. Тоже помогаю.
Порой я слишком сильно погружаюсь в работу – она снится мне по ночам. Я во сне заканчиваю то, что не успела за рабочий день. Несколько раз так даже появились решения настоящих проблем.
Однако несмотря на большую нагрузку, в моей работе ничто не вызывает раздражение. Иногда я только расстраиваюсь, когда нет возможности помочь пользователю в кратчайшие сроки. Такое случается, если вопрос зависит не от меня напрямую.
Длительное время я работала удаленно. Но последние полгода стараюсь бывать в офисе так часто, как могу, потому что здесь очень здорово! В дружеской атмосфере работать гораздо приятнее и легче, чем одной из дома.
Эд, специалист службы поддержки
Я приехал из Анголы и работаю в компании меньше года. Занимаюсь решением вопросов иностранных пользователей «Мегабонус» на испанском и португальском языке. Самым важным для меня является выполнение поставленных задач.
Работать я люблю больше в офисе, потому что меня устраивает график работы. Это дает мне возможность учиться и работать одновременно. А еще я люблю работать в офисе, потому что мне очень нравится коллектив.
Майя, специалист службы поддержки
Наиболее вдохновляющим в моей работе я нахожу возможность быть полезной нашим клиентам в решении проблем, способность делиться своим опытом и знанием продукта, а также самореализацию. Обратная связь от клиентов помогает мне сознавать, что я приношу пользу компании.
Ведь если ты кому-то смог помочь – это всегда очень приятно.
Для работы в качестве менеджера службы поддержки нужны следующие качества: внимательность к потребностям клиента, умение обнаружить корень проблемы, умение общаться, готовность помочь, а также способность работать с большим объемом информации. Эта работа очень хорошо сочетается с моим типом личности.
Здесь бывают и забавные ситуации: довольно часто пользователи, понимая, что менеджером службы поддержки является девушка, делают комплименты, приглашают на свидания.
Алевтина, специалист службы поддержки
На мой взгляд, для работы в техподдержке важен лишь определенный набор личных качеств. На первом месте – безусловная любовь к людям. Желание помочь должно быть искренним, его невозможно изобразить или подделать. Я всегда представляю, что пользователь, с которым я общаюсь, – это мой друг или родственник. И ему действительно нужна моя помощь.
Мне также нравится, что мы занимаемся не только работой с людьми, но и с технологиями. Часто нам удается самостоятельно найти баги, неполадки. Мы имеем возможность в режиме реального времени следить за развитием нашего продукта, вносить в него свой вклад.
Порой раздражает собственное бессилие. Хочется помочь пользователю, но не всегда удается сделать это в кратчайшие сроки, так как решение вопроса может зависеть от целой группы людей или целого отдела. В нашей работе важно разделять ценности компании. Важно искренне верить в то, что ты предлагаешь людям. В пользу, которую приносишь. Без этого работа превратится в издевательство над собой.
Я работаю здесь, потому что верю, что наша команда и продукт самые лучшие. Я могу работать из дома, но люблю приходить в офис. Так как здесь я тоже чувствую себя как дома. Здесь находятся близкие мне по духу люди. Не было дня, когда бы я проснулась с мыслью «Боже, не хочу идти в этот офис». Всегда иду на работу с удовольствием и в отличном расположении духа.
Антон Сухарев, основатель и руководитель кэшбэк-сервиса «Мегабонус»
Обслуживание клиентов – один из ключевых бизнес-процессов компании. Мы всегда уделяли большое внимание качественному обслуживанию пользователей. Ни для кого не секрет, что удержание существующего клиента обходится компании в пять раз дешевле, чем привлечение нового, поэтому наши ребята четко понимают важность своего дела.
Во главе всего мы ставим взаимоотношения с пользователем, всегда смещаем фокус принятия решений в пользу пользователей нежели рекламодателей. Рекламодатели для нас тоже важны. Но интерес рекламодателя там, где присутствует внимание пользователя. Поэтому мы стараемся сделать так, чтобы взаимодействие было полезным и выгодным для всех, но в первую очередь для конечного потребителя.
Мы продолжаем расти, и у нас есть большое желание стать еще лучше. Поэтому будем рады вашим комментариям к статье.