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

Разговор закончился, вопрос к сайту остался

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

Разберём обращения покупателей через Открытые линии Битрикс24, куда поступают диалоги из подключённых каналов. Причины будем записывать отдельно от статистики операторов. Количество реплик, разговоров и затруднений клиента различается: в одной переписке человек может сначала уточнить срок доставки, затем попросить изменить заказ и вернуться к оплате. Если считать каждую реплику самостоятельной проблемой, активный разговор получит больший вес, чем короткое сообщение о невозможности купить. Приоритеты тогда определит манера общения. Для смыслового разбора удобнее взять один диалог за одно обращение, а самостоятельные вопросы внутри него отмечать отдельно.

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

Я бы начала с законченных диалогов за выбранный период, а незавершённые вынесла в отдельную подборку: первые помогают уточнить причины, вторые показывают вопросы, с которыми компания ещё не разобралась. Такой порядок даёт материал для разметки и сохраняет нерешённые случаи на виду. Отбирать только жалобы неудачно. Спокойная просьба объяснить доставку тоже может указывать на пробел в информации, даже если человек не выразил недовольства. Причину и эмоциональную оценку хранят раздельно, чтобы улучшения сайта не зависели от того, насколько резко пишет покупатель.

Что на самом деле измеряет статистика диалогов

Большой поток в чате прежде всего говорит о нагрузке. Причину вопроса придётся выяснить по переписке. Аналитические отчёты по обращениям доступны не на всех тарифах, поэтому перед разбором уточняют доступность этой функции на портале. Сначала по справке статистики Битрикс24 стоит разобраться в отчётах по обращениям, каналам и операторам, чтобы выбрать нужный период и состав разговоров, а уже затем читать сообщения покупателей и записывать причины, которых статистика нагрузки не раскрывает.

Свою статистику легко спутать с тестовыми данными, которые включаются при первом входе. Раздел «Статистика диалогов» находится по пути CRM → Клиенты → Контакт-центр. Кнопка «Скрыть демо-представление» переключает его на сведения портала. Если пропустить это действие и сразу обсуждать график с руководителем, команда начнёт объяснять тестовые разговоры, хотя рассчитывала найти причины вопросов реальных покупателей. Период в отчёте выбирают тот же, за который читают обращения.

Закрытый как спам диалог исключается из статистики. Это правило нужно помнить при сверке отчёта со списком разговоров.

Ожидание покупателя нельзя без разбора записать в медлительность оператора. Показатель «Среднее время до ответа» идёт от первого сообщения до нажатия оператором кнопки «Ответить». Он включает нерабочие часы, как поясняет документация расчёта. Ночные обращения поэтому могут увеличить среднее, даже когда сотрудник взял разговор вскоре после начала смены. Для вопроса о расписании нужны часы поступления сообщений, а для оценки сотрудника — ожидание во время его работы. Разделить эти выводы полезнее, чем назначать всей команде новый норматив по одному среднему значению, в котором смешаны дневные и ночные разговоры.

Причины и исходы обращения

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

Основную причину выбирают одну. Вторую отмечают отдельно, если она потребовала самостоятельного ответа.

Это помогает считать обращения без двойного учёта, сохраняя возможность позднее разобрать связанные темы. Например, уточнение комплектации и вопрос об оплате могут возникнуть в одной переписке, но полезно выяснить, какое затруднение привело человека в поддержку и какие вопросы появились уже по ходу разговора. Для заранее заданных значений в карточке CRM подходит тип поля «Список». Документация пользовательских полей описывает и выбор нескольких значений. Исполнитель определяет, в каком элементе CRM хранить причины: поле в карточке не добавляет автоматически классификацию ко всем чатам.

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

Почему сначала стоит прочитать переписку

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

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

Совпавшие метки тоже стоит обсудить. Внутри слишком широкой рубрики могут совпасть вопросы с разными способами решения, и обсуждение исходных сообщений поможет заметить эту разницу.

В подборку включают разные каналы и исходы разговора. Только быстрые ответы дадут удобную, но неполную картину: за пределами разбора останутся обращения, переданные другому отделу или не получившие решения. После уточнения рубрик часть разметки можно поручить инструменту. Спорные сообщения оставляют человеку, а исходную переписку сохраняют как основание метки. Руководитель тогда сможет открыть вопрос, из которого появилась задача на улучшение, и понять, почему команда выбрала именно её.

