Моя позиция: не стоит строить омниканальность как технологический проект. Сначала нужно договориться, какая информация действительно нужна человеку на следующем шаге. Только потом выбирать интерфейсы и интеграции.
Проблема не в каналах, а в разрыве ответственности
Типовой путь клиента выглядит просто. Он задаёт вопрос в чате, получает ответ и просит перезвонить. Менеджер набирает номер, но переписку не видит. Поэтому снова спрашивает, с чем человек обращался, какие условия уже обсуждали и чего он ждёт от звонка.
Клиент слышит не внутреннюю проблему компании, а сообщение: «Меня не помнят». Даже если оператор вежлив, впечатление от коммуникации уже ухудшается. А у сотрудника появляется риск дать ответ, который расходится с обещанием из чата.
Такие разрывы особенно заметны там, где решение не принимают за один контакт:
Обычно причина не в том, что сотрудники плохо работают. История распадается, когда телефония, CRM, чаты и личные заметки существуют отдельно. За карточки отвечает одна команда, за звонки — другая, за чат сайта — третья. При этом никто не владеет всем маршрутом обращения от первого вопроса до результата.
Поэтому вопрос для руководителя звучит не так: «Какие каналы нам ещё подключить?» Правильнее спросить: «В какой момент клиент перестаёт быть понятен следующему сотруднику — и кто отвечает за этот разрыв?»
Единый профиль — это не досье на человека
Распространённая ошибка — считать единый профиль клиента максимально полной базой данных. Из-за этого карточка обрастает полями, которые никто не заполняет или не использует. В итоге команда возвращается к заметкам в личных чатах и таблицах.
Рабочий профиль должен отвечать на три вопроса: кто обратился, что уже произошло и что нужно сделать дальше.
Первый блок — идентификация: имя, номер телефона, электронная почта, аккаунт в мессенджере, компания при корпоративном обращении. Здесь нужны правила сопоставления. Один и тот же человек может написать с личного аккаунта, позвонить с другого номера и оставить рабочую почту в форме. Без правил вместо одной истории появятся дубли.
Второй блок — источник и история контактов: откуда начался диалог, хронология сообщений, итогов разговоров, прикреплённых материалов и попыток связаться.
Но полную историю не обязательно выводить на первый экран. Для первой линии важнее короткое резюме: тема обращения, ключевые детали, открытые вопросы и уже данные обещания. Полная переписка должна оставаться доступной, если потребуется уточнение.
Третий блок — статус, ответственный и следующий шаг. Именно он отличает историю от архива. Если после разговора клиенту обещали прислать информацию, это должно стать понятной задачей, а не комментарием. Если сотрудник не дозвонился, нужен зафиксированный дальнейший сценарий: повторный звонок, сообщение, закрытие или передача другому специалисту.
При этом профиль не должен включать чувствительные сведения, не нужные для обслуживания или продажи. Для каждой категории данных стоит определить доступы, сроки хранения и основания обработки по правилам компании и применимому законодательству.
Качество заметок тоже влияет на бесшовное общение с клиентом по каналам. Запись «клиент сложный» не даёт следующему сотруднику никакой опоры. Наблюдаемые факты дают: «ожидает звонок после согласования условий», «просил прислать варианты до определённой даты».
Переход из чата в звонок — отдельный процесс
Компании часто относятся к нему как к технической мелочи: клиент оставил номер, сотрудник перезвонил. Но переход клиента из чата в звонок требует сценария передачи. Без него история каждый раз начинается заново.
Сначала стоит решить, нужен ли звонок вообще. В чате удобнее передать ссылку, инструкцию, список документов или краткий ответ. Голосовой контакт оправдан, когда нужно быстро уточнить сложную потребность, договориться о следующем действии, снять возражения или прекратить затянувшуюся переписку.
Если звонок нужен, важно получить согласие и удобное время. Формулировка «Можем позвонить вам сегодня? Укажите номер и удобный интервал» полезнее автоматического обещания перезвонить. Она уменьшает число бесполезных попыток связи и сразу создаёт основу для передачи обращения.
Перед звонком сотрудник должен увидеть короткую карточку: тему обращения, вопросы и ответы из чата, детали, которые ещё нужно уточнить, обещанные материалы или действия, причину звонка и ответственного за него.
Например, при вопросе о бронировании оператору необязательно читать весь диалог. Достаточно увидеть: клиент хочет уточнить состав гостей и время. Это и есть практический смысл сохранения истории клиента между каналами — не переносить весь массив данных механически, а передавать смысл разговора.
После звонка результат возвращают в ту же историю. Если следующая коммуникация пройдёт в мессенджере, новый сотрудник должен видеть итог предыдущего контакта. Иначе омниканальность превращается в несколько очередей, связанных только названием компании.
Почему интеграция каналов с CRM не решает всё
Интеграция каналов коммуникации с CRM нужна, но сама по себе не создаёт единый клиентский путь. Она может передавать данные, но не определяет, какие именно данные важны, кто их проверяет и что делать с ошибками.
Полезно заранее описать маршрут обращения:
У каждого шага нужен владелец. Иначе карточка создаётся, но остаётся без ответа; звонок проходит, но его результат не фиксируют; сообщение отправляют, но никто не контролирует выполнение обещания.
Есть и менее очевидный риск: ошибочное объединение карточек. Нельзя автоматически склеивать обращения только по совпадению имени. Для сопоставления полезны телефон, подтверждённая почта, сведения из формы и данные диалога. Спорные случаи разумнее направлять на ручную проверку, чем показывать сотруднику историю другого человека.
Руководитель может проверить процесс без сложного аудита. Достаточно пройти несколько реальных маршрутов: написать в чат, оставить номер, принять звонок, продолжить общение в мессенджере. На каждом этапе нужно посмотреть, что увидит следующий сотрудник. Если он не понимает тему, ответственного и следующий шаг, проблема не решена — даже при работающих интеграциях.
Где здесь полезен ИИ, а где он не поможет
Специализированные ИИ-инструменты для голосовых и текстовых коммуникаций (такие решения предлагает, например, VoxWise) способны принять типовой вопрос, собрать недостающие сведения и подготовить краткое резюме для человека. В голосовом канале ИИ может определить тему обращения, зафиксировать базовые данные и передать разговор сотруднику. В чате — ответить по базе знаний и предложить удобный способ продолжения.
Но ИИ не исправит хаос в данных. Если в CRM нет понятных статусов, база знаний устарела, а правила передачи отсутствуют, автоматизация только быстрее размножит несогласованные действия.
Поэтому границы сценария важнее эффектной демонстрации. Нужно заранее определить, в каких случаях ИИ продолжает диалог сам, когда передаёт его человеку и какая информация уходит вместе с обращением. Сложные, нестандартные и значимые ситуации лучше направлять сотруднику с накопленным контекстом, а не пытаться любой ценой удержать их в автоматическом сценарии.
Что делать в первую очередь
Начинать стоит не со всех каналов сразу, а с одного частого перехода — например, из чата сайта во входящий или исходящий звонок.
Оценивать стоит не абстрактную «цифровизацию сервиса», а признаки управляемого процесса: есть ли в обращении тема, ответственный и следующий шаг; сколько карточек создаётся с дублями; как часто клиенту приходится повторять свой вопрос.
Омниканальность — это дисциплина сохранения смысла, а не витрина из чатов, телефонии и CRM. Чем больше каналов использует компания, тем важнее не дать каждому из них жить по собственным правилам.
Если клиент прямо сейчас сменит чат на звонок, сможет ли следующий сотрудник продолжить разговор — или начнёт его заново?