Hi-Tech

Однажды в такси: три истории, которые могли стоить «Яндекс.Такси» бизнеса, но привели к его бурному росту

Публикуем сокращенную версию доклада Даниила Шулейко. Что стоит за бурным ростом, как технологии помогают в условиях дефицита ресурсов и почему «сделал — сразу кати в прод» на самом деле самая правильная стратегия.

Они случились в разное время, и «Яндекс.Такси» каждый раз была разной компанией, на разных этапах переживало разные проблемы. Три истории, про которые я расскажу, произошли с «Яндекс.Такси» за последние полтора-два года.

Первая история — за спрос деньги берут

Когда-то давным-давно в СССР банка красной икры стоила примерно 3 рубля. Первая история про капитализм. Проблема в том, что икра была сумасшедшим дефицитом, ее невозможно было пойти и купить в магазине — только если улыбнулась удача или по блату. Ее мог себе позволить, пусть и на праздники, практически каждый советский инженер.

Вот, например, обычное утро обычного буднего дня в Москве. Такси раньше тоже было примерно такой банкой икры, особенно в час пик.

Примерно в 7:30 утра спрос начинает активно расти. Этот график иллюстрирует спрос на поездки. Самый армагеддон приходится на 8:40, потому что, как правило, мы заказываем такси к самому началу рабочего дня, а в Москве как раз средняя поездка занимает по длительности 15-20 минут. Девять утра — самое частое время начала рабочего дня в Москве, это подтверждают и наши исследования. Проблема в том, что хотя многие водители и выходят работать примерно по такому же графику, в час пик их всё равно не хватает, чтобы обслужить все заказы.

А так выглядит спрос, когда в Москве идет дождь — цвет каждого полигона означает спрос: от зеленого (спрос обычный) до красного (спрос в несколько раз выше, чем обычно в это время в этом районе).

Если кто-то знает, как за несколько минут сделать, чтобы в этот же самый момент к системе подключилось в четыре раза больше водителей — приходите работать в «Яндекс.Такси». Как только начинается дождь, спрос за несколько минут вырастает примерно в четыре раза — люди хотят доехать «от двери до двери».

Таким было приложение «Яндекс.Такси» раньше.

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

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

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

А теперь история о том, как мы вводили этот повышающий коэффициент.

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

Была критика на удорожание поездок, но в целом сервис решал свою задачу: находить свободную машину в любое время и в любом месте. Так было до того, когда мы внедрили повышающие коэффициенты. Мы внедрили, и с нашими когортами случилось примерно следующее (график ниже).

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

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

Мораль этой истории для меня такая: идея всегда важнее графиков.

Но руководствуясь только данными, мы бы все отменили. Маркетологи и growth-хакеры говорят: «верьте данным». Я считаю, что всегда верить данным нельзя: правильная и прорывная идея далеко не всегда сразу подтверждается хорошими показателями. По показателям все стало хуже, люди перестают пользоваться сервисом, потому что у него цены меняются и «вообще очень дорого».

Вторая история — про «вопрос жизни и смерти»

Представьте себе овощной рынок, где нет табличек с ценами. Эта история еще про один из случаев, когда мы чуть не потеряли бизнес. Можно, конечно, не покупать и отказаться, но вы уже выбрали и взвесили. Выбираете, взвешиваете, а цена в итоге совсем не та, на которую вы рассчитывали.

Цена была показана только приблизительная, не факт, что она такой будет в конце поездки, потому что водитель, например, попал в пробку или решил ее объехать по более длинному маршруту. В приложении «Яндекс.Такси» раньше тоже было похожим образом.

Год назад мы стали показывать окончательную стоимость поездки перед заказом — когда известна начальная и конечная точки маршрута.

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

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

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

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

Вот так стал выглядеть «колокол» — ключевой для нашего бизнеса график, где видны отклонения при прогнозе цены.

Мы написали большой рассказ для разработчиков и аналитиков про то, как делали эту фичу, если интересно — можно почитать на «Хабре». Алгоритм расчета удалось сделать очень точным, при том, что нам надо учитывать десятки факторов и уметь считать с большой скоростью в реальном времени, чтобы не страдал UX.

Почему выиграли и водители? Можно предположить, что от такого новшества выиграли только пользователи, но на самом деле не только они. Вот график, важный для водителей:

