В своем предыдущем посте я рассказал о том, как мы справлялись с низким качеством сервиса в одном из сегментов нашего бизнеса. В этой статье я расскажу о том, как мы использовали аналитику и налаживали взаимодействие между разными командами, чтобы продолжить рост бизнеса в регионах и минимизировать пустые траты усилий и денег.
Проблема
Если вы технологическая компания, работающая на В2С рынке с миллионами клиентов, скорее всего у вас есть любимая «кнопка получения дополнительной выручки» - маркетинг. В случае с Деливери Клабом это точно было так, по крайней мере долгое время. Примерно полтора года назад, летом 2021 года, появилась задача ускорить рост, и привычным образом была нажата именно эта кнопка. Но в этот раз желаемый рост не произошел. Несмотря на заметные скидки и приток новых пользователей, эффект был несоизмеримым ни с запланированным, ни с прошлыми итерациями. Стало ясно, что сломано что-то внутри.
В то время в Деливери Клабе зарождалась практика «высадки руководства в поля». Она существует очень во многих технологических компаниях и не только в них. Это такой универсальный способ сделать так, чтобы руководители, находящиеся очень далеко от «земли», на эту землю спускались и смотрели на происходящее незамыленым взглядом. Столкнувшись с проблемой роста, было решено взять всю руководящую команду и отправить ее работать курьерами в один из проблемных городов на несколько дней. Назовем его для удобства город Анск.
Вести с полей и SWAT-команда
Когда речь идет о доставки еды или продуктов, которыми занимается Деливери Клаб, существует понятный рецепт успеха, понятный набор обстоятельств, наличие которых обеспечит появление заказа.
Во-первых, для возникновения заказа должны быть пользователи, открывающие приложение, а значит имеющие актуальную потребность, с которой у них Деливери Клаб (ДК) ассоциируется. Со временем такие актуальные потребности меняются, но чтобы был заказ, должна быть хотя бы одна потребность. Да причем такая, что заметное число людей с ней столкнувшихся сразу вспоминают ДК. Во-вторых, необходимо иметь среди ресторанов и магазинов, доступных для заказа, те, которые пользователи ассоциируют с удовлетворением своей потребности. Скажем, для тех, кто хочет себя побаловать, нужно иметь подключенные к ДК бургерные или суши-бары, из которых можно сделать заказ. А для тех, у кому предстоит отмечать свой день рождения с коллегами в офисе - заведения с пиццей или пирогами. В-третьих, пользователь должен легко найти в приложении именно то, что ему нужно. В-четвертых, он должен быть удовлетворен скоростью доставки и ее свойствами (например, что к нему приедут суши вместе с приборами и соусами). И, наконец, в-пятых, пользователь должен счесть для себя все предложение, найденное в ДК, выгодным или хотя бы приемлемым. И здесь я имею ввиду как цены в ресторане, так и разные скидки, так и стоимость доставки и размер сервисного сбора.
Иными словами, пять факторов:
Трафик,
Ассортимент,
Выбор и поиск,
Сервис,
Цены.
После нескольких изнурительных дней доставки заказов по жаре в городе Анске, наша управленческая команда четко определила тот фактор, с которым в Анске у Деливери Клаба были проблемы: ассортимент. Огромное число заведений, популярных в городе и доступных на той же Яндекс.Еде, не были подключены к ДК. И это с одной стороны означало, что сколько бы в приложение не нагонялось трафика, заказы не случались. А с другой стороны означало, что уровень сервиса часть был не высок. Ведь если в приложении мало ресторанов, то нужная пользователю пицца или бургер при прочих равных поедут не из ближайшего подходящего места, а из более далекого. А значит обещанное время доставки - важнейшая компонента уровня сервиса - будет большим. Чем больше обещанное время доставки, тем меньше шанс получить заказ.
Итак, есть задача кратно улучшить разнообразие ресторанов и магазинов, доступных для заказа в Анске. Чтобы решить такую задачу быстро, решили действовать по трем шагам.
Спарсили данные карт о существующих в городе заведениях и магазинах, их рейтинге и отзывах,
Дали нашему колл-центру задачу в приоритетном порядке прозвонить отсутствующие на ДК заведения и предложить им подключиться,
Создали небольшую команду продажников, которые должны были приехать в Анск после его обработки колл-центром и затащить на платформу недостающие хорошие заведения, физически прийдя в них и заключив договор на месте. Эта команда получила внутренние название «коммерческий SWAT», или же просто «SWAT».
В результате работы такого подхода удалось кратно вырастить объем заказов в Анске за 1.5-2 месяца. Признав подход успешным, решили распространить его и на другие города, где у нас было мало заказов или где была маленькая доля рынка.
Первые трудности SWAT - координация
После Анска, значительный рост заказов продемонстрировали и пара следующих за ними городов. Однако стали проглядываться проблемы координации между отделами.
Начиналось все с того, что коммерция приводила большое количество новых заведений на платформу. Заведения, как и пользователи, остаются на платформе не вечно - при отсутствии заказов они могу решить отключиться и перестать быть доступными для заказа на ДК. По данным ДК, чтобы снизить вероятность оттока ресторана до приемлемых значений и не считать работу коммерции сделанной впустую, нужно постараться сделать так, чтобы новый ресторан получил 10 заказов в свои первые 4 недели работы. С таким объемом ДК не станет для ресторана ключевым каналом продаж, но возникнет история заказов и отзывы, которые позволят ресторану получать трафик и заказы в дальнейшем.
По умолчанию, у ДК были специальные способы продвижения для новых ресторанов. На главном экране приложения существовала подборка «Новые», куда автоматически подтягивались все недавно подключившиеся места. Рестораны проводили в этой подборке первые 28 дней, и на все заказы, сделанные через эту подборку, Деливери Клаб давал скидку для пользователей за свой счет (обычно от 15 до 25 процентов).
После отработки первых городов SWATом, стало видно, что стандартных инструментов продвижения ресторанов часто недостаточно - многие недобирали те самые первые 10 заказов. Частично это было обусловлено самим проектом, так как при массовом заведении новых ресторанов на платформу подборка «Новые» начинала содержать десятки заведений. По сути, открыв подборку, пользователь видел вторую ленту на главном экране. И так же, как и в случае главной ленты, лишь 5% заказывали из ресторанов, шедших 20ми и больше по списку.
Увидев проблему, коммерческая команда обратилась за помощью к команде маркетинга - в ДК она заведовала как привлечением графика в приложение, так и скидками, купонами и подборками внутри. С перепугу решили дать залп из всех орудий: дополнительная закупка трафика, скидки до 30%, снижение минимальной стоимости доставки до нуля. К сожалению, операции, управляющие курьерами в городе, к такому готовы не были. Автоматические алгоритмы отреагировали повышением стоимости доставки - попытка отрезать поток заказов, падающий на ограниченное количество курьеров, чтобы не браться за те заказы, которые привезти вовремя скорее всего не получится. В результате наши клиенты могли видеть примерно такую картину:
Собранная корзина: 1000 рублей,
Скидка по промокоду: 200 рублей,
Сервисный сбор: 19 рублей,
Стоимость доставки: 350 рублей,
Итого: 1169 рублей.
Не сложно догадаться, что весь эффект скидки оказался перекрыт повышенной стоимостью доставки.
Мы собрали все команды вместе, провели разбор полетов и договорились об уточненном подходе. Теперь он выглядел так:
Команда развития вместе с коммерцией определяет последовательность городов в обработке, а также дату и длительность работы с каждым городом, учитываем оценку потенциала в городе и объем предстоящей работы (число новых заведений, которые хотим подключить),
Составляем график поддержки маркетингом, согласованный с графиком отработки городов коммерцией. «Врубаем» дополнительный трафик и скидки тогда, когда первое заметное число новых заведений появляется на площадке,
Составляем целевую траекторию роста числа заказов в городе (в результате расширения ассортимента и маркетинга) по неделям,
Планируем поэтапный найм и вывод на линию дополнительных курьеров командой операций, чтобы справиться с потоком заказов и не повышать стоимость доставки,
Раз в неделю проводим статусные встречи по текущим результатам, делимся с коллегами фактическими результатами и проблемами и корректируем действия с их учетом.
После первых 2-3 недель притирки, регулярные встречи стали происходить ритмично и конструктивно. Траектория роста в следующих городах улучшилась, и несколько месяцев проект существовал в таком режиме.
Неравномерный рост
Проведя около 10 городов по процессу, мы обнаружили, что нам не одинаково легко добиваться роста в разных городах. Были места, в которых все работало идеально: рестораны, трафик, заказы. Были же такие, в которых при том же наборе действий рост был не на 100-300%, а лишь на 50%. Что-то было не так. Вместе с командой аналитики мы снова полезли в детали.
Чтобы понять, почему рост случается в одних местах и не случается в других, мы решили изучить заведения, которые генерируют новые заказы. Очень простой анализ: берешь свежую когорту ресторанов, смотришь на число заказов, полученных каждым, и ищешь закономерности. Первые же итерации показали большую брешь в нашем процессе. Дело в том, что была совершенно конкретная категория заведений, которая стабильно получала мало заказов в ДК - кофейни. Просто ДК не ассоциировался у пользователей с кофе, и очень редко пользователи открывали приложение с кофе на уме. При этом мы ставили задачу команде коммерции в штуках ресторанов - в городе А добавьте 200, в городе Б - 300. А тот список, из которого команда выбирала заведения для подключения, показывал только то, было ли заведение хорошим судя по отзывам и рейтингу - тип кухни в списке не учитывался. В результате получилось, что до 50% новых подключенных заведений в городе могли оказаться кофейнями (особенно если в городе есть сеть кофе на вынос, и договорились сразу со всей сеть) и потому фактическое улучшение ассортимента было не таким значительным.
Кроме проблемы кофеен, стало видно еще одно обстоятельство. Даже не кофейни, а какие-нибудь обычные рестораны или пиццерии, в одном городе могли генерировать много новых заказов, а в другом - нет. Вплоть до того, что эти заведения принадлежали к одному бренду. Потратив несколько спринтов аналитики, мы сформулировали ряд закономерностей. Вот основные из них:
Все города можно условно поделить на 4 категории в зависимости от высокой или низкой доли рынка ДК в городе (в основном против Яндекс.Еды) и от высокой или низкой развитости города с точки зрения доставки еды в целом (суммарно клиенты ДК и Яндекс.Еды, деленные на население города; 8% - топ, 5% - сносно, меньше 5% - слабо развитая доставка в городе).
В зависимости от типа города (развитый и ДК сильный, развитый и ДК слабый, неразвитый и ДК слабый, неразвитый и ДК сильный), разные категории заведений обеспечивают рост. А значит задание для команды коммерции должно формироваться по-разному.
В неразвитых городах бесполезно подключать фешенебельные рестораны или что-то отличное от фастфуда, пиццы и суши. Как правило, у местных пользователей нет привычки заказывать еду, и они полагаются на два основных сценария: побаловать себя или заказать что-то по особому поводу. Поэтому костяком задания для коммерции в неразвитых городах должны быть фастфуд, пицца, суши и пироги.
В городах, где Яндекс сильней ДК, в первую очередь нужно добавить на платформу те же заведения, что уже есть в Яндекс.Еде. Слава богу, мы легко могли такие найти, соотнести их с кухнями и определить их рейтинг. Если рейтинг хороший, тип кухни подходит и заведение есть в Еде, в ДК оно скорее всего также будет успешным.
В городах, где ДК слабый, нужно отдавать приоритет тем районам города, где у ДК уже есть заказы. Иными словами, лучше разнообразить ассортимент там, где у нас уже есть клиенты, чем пытаться получить заказы из новых ресторанов там, где у ДК еще нет клиентов. Второе тоже работает, но хуже.
Если ДК в городе сильный, то все заведения (кроме кофеен) более-менее одинаково хорошо привлекают новые заказы. Можно подключать все хорошие не кофейни.
В неразвитых городах перфоманс маркетинга (рекламы в интернете) недостаточно - нужно «качать» город и традиционным маркетингом вроде телевидения и наружки.
Таким образом, третья версия проекта SWAT опиралась на еще более глубокую аналитику, учитывающую особенности городов и положения ДК в них. До самого начала интеграции с Яндексом, проект работал в ДК в таком виде и приносил десятки тысяч новых заказов в неделю.
Завершение «прокачки»
На время «прокачки» города мы сознательно ухудшали юнит-экономику в нем. Мы осознанно меняли заработок на рост, но в конце концов хотели получить больше заказов с той же или лучшей экономикой. Поэтому после 3-4 месяцев от начала «прокачки» мы постепенно начинали уменьшать скидки и повышать стоимость доставки до нормальных уровней (вроде 50 рублей при заказе до 700 рублей, далее бесплатно). Это тоже был нетривиальный процесс. Например, мы заметили, что после «прокачки» наши города выглядели очень по-разному с точки зрения сегментов ресторанов, обеспечивающих заказы. В некоторых городах существенная часть дополнительного роста приходилась на фастфуд, и в них выходить на хорошую экономику было трудно: чеки там обычно меньше, а значит повышение стоимости доставки / снижение скидок на те же 100 рублей выглядят более внушительно на фоне чека. В этом случае мы старались работать над плотностью и уровнем сервиса. Делали так, чтобы точек возникновения заказов на карте было по-больше, например подключаем к ДК местные сети магазинов. Так мы при прочих равных мы снижали порожний пробег курьеров, а значит и выплаты за него. Кроме того, мы старались наращивать долю заказов, которые курьер нес в паре с другим заказом - батчинга. Такие заказы более выгодные, но страдает время доставки.