В этой статье поговорим о компаниях, которые планируют внедрять омниканальные сервисы и платформы: банках, страховых компаниях, различных учреждениях, которые работают в сегментах B2C или B2B.
Даже в сегменте B2B конечный потребитель – это конкретный человек: бухгалтер, генеральный директор и т.д. Сервисы для управления коммуникациями, как правило, в B2B и B2C тоже практически одинаковые, с той лишь разницей, что количество контактов в B2C больше.
Какие основные ошибки они совершают при внедрении многоканального сервиса для коммуникации с клиентами?
Даже в сегменте B2B конечный потребитель – это конкретный человек: бухгалтер, генеральный директор и т.д. Сервисы для управления коммуникациями, как правило, в B2B и B2C тоже практически одинаковые, с той лишь разницей, что количество контактов в B2C больше.
Какие основные ошибки они совершают при внедрении многоканального сервиса для коммуникации с клиентами?
- Многоканальность не равно омниканальность
В чем разница? Многоканальность – это множество каналов коммуникаций, не связанных между собой. Часто такой подход называют «омниканальностью», что в корне не верно.
Разберем ситуацию. Клиент обращается на сайте в чат поддержки, он работает за компьютером. Затем рабочий день заканчивается, и он переходит в мобильное приложение и хочет продолжить диалог.
По факту, это новый канал коммуникации, и они должны быть связаны. Но преемственности нет, и диалог создается заново. Клиент звонит, чтобы было быстрее, и попадает на линию обслуживания, где, скорее всего, его встречает робот, который не всегда справляется со стандартными задачами. И после этого его переводят на оператора колл-центра.
В результате клиент вынужден свой вопрос или проблему озвучивать многократно: в каждом новом канале коммуникации регистрируется новое обращение, и в результате мы видим огромное количество негатива со стороны клиента и трудозатрат со стороны организации, которая его обслуживает.
Это типичная ситуация для ритейла, e-com, финтеха, телекома, медицины и госкомпаний.
Чаще всего, сервисы для связи с клиентами прирастают постепенно с ростом компании и самих коммуникаций, но в какой-то момент такой «зоопарк» систем становится проблемой: информация в них отличается, может быть не актуальной, клиенты тратят большое количество времени на решение своих вопросов.
И в такой ситуации нужно или все системы внедрять заново, но уже связанные между собой, или интегрировать их между собой, что очень дорого – не все системы рассчитаны на это.2.
Разберем ситуацию. Клиент обращается на сайте в чат поддержки, он работает за компьютером. Затем рабочий день заканчивается, и он переходит в мобильное приложение и хочет продолжить диалог.
По факту, это новый канал коммуникации, и они должны быть связаны. Но преемственности нет, и диалог создается заново. Клиент звонит, чтобы было быстрее, и попадает на линию обслуживания, где, скорее всего, его встречает робот, который не всегда справляется со стандартными задачами. И после этого его переводят на оператора колл-центра.
В результате клиент вынужден свой вопрос или проблему озвучивать многократно: в каждом новом канале коммуникации регистрируется новое обращение, и в результате мы видим огромное количество негатива со стороны клиента и трудозатрат со стороны организации, которая его обслуживает.
Это типичная ситуация для ритейла, e-com, финтеха, телекома, медицины и госкомпаний.
Чаще всего, сервисы для связи с клиентами прирастают постепенно с ростом компании и самих коммуникаций, но в какой-то момент такой «зоопарк» систем становится проблемой: информация в них отличается, может быть не актуальной, клиенты тратят большое количество времени на решение своих вопросов.
И в такой ситуации нужно или все системы внедрять заново, но уже связанные между собой, или интегрировать их между собой, что очень дорого – не все системы рассчитаны на это.2.
2. Выбор моновендора
Еще одна типичная ошибка при внедрении омниканальных платформ – это выбор вендора, который предоставляет все каналы коммуникации: и телефонию, и чат-боты, и LMS, и голосовых помощников. Как правило, в 90% случаев они не объединены в систему: вендор по мере необходимости приобретал разработку или более мелкие компании, чтобы предложить как можно более широкий спектр услуг.
Т.е. по большому счету компания-заказчик подсаживается на иглу vendorlock - придется постоянно доинтегрировать сервисы между собой. Из зарубежных это, например, Salesforce, которые приобрели множество компаний и предлагают их решения под видом экосистемы. В России это каждый второй вендор, позиционирующий себя как омниканальное решение.
Т.е. по большому счету компания-заказчик подсаживается на иглу vendorlock - придется постоянно доинтегрировать сервисы между собой. Из зарубежных это, например, Salesforce, которые приобрели множество компаний и предлагают их решения под видом экосистемы. В России это каждый второй вендор, позиционирующий себя как омниканальное решение.
3. Только самостоятельна разработка
Обычно это ошибка больших холдингов, у которых есть свой отдел разработки, который они могут себе позволить содержать и развивать.
Вроде бы, идея все сделать самостоятельно не лишена плюсов, но по факту чаще всего это тоже зависимость, но уже от отдела разработки. В какой-то момент «рабочих рук» станет не хватать, задачи пойдут в бэклог и будут решаться не оперативно. С этого момента штат начнет расти, а соответственно – и затраты. Нередко спустя несколько лет они превышают стоимость разработки и поддержки вендором целевого решения, которое изначально требовалось.
Например, Dodo Pizza, Avito, Yandex, и т.д.
Если Вы решили разрабатывать сервисы самостоятельно, то правильнее будет миксовать задачи: основную архитектуру и интеграцию отдать внутреннему подразделению, а кодинг отдавать вендору.
Вроде бы, идея все сделать самостоятельно не лишена плюсов, но по факту чаще всего это тоже зависимость, но уже от отдела разработки. В какой-то момент «рабочих рук» станет не хватать, задачи пойдут в бэклог и будут решаться не оперативно. С этого момента штат начнет расти, а соответственно – и затраты. Нередко спустя несколько лет они превышают стоимость разработки и поддержки вендором целевого решения, которое изначально требовалось.
Например, Dodo Pizza, Avito, Yandex, и т.д.
Если Вы решили разрабатывать сервисы самостоятельно, то правильнее будет миксовать задачи: основную архитектуру и интеграцию отдать внутреннему подразделению, а кодинг отдавать вендору.
4. Перенос устаревших процессов в новую систему
Еще одна типичная ошибка. В целом, все понятно из названия – при создании новой системы часто заказчики хотят перенести все процессы, даже устаревшие и неиспользуемые.
При миграции важно садиться и описывать все способы коммуникации с нуля и заново. И здесь лучше привлечь бизнес-аналитиков, которые умеют это делать и настраивать.
Например, наша система позволяет самостоятельно настроить процессы через интерфейс и сделать их в дальнейшем исполняемыми. Но в большинстве случаев это кодинг.
При миграции важно садиться и описывать все способы коммуникации с нуля и заново. И здесь лучше привлечь бизнес-аналитиков, которые умеют это делать и настраивать.
Например, наша система позволяет самостоятельно настроить процессы через интерфейс и сделать их в дальнейшем исполняемыми. Но в большинстве случаев это кодинг.
5. Разрозненность баз знаний
В попытке создать омниканальное обслуживание компании часто забывают об омниканальности знаний. Вроде бы, каналы коммуникации интегрированы друг с другом, но есть нюанс - каждый из них продолжает использовать свою базу знаний: роботы, операторы колл-центра, чат-боты и т.д.
И здесь возникает опасность разрозненной информации, потому что когда контент обновляется, то ресурсы не получают обновление одновременно и автоматически.
Получается, что вроде как бы у них омниканальность есть, но контент, передаваемый в рамках этих каналов, все равно остается разрозненным и кривым.
И здесь возникает опасность разрозненной информации, потому что когда контент обновляется, то ресурсы не получают обновление одновременно и автоматически.
Получается, что вроде как бы у них омниканальность есть, но контент, передаваемый в рамках этих каналов, все равно остается разрозненным и кривым.
6. Ошибка перемиграции контента
Эта ошибка чем-то схожа с переносом старых процессов в новую систему, но здесь это избыточный перенос контента.
Не весь контент можно перенести автоматически, потому что в исторических системах часто находятся баги и костыли, которые не позволяют это сделать.
Поэтому и вендору, и заказчику перед переносом нужно посмотреть и оценить, что из знаний должно быть в новой системе, а что – устарело. Если переносить все – это раздувает бюджет проекта и его сроки, замусоривает новую систему.
Не весь контент можно перенести автоматически, потому что в исторических системах часто находятся баги и костыли, которые не позволяют это сделать.
Поэтому и вендору, и заказчику перед переносом нужно посмотреть и оценить, что из знаний должно быть в новой системе, а что – устарело. Если переносить все – это раздувает бюджет проекта и его сроки, замусоривает новую систему.
7. Отсутствие сотрудников, обслуживающих систему
В компании должны быть сотрудники, которые на регулярной основе оценивают качество и скорость обслуживания, выявляют неточности и выявляют повторы информации, и, в конечном счете, подсказывают, как изменить контент, его структуру, обеспечить лучшую скорость поиска.
Если таких специалистов нет, то, закупив систему и потратив на нее бюджет, вы, мягко говоря, неэффективно расходовали инвестиции. Соответственно, как показывает наш опыт работы с нашими клиентами, инвестиции в такой персонал приводят к существенному росту качества обслуживания. Например, количество ошибок при обслуживании снижается на десятки процентов, снижается количество повторных обращений и т.д.
Из всего выше сказанного можно сделать вывод, что ошибки встречаются часто. У нас, фактически, не было ни одного заказчика, у которого бы при обращении к нам не встретилась хотя бы одна.
Проводите предварительную работу, обращайтесь к правильным консультантам и выбирайте правильные продукты, которые действительно доказали свою эффективность.
Отдавайте предпочтения тем платформам, которые встраиваются в существующую архитектуру сервисов и связывают их между собой. Например, наша платформа L2U позволяет не заменять каналы коммуникации, а связывать их через low-code платформу в единый коммуникационный сервис. Т.е. вы не зависите от вендора, но приобретаете омниканальность. По сути, это означает повышение отдачи на уже сделанные инвестиции.
Если таких специалистов нет, то, закупив систему и потратив на нее бюджет, вы, мягко говоря, неэффективно расходовали инвестиции. Соответственно, как показывает наш опыт работы с нашими клиентами, инвестиции в такой персонал приводят к существенному росту качества обслуживания. Например, количество ошибок при обслуживании снижается на десятки процентов, снижается количество повторных обращений и т.д.
Из всего выше сказанного можно сделать вывод, что ошибки встречаются часто. У нас, фактически, не было ни одного заказчика, у которого бы при обращении к нам не встретилась хотя бы одна.
Проводите предварительную работу, обращайтесь к правильным консультантам и выбирайте правильные продукты, которые действительно доказали свою эффективность.
Отдавайте предпочтения тем платформам, которые встраиваются в существующую архитектуру сервисов и связывают их между собой. Например, наша платформа L2U позволяет не заменять каналы коммуникации, а связывать их через low-code платформу в единый коммуникационный сервис. Т.е. вы не зависите от вендора, но приобретаете омниканальность. По сути, это означает повышение отдачи на уже сделанные инвестиции.