Это доля времени в каждом часе, в течение которого водитель едет со своим пассажиром, а не ждет заказ, не ожидает клиента и не едет к нему, чтобы забрать. По оси Y один из самых важных показателей — мы его называем «эффективность». У онлайн-сервисов эффективность составляет от 45 до 60% за счет «умного» распределения заказов и большой плотности пользователей и водителей в системе одновременно. То есть, это время чистого заработка.

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

Иначе есть большой риск стать догоняющим, а не пионером. Мораль у этой истории для нас стала такой: если нашли супер-важное продуктовое свойство для бизнеса, то как бы тяжело, сложно и страшно ни было, нужно брать и сразу делать.

История третья — про ограничение ресурсов, которое творит чудеса

И это очень важная часть качества сервиса. Для того, чтобы оперативно решать вопросы пользователей и водителей, у нас есть служба поддержки. Хотя доля заказов, по которым нужно какое-либо вмешательство службы, меньше 1%. Чем больше поездок заказывается через сервис, тем больше обращений.

Я сказал, что он может рассчитывать только на половину, и благополучно про это забыл. Примерно полтора года назад, когда мы росли в 4-5 раза в год по поездкам, ко мне пришел руководитель службы поддержки с бюджетом на персонал и сказал, если мы будем расти так и дальше, то до конца года необходимо нанять в отдел несколько сотен человек, чтобы держать уровень качества.

А Паша (Павел Бывших — руководитель службы поддержки «Яндекс.Такси») не забыл и ушел думать, как сделать так, чтобы часть работы переложить на алгоритмы, машинное обучение и другие технологии, которые есть у «Яндекса».

Нужно сказать, что задача это нетривиальная, потому что большинство отзывов о проблемных поездках через приложение люди оставляют вот так:

То есть не детализирует, что именно не понравилось и в чем была проблема.

Например, версия ОС в телефоне (это может влиять на «чистоту» GPS-сигнала); была ли поездка до заказа дольше, чем планировалось; или пользователь долго выходил к такси и поэтому ему начислена дополнительная сумма за ожидание. В саппорт такой отзыв попадает с большим количеством мета-данных о поездке, которые формируются автоматически. Вся эта информация дает нам возможность проанализировать, что именно было не так.

Для того чтобы быстрее и точнее обрабатывать такие отзывы мы написали алгоритм, который автоматически раскладывает все обращения (тикеты) на четыре типичных сценария.

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

Это, к слову, наиболее массовый стрим — так отрабатывается наибольшее количество тикетов. В стандартной ситуации — менеджер службы поддержки действует по шаблону для самых частых ситуаций или вопросов от пользователей или водителей (например, объясняет, как работает повышающий коэффициент, про который я только что рассказал).

Наконец, важное — это случаи, требующие отдельной проверки и разбирательства.

Однако отзывы и комментарии нам присылают не только из меню приложений «Яндекс.Такси» или «Таксометра», но и по электронной почте, по телефону, публикуют в социальных сетях. Раньше такую сортировку выполняли люди, теперь это делает алгоритм на основе machine learning, который постоянно обучается. И у таких отзывов нет всех мета-данных, по которым мы можем разобраться в ситуации.

Мы вручную разметили более 50 тыс. Поэтому следующим шагом стало внедрение системы семантического анализа всех входящих сообщений (в случае с call-центром это данные по итогам звонка, которые фиксируют в нашей внутренней системе операторы). Система довольно точная: всего в 2% случаев она ошибается. текстовых обращений и с помощью машинного обучения научили алгоритм анализировать семантику и автоматически разносить тикеты в разные очереди.

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

А штат «Яндекс.Такси», наверное, на 70% состоял бы из службы поддержки, опять же, просто потому, что на таком объеме поездок даже при низком проценте проблемных заказов в абсолютных значениях их всё же довольно много. У этой истории следующий вывод: если бы мы не ушли от масштабируемого найма сотрудников в саппорт и не начали бы оптимизировать систему поддержки с помощью технологий, обработка одного обращения сейчас для нас стоила бы примерно в 8 раз дороже, чем она стоит по факту. Нам пришлось спровоцировать резкую нехватку кадровых ресурсов, и это стимулировало команду быстро принимать меры и искать пути выхода.

Больше историй по маркетингу продуктов в Telegram-канале @epicgrowth.

#маркетинг

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»