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

На конференции Epic Growth Conference выступил управляющий директор «Яндекс.Такси» Даниил Шулейко и рассказал о ситуациях, когда бизнес был на грани.

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

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

Первая история про капитализм. Когда-то давным-давно в СССР банка красной икры стоила примерно 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, который постоянно обучается. Однако отзывы и комментарии нам присылают не только из меню приложений «Яндекс.Такси» или «Таксометра», но и по электронной почте, по телефону, публикуют в социальных сетях. И у таких отзывов нет всех мета-данных, по которым мы можем разобраться в ситуации.

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

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

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

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

#маркетинг