Для обсуждения причин маркетологу достаточно обезличенного содержания вопроса, связанной страницы и последствия для покупки. Имена, телефоны и подробности заказа остаются нужны сотрудникам, которые отвечают клиенту. Вместо рассылки исходной выгрузки всему кругу участников полезнее подготовить выдержки без личных сведений: коллегам, которые меняют страницу, нужен вопрос покупателя и место его возникновения, а подробности заказа останутся доступны поддержке для продолжения разговора с клиентом. Рабочий документ лучше ограничить смыслом обращения, а разбор конкретного заказа оставить поддержке. Так сведения для аналитики не смешиваются с данными для обслуживания.

Сопоставьте вопросы с объёмом покупок

Число разговоров о доставке может вырасти вместе с заказами. Поддержке стало тяжелее, однако доля затруднений среди покупателей могла остаться прежней. Возможна и обратная картина: обращений меньше просто потому, что покупок меньше. Чтобы оценить правку сайта, полезно сопоставить обращения по выбранной теме с тем объёмом покупок или посещений, при котором эти вопросы могли возникнуть, и назвать основание сравнения в отчёте.

Сравнивайте периоды с одинаковым отбором и разметкой. Вопросы после покупки сопоставляют с заказами, а затруднения при выборе — с посещениями соответствующего раздела, если они измеряются. Знаменатель берут по смыслу причины. Самая большая цифра в отчёте может включать людей, которые вовсе не пользовались обсуждаемой частью сайта.

Для расчётной иллюстрации возьмём 20 обращений на 200 заказов и 30 обращений на 600 заказов. В первом случае получается 10 обращений на 100 заказов, во втором — 5. Это частота обращений, а не доля уникальных недовольных покупателей: один заказ мог породить несколько разговоров. При увеличении общего потока нагрузка выросла, но вопросы относительно числа заказов стали встречаться реже. Такой вывод точнее, чем оценка сервиса по абсолютному числу разговоров.

Вернувшийся клиент может обсуждать новую покупку. В Битрикс24 к повторным относятся обращения клиентов, которые уже есть в CRM, как поясняет справка о готовых отчётах, поэтому такую отметку полезно читать вместе с вопросом человека, прежде чем считать её признаком неудачного решения прежней проблемы. Для поиска повторения одной проблемы нужна связь по смыслу и конкретному заказу. Ещё один источник двойного счёта — передача диалога между операторами. В показателе «Количество всех обращений» один разговор учитывается несколько раз, если каждый из операторов ответил. Сумму по сотрудникам поэтому не стоит брать за число самостоятельных причин: сначала сверяют её со списком диалогов.

Какие причины превращать в задачи

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

Ответ иногда уже опубликован. Тогда новая страница только добавит ещё одно место, до которого покупатель может не дойти.

Из обращения получается задача, когда понятно, где человек остановился, чего ему не хватило и что он сможет сделать после изменения. Если вопрос о доставке возникает возле кнопки оформления, ответ полезнее показать там же, чем отправлять покупателя в общую справку внизу сайта, где он уже не нашёл нужную информацию. Но когда причина — задержка сборки на складе, работа с текстом решит лишь часть вопроса. Понадобится изменить обслуживание, а сайт сможет яснее сообщать о текущем состоянии заказа.

После правки команда возвращается к той же причине и прежним рубрикам. На нужном участке сайта оценивают обращения вместе с результатом действия. Исчезновение одной темы при росте другой может означать, что затруднение переместилось. Смена канала связи тоже меняет поток: человек мог перейти из чата в телефон. С аналитикой внутреннего поиска этот разбор связывают по конкретному вопросу покупателя, если сначала он искал ответ на сайте, а потом обратился в поддержку.

Из переписки — в задание на улучшение

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

Одна тема — одна первая задача. Совместная переделка нескольких участков затруднит оценку того, какой из них порождал вопросы.

Руководитель сможет включить улучшение в план, если маркетолог назовёт причину вопросов и ожидаемое действие покупателя, а исполнитель объяснит, какую часть сайта или обслуживания он изменит и по каким сведениям команда затем оценит, помогло ли это людям. Для приёмки заранее сохраняют вопросы до правки и описывают ожидаемый ответ сайта. Исполнитель показывает его в том месте, где покупатель выбирает или оформляет заказ. ШТАБ ИТ может связать этот учёт с настройкой Битрикс24 и доработкой сайта. Так обсуждение начинается с затруднения покупателя, а заканчивается способом увидеть, стало ли ему проще продолжить покупку.