Для нас было важно создание единого облачного решения, которое при обновлении в одном месте ретранслирует обновлённую информацию во все разделы, структуры и иерархии других подразделений, с которыми работают наши клиенты.

Сейчас базы знаний находятся в одном месте и оперативно обновляются технической поддержкой. Очень важно, чтобы информация была актуальной. Даже тогда, когда происходят небольшие изменения – мы стараемся оперативно быстро обновить информацию в Базе знаний.

В Базах знаний содержатся и находятся ответы на все вопросы клиентов, которые нам когда-либо задавали. Если клиент задаёт нам вопрос, ответа на который нет в Базе знаний – специалисты технической поддержки (клиентского сервиса) добавляют эту информацию в необходимый раздел данного информационного ресурса.

Все базы знаний во всех направлениях интегрированы в CRM Хелпдеск – это особенно важно для того, чтобы давать оперативный вопрос клиентам и отвечать на любой вопрос клиентов.

Глава 8. Реализация информационных рассылок.

Реализация информационных рассылок предусмотрена для того, чтобы оповещать клиентов в случае аварийных ситуаций, когда программа или программное обеспечение для взаимодействия с клиентом не работает.

Информационные рассылки реализованы на основе платформы Хелпдеск, а также интеграционного взаимодействия с функционалом от ботмамы.

Используя опции CRM, мы информируем клиентов о том, что в нашей системе произошёл сбой/авария, и когда данный сбой будет устранён, ну и, конечно, после устранения сбоя.

Данная процедура необходима для организации лучшей технической поддержки. Это важно для того, чтобы оповещать клиентов о сбое раньше, чем они с ним (сбоем) столкнутся.

Данная реализация имеет как плюсы, так и минусы. К плюсам относится то, что мы имеем функционал, позволяющий в двухстороннем направлении общаться с клиентами. Минус – это то, что клиенты могли бы и не узнать об аварии, но из-за нашего информирования они (клиенты) об аварии узнают и могут использовать данную информацию в провокационных и других целях, носящих характер саботажа или коммерческого шантажа.

После того, как мы реализовали информационные рассылки через Ватсап, мы реализовали информирование в самой программе, но, как я и писал раньше – индивидуальное обращение в Ватсап или «тележку» работает лучше, чем информирование о сбое или аварии в самой программе. Также к минусам информирования о сбое/аварии из самого ПО – можно отнести тот факт, что если ПО не работает, то и саму «объяву» наши клиенты также не видят. Мы почесали затылки, пообщались, обсудили, ещё раз пообщались и договорились, что:

– если мы не хотим усложнять реализацию задачи, её проработку и эксплуатацию – нам нужно, прежде всего, сделать акцент на том, чтобы избегать аварийных и сбойных ситуаций, когда у нас не работает программа;

– мы заводим аварийный канал в «телеге» и заводим туда всех заинтересованных пользователей, клиентов, партнёров, при этом число ответственных, которые имеют возможность информирования в канале, регламентировано определённым количеством от каждой стороны участников процесса;

– мы создаем всплывающую информационную плашку в программе, в которой информируем клиентов о сбоях и нововведениях, при этом важно отметить, что в зависимости от важности новости у плашки разная цветовая гамма и палитра: красный, жёлтый, зелёный;

– в качестве резервного канала информирования клиентов мы используем Ватсап и Telegram и используем их, когда остальные средства и методы недоступны.

То есть, говоря простыми словами – мы не пишем в Ватсап о том, что у нас ошибка или неполадка в модуле. В Ватсап мы пишем только в случае серьёзной аварии, только тогда, когда проинформировать клиентов в программе не получается.

Ну и конечно информируем через, а точнее, ИЗ нашего Хелпдеска.

Ну, не буду напоминать, что КЛИЕНТЫ – это наше всё, и наша задача, задача Лучшей технической поддержки – информировать клиентов и держать их в курсе. Это важно не только для того, чтобы закрывать вопросы типа: «а почему вы нас не предупредили?» Это важно, чтобы клиенты понимали, что происходит, и если это происходит, могли оперативно принимать стратегически важные для них (КЛИЕНТОВ) решения.

Так обстоит в нашей технической поддержке дело с информационными рассылками.

Глава 9. Внедрение методологии работы с жалобами.

Методология работы с жалобами – это современная часть клиентского сервиса. Многие компании недооценивают эффективность работы с жалобами и вместо того, чтобы обращать на жалобы особенное и пристальное внимание, стараются эти проблемы замаскировать и не учитывать ни в работе технической поддержки, ни в работе компании. Многие используют жалобы как некий формат метрики, по которому оценивают работу и качество технической поддержки и клиентского сервиса (чем меньше жалоб, тем лучше сервис) – это неправильно. Неправильно не то, что коллеги используют жалобу как метрику, неправильно то, как эту метрику используют. Непонятно? Запутанно? Тогда читайте дальше, сейчас всё разжуём и погрузимся в детали.

Современные методы работы технической поддержки с жалобами таковы, что крайне важно относиться к жалобам, как к подарку, как к подарку судьбы. Жалоба от клиента – это именно подарок судьбы. Ведь представьте, что клиент мог отнести этот подарок не вам, а куда-нибудь в другое место, например, на Первый телевизионный канал и затем эту новость подали бы вам в вечерних новостях.

Задача технической поддержки (при получении проблемы), не хвататься за голову и не прятать её (голову) в песок, а искренне поблагодарить клиента за то, что он сообщил нам о проблеме.

Мы благодарим клиентов за то, что они нам жалуются и сообщают о проблемах.

Сегодня у нас есть определённый регламент, в котором описываются конкретные действия для технической поддержки, если они получают жалобу:

– благодарим клиента и говорим спасибо за жалобу/проблему;

– объясняем клиенту, почему для нас важна жалоба;

– извиняемся перед клиентом (очень важно извиняться, но не делать это сразу, а только после 1 и 2 пункта);

– сообщаем о том, что мы все уже бросились на исправление/решение ситуации;

– исправляемся и отвечаем.

Пример:

Благодарим вас за проблему.

Спасибо, что сообщили нам об этой ситуации.

Для нас очень важен подобный фидбек.

Извините за доставленные неудобства.

Мы уже связываемся с коллегами из диспетчерского центра, чтобы выяснить ситуацию о сбое.

Главные задачи технической поддержки – это поблагодарить за жалобу, рассказать клиенту о том, что для нас это очень важно, и объяснить почему. Извиниться за то, что мы доставляем клиенту подобные неудобства. Рассказать о том, что мы уже взяли в работу данную жалобу и через определённое время вернёмся к клиенту с решением и ответом на вопрос по его жалобе.

Данный формат очень важен для того, чтобы не потерять клиентов, а приумножить. Также в формате работ с жалобами в технической поддержке организован специальный канал – «Наши клиенты».

В этом канале собраны все клиенты, которые любят сообщать нам о проблемах. Наши клиенты нам часто пишут и жалуются, и сообщают о проблемах. Наши клиенты – это очень важные для нас люди. Всех клиентов, которые находятся в этом канале, в этом разделе, мы обслуживаем как наших лучших клиентов. Обычно, вопросы от Наших клиентов мы решаем в первую очередь. Мы всем клиентам стараемся отвечать максимально быстро, но Нашим клиентам мы стараемся отвечать реактивно – мы быстро передаём проблему в любых направлениях для достижения лучшего результата. Это не значит, что со всеми другими клиентами мы не делаем так же, как с Нашими клиентами – делаем, но приоритет всё же у Наших клиентов.