Асинхронный сервис

Конец живой очереди

Обслуживание клиентов долгое время предполагало единый шаблон: живой, синхронный сеанс. Клиент звонит, ждет, соединяется, решает проблему — все это в одном непрерывном отрезке времени, иначе взаимодействие считается неудачным. Это предположение сейчас разрушается. Асинхронное обслуживание, построенное на постоянных каналах обмена сообщениями, заменяет живую очередь в качестве модели по умолчанию для поддержки клиентов.

Механика проста, но последствия — нет. Клиент отправляет сообщение компании о задержке заказа в 9 утра, закрывает приложение, занимается своими делами и получает решение в 3 часа дня в том же чате. Никакой музыки ожидания, никакой позиции в очереди, никакого номера обращения для цитирования, никакого повторения проблемы с нуля. Канал помнит, даже если клиент и агент отходят. WhatsApp Business и Apple Messages for Business сделали это обыденным, а не новым — разговор рассматривается как постоянный объект, к которому обе стороны могут вернуться, а не как живой звонок, который должен быть завершен или потерян.

Почему чат лучше звонка

Масштабы внедрения уже не являются незначительными. Meta сообщила в 2022 году, что более 175 миллионов человек ежедневно отправляют сообщения бизнес-аккаунтам в WhatsApp — цифра, которая свидетельствует о том, что сервис постоянного обмена сообщениями давно вышел за рамки пилотного статуса и стал основной инфраструктурой для значительной части отраслей, ориентированных на потребителя.

Примечательно не просто то, что клиенты массово обмениваются сообщениями с компаниями, а то, что сама очередь исчезает как концепция дизайна. Apple Messages for Business и WhatsApp Business API по умолчанию используют потоковые, постоянные беседы, а не живые очереди — клиенты видят историю чата, а не время ожидания. Это единственное изменение интерфейса незаметно устраняет психологические издержки ожидания, потому что ожидание больше не является видимым или синхронным. Не на что смотреть, нечего обновлять.

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

Перестройка бэкенда вокруг чатов

Поставщики контакт-центров — Zendesk, Salesforce, Twilio среди них — перестроили основные рабочие процессы вокруг цепочек сообщений, которые со временем направляются разным агентам, а не односессионным звонкам. Это более глубокий архитектурный сдвиг, чем кажется. Живой звонок требует одного агента, присутствующего на протяжении всего времени. Постоянная цепочка может передаваться между агентами, сменами и даже днями, при условии, что контекст передается вместе с ней. Это требует новой инфраструктуры: общей истории, видимых предыдущих обменов и логики маршрутизации, которая рассматривает разговор как непрерывную запись, а не как закрытое событие.

Именно поэтому сохранение контекста, а не скорость ответа, стало настоящим отличием. Поскольку цепочка сохраняет историю, клиенты терпят более длительные сроки решения — при условии, что им никогда не придется заново объяснять проблему с нуля. Скорость по-прежнему важна, но ее значение снизилось. Чего клиенты не потерпят, так это просьбы повторно изложить проблему, которую они уже описали, системе, которая, по-видимому, забыла о ее существовании.

Что меняется для клиентов и операций

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

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

В частности, для команд CX и операций это требует пересмотра метрик. Устаревшие показатели, такие как среднее время обработки и время до первого ответа, теряют большую часть своего значения, когда «звонок» больше не существует как дискретная единица. Операции должны перейти к отслеживанию разрешения на уровне цепочки — измерению того, была ли проблема фактически закрыта и сколько времени занял весь процесс, а не того, как быстро кто-то ответил.

Практический путь вперед

Этот шаблон уже актуален в розничной торговле и электронной коммерции, телекоммуникациях, банковском и финансовом секторах, туризме и гостиничном бизнесе, а также в логистике и доставке — везде, где большое количество несрочных запросов на обслуживание в настоящее время излишне засоряет живые каналы. Разумный шаг — внедрить его сейчас: пилотировать каналы постоянного обмена сообщениями именно для этих менее срочных, но объемных случаев и перестроить SLA вокруг окон разрешения, а не времени ответа. Организации, которые рассматривают это как простую смену канала, упустят суть. Те, кто рассматривает это как переосмысление того, что означает «разрешение», будут теми, с кем клиенты перестанут бояться связываться.