Support что за организация
Нужен ли support
Немалое количество владельцев сайтов считают, что служба support совершенно не нужна, и могут логически обосновать своё мнение. Ведь техподдержка не продаёт товар, не выдвигает сайт в топы, не рекламирует и не приносит никакого дохода. Можно подумать, что от support одни лишь растраты.
Но мы с вами сейчас убедимся, что это не так.
Что будет, если на сайте нет техподдержки
Чтобы посмотреть, что произойдёт, если на сайте нет support, смоделируем простой пример.
Допустим, есть интернет-магазин. Сюда приходят посетители, которые ищут определённый товар, например, сотовый телефон. Потенциальный клиент благополучно находит нужную модель. Вы, естественно, позаботились об информативности, и рассказали на сайте об этом телефоне всё, что могли и знали.
Но тут у клиента возник вполне обычный вопрос, который не сказан в ваших характеристиках телефона – например, сколько времени он будет держать заряд батареи. И тогда посетитель будет искать помощи на сайте – support. А так как её он не найдёт, клиент покинет сайт, и отыщет эту информацию у вашего конкурента. Да ещё и напишет потом о вас плохой отзыв.
Пример достаточно грубый, но он в полной мере показывает важность присутствия support на сайте.
Какие вопросы должна охватывать техподдержка, и как это организовать
Служба поддержки должна решать следующие вопросы:
Технические вопросы от клиентов сайта могут решаться двумя способами: шаблонным – вы даёте своей техподдержке список стандартных и частых вопросов с ответами, и они работают; и фундаментальным – вы даёте своей техподдержке с связь с IT-специалистом сайта, который может быстро решить серьёзную и нестандартную проблему.
Консультация о товарах или услугах, это как раз то, о чём был пример, описанный выше. Поэтому ваш support на сайте должен знать о продукции всё. Не заучивать это, естественно. Вы должны предоставить эту информацию в лёгком доступе.
Вопросы денег возникают всегда, и support должен либо удовлетворить просьбу клиента, либо отказать. Поэтому техподдержка должна знать политику вашей компании.
Предложения, которые высказывают ваши клиенты, тоже очень важны. К мнению со стороны нужно прислушиваться, ведь там всегда найдётся новая и актуальная идея для сайта.
Support, в зависимости от специфики сайта, может выполнять больше или меньше описанных функций. Техподдержка может состоять как из группы людей, так и из одного человека. Для каждого сайта это индивидуально.
«Не думай о саппорте свысока»: как реализовать скрытые возможности вашей службы поддержки
Практически любой организации, так или иначе связанной с продажей софта, необходимо наличие линии поддержки. Саппорт ассоциируется с помощью в освоении продукта и решением разного рода проблем клиента, как правило, технического характера. Эти функции действительно составляют основу работы команд поддержки, хотя есть и много скрытых «плюшек», которые Саппорт может дать бизнесу, если его потенциал использовать на полную мощность. О них речь и пойдет под катом.
Саппорт может стать многофункциональным инструментом, решающим важные задачи как внутри компании, так и на «клиентском» направлении. Попробуем выделить несколько ролей, которые поддержка может сыграть на подмостках любого IT-бизнеса.
1. Саппорт-психолог
Наиболее очевидная дополнительная функция Саппорта, касающаяся работы с клиентом.
С психологической точки зрения человек, успешно помогающий разрешить проблему, автоматически записывается в товарищи или бадди. К такому человеку проще обратиться за помощью вновь, рассчитывая на поддержку. Клиенты порой воспринимают «саппортеров» как своих личных психотерапевтов / психологов и пользуются возможностью высказаться, ведь код общения не предполагает отказов в обслуживании (конечно, важным условием является достойный уровень профессионализма агента поддержки).
Роль психолога обычно взывает к доверию – клиенты, довольные результатом сеансов психотерапии, с большим уважением начинают относиться к самой компании, их лояльность повышается. В особо удачных случаях постоянного содействия Саппорта клиент может стать добровольным евангелистом продукта в своей команде.
В нашей Саппорт-практике в Wrike нашлись примеры прекрасных отношений с клиентами, которых мы поддерживаем. Сложившиеся связи в некоторых случаях стали теплыми и дружескими, во многом благодаря многократному взаимодействию со «счастливым исходом». Такие клиенты всегда замолвят за нас словечко — например, при кросс-продаже продукта в другие отделы или при общении с другими пользователями в нашем Сообществе. Свежий пример: недавно мы узнали о переходе одного из наиболее активных в общении с Саппортом клиентов в другую компанию. Одним из условий этого перехода стало использование Wrike как инструмента для планирования проектов. Эту новость в дружеской беседе нам сообщил сам клиент со словами «I’m a Wriker to the end!», что не могло не порадовать всю команду!
2. Саппорт-пожарный
Представим ситуацию – у вас случился некий глобальный инцидент (массовая проблема, критический баг, упаси боже даунтайм), а уполномоченные инженеры/админы еще не осознали, что «все плохо», или осознали, но заняты срочным устранением последствий. Тем временем, наверняка уже есть большое количество недовольных пользователей, которым срочно необходимо получить комментарий. На помощь приходит Саппорт-пожарный, который всех успокоит, все объяснит, а затем доведет нужную для выявления проблемы информацию инженерам.
Стоит заметить, что в этом случае при правильном подходе можно добиться результата, который предсказывается психологами — люди, проблемы которых хорошо и оперативно решаются при правильной коммуникации, в итоге оказываются довольнее тех, кто с проблемами совсем не сталкивался. Поддержка в таких экстренных случаях также служит отличным индикатором проблем — зачастую пользователь первым замечает неладное, о чем сразу же уведомляет Саппорт. При хорошо налаженной системе внутренней коммуникации проблема может быть уничтожена еще в зародыше, и в этом во многом заслуга Саппорта, вовремя передавшего информацию.
В команде поддержки Wrike сложилась определенная практика взаимодействия с инженерами при возникновении критических ситуаций. Мы стараемся чутко реагировать на любые сообщения клиентов, которые могут заявлять о потенциальной проблеме, собираем максимум информации и информируем дежурных инженеров. Схожая схема работы применяется при обнаружении критических багов, где к сотрудничеству мгновенно привлекается отдел QA (третий уровень нашей поддержки, см. пост о том как это работает в деталях здесь). Оперативная реакция Саппорта не раз помогала предотвратить более драматическое развитие событий.
3. Саппорт-коммуникатор
Эта роль команды поддержки имеет ярко выраженное влияние на развитие продукта. Саппорт представляет огромную пользу для любого ПМа, поскольку обладает сакральным знанием о том, что же все-таки клиент желает.
Какую помощь для развития продукта Саппорт может оказать? Передача фидбэка от пользователя напрямую в продуктовый отдел одна из альтернатив. К примеру, наша команда Поддержки фиксирует фидбэк от пользователей в Сообществе Wrike и представляет отчеты менеджерам продукта на регулярной основе. Никто не поймет клиента лучше представителя поддержки, поэтому интерпретацию любой обратной связи полезно отдавать именно Саппорту.
Другой подход – использование общего понимания нужд клиента и их «ретрансляция» другим командам. Саппорт Wrike частый гость на мероприятиях Scrum команд – к нашему мнению прислушиваются, поскольку мы представляем интересы клиента и являемся важным стейкхолдером.
Коммуникативная функция работает и в обратном направлении – ПМы или инженеры могут попросить Саппорт собрать сведения или статистику по интересующей теме, донести информацию до клиента, и т.д. Важно отметить, что эту функцию стоит использовать с умом и осторожностью — Саппорт плавает в океане данных о клиентах, и самая большая проблема в том, как эти данные систематизировать и сделать правильные выводы, не уводящие в сторону.
4. Саппорт-кузница качественных кадров
Еще одной неоспоримой «скрытой» функцией Саппорта является его кадровый потенциал.
Универсальность навыков и знаний, всестороннее понимание продукта и большой опыт в коммуникациях с клиентами делают выходцев из Саппорта желанными в любых клиентских и продуктовых отделах (маркетинг, продажи, консультирование и т.д.). В случае если команда Поддержки еще и мультиязычная (и покрывает несколько часовых поясов/ географических локаций), ее внутренняя культура также способствует дополнительному развитию коммуникативных навыков, что конвертируется в полезность для любой клиент-ориентированной работы.
Саппорт Wrike, к примеру, работает из Западной и Восточной Европы, России, Северной и Южной Америки; мы говорим на русском, украинском, английском, испанском, французском, немецком, португальском (и, кстати, в этой связи помогаем с локализацией продукта). На этом языковой потенциал команды не исчерпан — знание некоторых менее распространенных языков (эстонский, шведский, тибетский (!) нечасто находит применение в работе, но зато является приятным бонусом для любого носителя редкого языка, заглянувшего в наш Саппорт-чат.
Если ваша поддержка отличается технической направленностью, то специалистам прямая дорога в QA или даже в разработку (при наличии навыков кодинга) – понимание продукта со стороны клиента может очень сильно пригодиться как в тестировании, так и создании новых фич. Саппорт-агенты, как правило, очень трудолюбивые и упорные ребята. Они докопаются до сути, помогут во всем разобраться, привыкли работать быстро и скрупулёзно, ведь солидные очереди входящей корреспонденции или звонков тренируют армейскую реакцию и сосредоточенность. Такие навыки приветствуются при любой работе! Кроме того, это люди с разным образовательным / профессиональным прошлым – никогда не знаешь, специалиста в какой области можно найти в отделе Поддержки (в Поддержке Wrike есть филологи, маркетологи, преподаватели, а также кандидаты и доктора наук).
Рекомендации от экспертов. Блог 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-продукта, часть 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 продукта, а организация правильного взаимодействия между саппортом и отделом разработки должна стать одной из приоритетных задач менеджмента.
Даже если саппортер задаёт глупый вопрос, разработчику не стоит закатывать глаза, ведь вопрос саппортера — это почти всегда вопрос клиента. Чем лучше программист вникает в «тупые» вопросы пользователей и объясняет технические аспекты службе поддержки, тем больше прокачиваются его софты. А чем лучше прокачиваются софты, тем более «дружелюбным» для пользователя становится программный продукт.
Да, можно упростить задачу и нанять саппортера-инженера, который способен общаться с технарями на одном языке. Однако для начинающих компаний такой наём вряд ли окажется финансово выгодным — реальных технических проблем у стартапов не так много, а платить квалифицированному сотруднику придётся в несколько раз больше.
Вывод:
Взаимодействие саппорта и разработчиков — это мост, на котором стоит пользователь. А отношения между ними влияют не только на климат в коллективе, но и на качество всего продукта.
Резюмируем
Программное обеспечение для оптимизации работы службы поддержки пользователей.