Архив недели
Понедельник
Привет! 👋🏻
Я Женя Миляева, продакт менеджер клиентского сервиса в Dostavista.
Буду рассказывать про продуктовый подход к клиентскому сервису, о своих победах и провалах, о том, почему вообще важен саппорт и о том, возможно ли превратить его из коста в драйвер роста.
Идеальный саппорт - тот, которого нет. То есть когда в сервисе все гладко на протяжении всего пути пользователя, на каждом шаге все понятно, не бывает багов и пользователи всегда довольны качеством оказанных услуг. Но все мы знаем, что идеала не существует 🙃
Сколько раз за последнюю неделю вы обращались с службу поддержки какого-либо сервиса или сервисов?
🤔
54.3% 0🤔
37.4% 1-2🤔
8.2% 3+При средней з.п. оператора в 40 000 р., вы будете тратить 800 000 р. в месяц на поддержку без учета стоимости софта, HR, обучения, аренды и прочих расходов. Прибавьте все это и смело умножайте сумму на два, а то и на три. Возьмём 2 млн р.
Если у вас 100000 активных пользователей и хотя бы 1% обращается в поддержку, это 1000 тикетов в день. При средней скорости решения вопроса 10 минут, всем ответить у одного оператора займет 7 дней, поэтому вам надо 20 операторов.
Допустим, с каждого пользователя в месяц вы зарабатываете 500 р. 20 из них уйдут на саппорт. После вычета маркетинговых и административных расходов, хорошо, если вообще что-то остается и компания прибыльна. Если нет, саппорт первый в очереди на оптимизацию костов. Да и если да.
Завтра подробно расскажу, чем я руководствовалась при принятии решений.
Тем временем, что бы вы сделали в первую очередь?
Если выбрали «Другое», пишите ваш вариант в комментариях.
🤔
43.8% Убрать телефон, chat only🤔
36.2% Chat only for logged-in u🤔
5.7% Запрятать «Поддержка»🤔
14.3% ДругоеНо какие меры самые эффективные с точки зрения клиента? Как оптимизировать косты без потери клиентского опыта?
Важно понимать, зачем и когда пользователь обращается в поддержку, и какую ценность или боль несёт в себе это соприкосновение как для пользователя, так и для бизнеса.
Если подходить к проблеме саппорта с операционной стороны, существует ряд очевидных мер, которые точно сократят количество тикетов, например
- ввести чат вместо телефона
- показывать чат только авторизованным пользователям
- спрятать кнопку «Поддержка» за тридевять шагов
и др.
Тред #1
Вторник
Все опции по отдельности - валидные, однако, чтобы сделать верный выбор, важно понимать особенности конкретно вашего бизнеса и его цели, а также ожидания и боли именно ваших пользователей.
По результатам опросов вчера:
- 46% респондентов обращались в поддержку за прошедшую неделю хотя бы раз
- большинство выбрало сделать чат-поддержку вместо телефона и скрыть чат от неавторизованных пользователей.
Несколько человек выбрали «Другое» и предложили свой вариант.
Возьмём ИКЕА. Фишка Икеи - self-service. Сам проектируешь кухню в конструкторе, сам собираешь товары с полок на складе, сам собираешь мебель. В случае вопросов ответ искать будешь тоже сам в отлично проработанной базе знаний с видео инструкциями.
Этот вариант абсолютно верно предложил @fat_piglet, но он подходит для сервисов, где длинный цикл заказа и нет ожиданий по скорости.
И это ок, пользователи не будут кипеть от гнева потому что их ожидания выстроены самим продуктом - доступная мебель и self-service.
Да, с человеком поговорить в поддержке ИКЕА тоже можно, но все сделано для того, чтобы пользователь сначала максимально самостоятельно нашёл ответ. При этом поддержка будет отвечать долго, а если ты закроешь страницу, то и чат закроется и придётся начинать заново.
Итак, для выбора канала поддержки и целевых значений метрик саппорта важно понимать особенности бизнеса, ожидания и боли конкретно ваших пользователей. Для этого необходимо на регулярной основе анализировать обращения в поддержку, что верно отметил вчера @MNZakharov.
Если пользователь не может решить свой вопрос в интерфейсе самостоятельно, он ожидает, что поддержка ответит быстро и оперативно решит вопрос, ведь не зря он 169 р. отдал за доставку.
Возьмём сервис с коротким циклом заказа, фишка которого - скорость. Например, сервис доставки еды. Ожидания совсем другие и будет странно, если на вопрос «А как пометить, чтобы блюдо сделали не острым?» пользователю предложат написать имейл в ресторан или прочитать ряд статей.
Про методологию анализа расскажу сегодня вечером и приведу несколько конкретных кейсов из Достависты.
Тред #2
Тем временем прокомментирую опции из опроса вчера:
- поддержка chat vs. phone.
1 оператор может вести параллельно 10 чатов, тогда как быть на линии только с 1 пользователем. В чате оператор может в один клик отправлять шаблоны, по телефону же надо вслух говорить каждое слово.
- чат только для авторизованных пользователей
Во-первых, надо понимать долю чатов от неавторизованных пользователей. Во-вторых, знать суть этих обращений и определить их ценность для бизнеса.
Самому пользователю тоже удобнее закинуть сообщение в чат и заниматься дальше своими делами, чем висеть на линии.
Есть одно условие: время ответа в чате должно быть минимальным. Если пользователь не получает ответ в течение 5-10 минут, он переживает и начинает искать телефон.
В Достависте чаты от неавторизованных пользователей составляют до 10% и большая часть этих чатов - от потенциальных клиентов и лидов, которые хотят узнать цены и условия. Скрыв чат от них, мы уменьшим нагрузку на саппорт на 10%, но потеряем намного больше на acquisition и LTV.
- запрятать «Поддержка» за тридевять кликов
Этим вы не сделаете лучше ни себе, ни пользователю. Если он хочет задать вопрос, он столкнулся с какой-то проблемой. Если поддержку не оказать, пользователь просто не оформит заказ или отменит его или не воспользуется сервисом вновь.
Особо пытливые все же найдут связь с поддержкой и к этому моменту их обращение с высокой долей вероятности приобретёт негативный оттенок, даже если изначально таким не было. Service, support - от слова служить и поддерживать. Запрятать путь к поддержке противоречит самой ее сути.
Тред #3
Поговорим о способах анализа тем обращений. Пока я пишу лонгрид-мегатред, опрос:
Как вы анализируете темы обращений в вашем сервисе? Для опции «Другое» не хватило места, но смело пишите в ответных твитах ваш вариант.
🤔
42.2% Теги🤔
9.6% ML🤔
33.7% Вручную🤔
14.5% НикакПервая опция - проставление тега, или выбор темы обращения во время закрытия чата.
Как правило, тег ставится вручную. Некоторые платформы, например Intercom, позволяют настраивать правила для автоматического тегирования.
Далее перед вами стоит задача настроить правила автоматического тегирования по ключевому слову и научить всех операторов одинаково использовать теги.
Начнём с автоматизации. Представим, вы хотите настроить правило для тега «Вопрос по ценам и услугам». Оно будет звучать так:
Вы формируете список из 5-10 тегов или тем. Например, на примере сервиса доставки:
- вопрос по ценам и услугам
- вопрос по ЛК
- оформление заказа
- редактирование
- опоздание курьера
- дополнительные услуги
- отмена
- компенсация
- жалоба
- другое
«Почему изменилась цена заказа?» - тег будет присвоен неверно.
«Сколько стоит отправить по Москве?» - верный тег не будет присвоен.
ЕСЛИ сообщение содержит «цена», «цену», «стоимость», ТО присвоить тег «Вопрос по ценам и услугам».
НО ключевые слова могут использоваться в других контекстах и темах. Их невозможно предвидеть каждый до последнего, также как и все формулировки, которые клиент может использовать.
Так, настроить автоматические теги можно и правила будут работать верно в большинстве случаев, что несколько сократит нагрузку на саппорт, но операторы все равно должны перепроверять теги в каждом чате и, если необходимо, удалять неверный тег и ставить верный вручную.
Что бы вы ни выбрали, задача научить этому алгоритму всех операторов все равно остается. На 300 операторов точно будут субъективные отклонения от общей логики. Что для одного - просто вопрос, для другого - жалоба, и т.д.
Отсюда следующий челлендж: обучить всех операторов использовать теги одинаково. Представим вопрос «Как добавить в заказ дополнительную услугу - выкуп товара?».
Это
🤔
10.0% Вопрос про цены и услуги🤔
10.0% Редактирование🤔
35.0% Дополнительные услуги🤔
45.0% Все вышеперечисленноеС оплатой наличными или по карте? Редактирование адреса или времени или других полей?
Что нужно пользователям? Почему они пишут в саппорт? Они не знают, что могут редактировать сами, или у них не получается?
Помимо точности их применения, проблема ещё в их информативности. Когда в сервисе много разных продуктов, платформ, типов оплат и тд, тег «Редактирование» сам по себе ни о чем не говорит. Редактирование с веба или из приложения? Только что оформленного или уже активного заказа?
А если ваш сервис работает в разных странах, как Достависта, то добавьте к этому географию по всему миру от Бразилии до Индии до Филиппин, языковые и культурные различия.
В общем, я на теги не полагаюсь. Была идея научиться тегировать при помощи ML, но за те годы что задача с огромным effort и небольшим impact в бэклоге, я научилась эффективно и быстро анализировать чаты руками.
Для продуктовых инсайтов нужен намного более подробный список тегов, в котором будут перемножаться тема вопроса, product area, customer journey step и другие категории. Настроить такую систему тегов или обучить операторов почти невозможно. Если у кого-то получилось, расскажите!
Так я узнала, например, что в Индии вопрос «Courier phone number?” пользователи спрашивали сразу после размещения заказа - до назначения курьера - и им было непонятно, что телефон появится в заказе после назначения курьера.
Алгоритм такой: беру 200-300-400 чатов подряд, пробегаю каждый взглядом и выписываете в столбцы нужные параметры: category, product, source и тд. Я обязательно копирую конкретный вопрос пользователя его словами, цитатой.
Аналогично с вопросом «Where is the courier?”, который писали также сразу после создания заказа - он не про местонахождение курьера, а про то, что пользователю непонятно, какие следующие шаги и что курьер будет назначен в течение нескольких минут.
Я также заметила, что 50% чатов в Индии - от пользователей, разместивших 1й заказ. А еще они почему-то спрашивали «How can I pay the courier?”, только ли наличными или можно по PayTM.
По итогам анализа я создала бота, который отправляется всем новым пользователям после создания первого заказа. Бот отвечает на частозадаваемые вопросы и использует формулировки, понятные пользователям.
В результате мы улучшили клиентский опыт во время первого заказа и сократили обращения в саппорт на 15%.
Но ещё более показательный кейс анализа чатов и последующего внедрения ботов - про Филиппины. Рассказать?
🤔
92.3% 👍🤔
7.7% 👎Тред #4
Среда
Ой, устала я сегодня, нет сил ничего рассказывать. А как ваш день? Работаете на майских?
Расскажите лучше что-нибудь вы. Например, как вы приоритезируете задачи?
Если «Другое», напишите ваш вариант. И в любом случае, расскажите, с какими проблемами сталкиваетесь в приоритизации?
🤔
51.5% RICE🤔
4.5% KANO🤔
16.7% MoSCoW🤔
27.3% ДругоеЧетверг
Мы в Достависте используем RICE, как и половина опрошенных. Мне нравится методология, но есть ряд сложностей. Разберём на примере.
Допустим, мы придумали решение, запрещающее создавать дубль заказа, пока на него не назначен курьер. После того как курьер назначен, можно создать такой же заказ.
Итак, считаем RICE.
Почему это плохо:
Список заказов зафлуден дублями, курьеры тратят время на изучение деталей и отклики на дубли, это негативно сказывается на времени назначения на реальные заказы.
Высокий % отмен.
Проблема: пользователи создают заказы-дубли, ошибочно думая, что так курьер найдётся быстрее. Пользователь создаёт 10 одинаковых заказов и после назначения курьера на 1 отменяет остальные 9. При этом иногда реально есть необходимость создать два одинаковых заказа, совпадение.
Кстати, прямо сейчас у нас открыта вакансия аналитика в клиентскую команду - именно на такие задачи. Мы тебя ждём! hh.ru/vacancy/420828…
Я пыталась, тщетно, а потом оказалось, что это задание уровня тестового для крутанов-аналитиков. Куда там мне со своими базовыми знаниями SQL.
Раз сама посчитать не могу, ставлю задачу на аналитиков и жду очереди. Аналитиков всегда мало, а работы у них много, поэтому жду долго.
Можете написать SQL запрос, чтобы определить WAU разместивших дубли?
Дублями считаем заказы одного клиента
- где полностью совпадают адреса на всех точках в заказе
- которые одновременно были в статусе «поиск курьера»
- которые были отменены все кроме 1
🤔
25.0% Легко 👌🤔
43.8% Займет пару часов 🤔🤔
31.2% Эмм, нет 🙄Это будет low, medium or high impact? Любое ли изменение можно посчитать в деньгах? А если меняется чисто дизайн?
Далее - impact. На сколько мы улучшим время назначения на реальные заказы, если в списке заказов не будет дублей? Сколько нам даст это в revenue?
🤔
42.1% Я знаю, как посчитать🤔
57.9% ХзТем временем, я хочу подтянуть SQL, чтобы считать все по максимуму самостоятельно и быстро. Посоветуйте, пожалуйста, курсы и ресурсы 🙏🏻
В общем, вопросов много, а еще такой же челлендж как и в истории с тегами и операторами: научить всех продактов и заказчиков по всему миру считать RICE одинаково, использовать одну логику.
Confidence - мое любимое. Максимально субъективный вброс в общий RICE score.
Тред #5
Суббота
Сегодня поговорим про метрики клиентского сервиса и как мы их считаем (или нет) в Достависте. В программе:
NPS
CES
CSAT
FRT
FCR
Chats per order
Automation rate
Что лучше, NPS или CES?
🤔
13.6% NPS🤔
16.9% CES🤔
69.5% Я не знаю, что такое CESВ самой постановке вопроса NPS мне не нравится его гипотетичность «какова вероятность..». Это как если на кастдевах спрашивать «Вы бы купили наш продукт?». Действия может не произойти, даже если вероятность высокая, и наоборот - вдруг произойти несмотря на низкую вероятность.
В 2010 году HBR опубликовал результаты опроса 75000 клиентов, заключая, что
восхищение клиентов не создает лояльность, а вот уменьшение усилий, которые они должны затратить для решения проблемы, коррелирует с лояльностью.
hbr.org/amp/2010/07/st…
NPS - net promoter score. “Какова вероятность того, что вы порекомендуете наш сервис своим друзьям, знакомым или коллегам?»
CES - customer effort score. “Насколько легко было воспользоваться нашим сервисом?»
В обоих случаях затем следует открытый вопрос «Почему?».
Давайте на конкретном примере.
Вспомните самый лучший ресторан, в котором вы были за последний год? В котором все - кухня, интерьер, обслуживание - было идеально.
Сколько раз вы рекомендовали его друзьям?
А сколько раз вы были в нем с тех пор сами?
Вопрос CES же про конкретный фактический опыт пользователя.
В этом разница NPS и CES. Что теперь вам кажется лучше?
🤔
19.2% NPS🤔
80.8% CESТак или иначе, мы в Достависте не измеряем на регулярной основе ни то, ни другое. Измеряем в рамках отдельных research проектов, и самое важное в этих метриках - не сама оценка, а ответы на вопрос «Почему?».
На постоянной основе мы измеряем CSAT: оценка заказа и оценка чата.
По окончании заказа мы предлагаем оценить курьера от 1 до 5 звёздочек.
По завершении чата мы предлагаем оценить оператора от «Ужасно» до «Отлично». Это нативная фича Интеркома, которая звучит дословно «Помогите понять, как [имя оператора] справляется».
Мы вычитываем все негативные оценки и комментарии, чтобы исключить несправедливое ухудшение рейтинга.
Что с этим сделать? Принять, полюбить и настроить систему фильтрации оценок, если на рейтинг завязаны KPI операторов и курьеров.
В обоих случаях есть одна проблема. Клиенты часто дают оценку не курьеру или оператору, а сервису в целом. Например, курьер опаздывает и клиент жалуется в чат. Как бы вежлив не был оператор, клиент все равно может поставить «Ужасно» и написать «Ужасный сервис» в комментарии.
Вообще негативную обратную связь - самая ценная. Ее надо не бояться и всячески приветствовать, давать клиенту всевозможные способы ее оставить в вашем сервисе, а не elsewhere. В ней самые полезные инсайты и особенно продакты должны ее жаждать и жадно читать.
Тред #6
FRT - first response time, время первого ответа. Согласитесь, неприятно, когда вы сообщили о проблеме, а поддержка долго молчит. Но что такое долго? Как же выбрать целевое значение метрики?
Хорошее время первого ответа это
🤔
13.4% 1 ч🤔
20.7% 20 мин🤔
37.6% 5 мин🤔
28.3% 1 минВоскресенье
Как вчера верно написали @egorka, @fat_piglet и @barn4k, целевое значение времени первого ответа зависит от сути бизнеса, канала связи и главное - ожиданий пользователей. Самое главное, на мой взгляд, подчеркнул @shaukote: важно отвечать не только быстро, но и качественно.
Решение вопроса.
Клиент:
- Не могу добавить адрес в заказе 12345. Нужен возврат на Ленина, 42.
Оператор (первый ответ в течение 2 минут):
- Я внёс изменения в заказ. Могу ещё чем-то помочь?
Я определила качественный первый ответ как тот, который содержит
- решение вопроса, или
- уточнение информации, или
- обозначение времени требуемого для решения вопроса.
Рассмотрим на примерах.
Когда-то в Достависте FRT был 20 секунд и достигался за счёт ответа шаблоном «Здравствуйте! 1 минуту, пожалуйста». При этом CSAT был 86%.
Я предположила, что клиенты готовы ждать до 2 минут при условии что затем последует качественный ответ.
Обозначение времени, требуемого для решения вопроса
К: Не могу добавить адрес в заказе 12345. Нужен возврат на Ленина, 42. А еще [вопрос 2], и ещё кстати [вопрос 3].
О: Мне потребуется 10 минут, чтобы ознакомиться с вашими заказами и вернуться с ответом.
Уточнение информации
К: Не могу добавить адрес в заказе.
О: В каком именно из активных заказов и какой адрес необходимо добавить?
Это говорит о том, что WOW-effect от супер быстрого ответа за несколько секунд впоследствии как минимум нейтрализуется, если не обращается в негатив, если затем следует ожидание и долгое решение вопроса.
В течение 3 недель на выделенной группе клиентов операторы давали первый ответ согласно этим условиям в течение 2 минут.
В результате время ответа в тестовой группе, очевидно, выросло, но вырос и CSAT с 86% до 91%.
Решает FCR - first contact resolution - когда вопрос пользователя решается в первом ответе, как в примере выше.
Здесь важно помочь пользователю предоставить всю необходимую информацию в своем вопросе, например, при помощи бота, чтобы оператору не нужно ничего уточнять в ответ.
Тред #7
При этом есть чаты, в которых оператор не участвовал - в них участвовал только бот.
% чатов, закрытых ботом без участия оператора и есть automation rate.
Chats per order.
Если вы хотите, чтобы ваш бизнес рос, а обращения в саппорт - падали, это одна из ваших ключевых метрик клиентского сервиса.
Ее я считаю как все чаты, в которых участвовал оператор, делённые на все созданные заказы в этом же периоде.
Мы используем обычные кнопочные боты, доступные в Intercom: пользователь нажимает «Отправить сообщение», бот показывает кнопки с популярными вопросами и при нажатии дает готовый ответ и две опции: «Назад» или «Нужна помощь оператора».
Не все пользователи одинаковые. Информация про регистрацию нужна новому пользователю и не нужна старому; пользователям с веба не нужна информация, касающаяся приложений и т.д. Уместить все в один универсальный бот физически можно, но это сделает его максимально не user-friendly.
Если пользователь нажал на «Отправить сообщение» и не нажал на «Нужна помощь оператора», мы считаем, что пользователь нашёл ответ в информации, предоставленной ботом.
Я запустила их в работу в ряде стран в начале Q2 2020. Рассмотрим результаты на примере Филиппин. Мы мы достигли automation rate 55%, то есть более половины чатов, начатых пользователями, закрывались полностью ботами. Chats per order упал с 0.23 до 0.05.
Я проанализировала обращения в зависимости от типа пользователя и его шага в пути продукта и построила систему ботов с основными 4:
- unauthorised web visitors
- unauthorised app users
- authorised users with 0 orders
- authorised users with 1+ orders
Это совпало с экспоненциальным ростом заказов в Филиппинах, где пандемия вызвала рост доставок. Если бы мы не запустили этих ботов, там потребовалось бы 40 операторов в месяц вместо 7. Так, мы сэкономили порядка $12000/mo только лишь в Филиппинах без ухудшения клиентского опыта.
А вы используете ботов в поддержке?
🤔
29.0% Да, кнопочные🤔
16.1% Да, ML🤔
54.8% НетТред #8
Так, все, что обещала рассказать - рассказала.
Забавно, конечно. В пн утром меня буквально накрывал ужас и я не знала, о чем писать. Сейчас же сожалею, что столько всего ещё не успела! Хочется писать обо всем: и про клиентский сервис, и про продукт, и про компанию и процессы.
С вами была я, Женя Миляева, продакт менеджер клиентского сервиса в Dostavista. Давайте дружить и оставаться на связи:
fb.com/jane.milyaeva
Всем спасибо! Будьте счастливы и любите ваших пользователей ✨
Как говорил мой первый руководитель в Достависте Саша Шамис в моменты, когда меня накрывал страх и я прокрастинировала, «Женя, просто начни».
И работает же!
Если вы ещё не делитесь своими знаниями и опытом, этот тот самый знак, чтобы начать :)
