Про рынок доставки еды и откуда у агрегаторов курьеры.
Агрегаторы вроде Деливери Клаба (ДК) и Яндекс.Еды (ЯЕ) не придумали доставку еды. Задолго до их появления существовали и рестораны, и курьеры. Именно поэтому в первые годы развития фудтеха доминировала модель маркетплейса. Фактически, фудтех компании решали задачу поиска ресторанов с доставкой и выбора, и на первых порах этого хватало. Возникли сайты и приложения с заметной аудиторией, фудтехи заключили контракты с тысячами ресторанов и стали работать — причем, преимущественно в плюс. Оно и понятно — расходов не много (только маркетинг, продукт и общие административные, никакой операционки), доходов — много (рестораны с хорошими чеками плюс комиссия в десяток-два процентов).
На этом этапе фудтех опирался на те типы ресторанов, что располагали своей доставкой — и 90% этих ресторанов были похожими с точки зрения типа компаний и кухонь. Это были заведения, готовящие пиццу, суши, китайскую еду или фастфуд и представляющие большие бренды вроде Subway или Domino’s. Рестораны при этом, даже имея доставку, далеко не всегда уделяли ей много внимания и внимательно работали с сервисом. По моему наблюдению, вообще большинство руководителей в ресторанном бизнесе мыслят не в терминах конверсий, юнит-экономики и ретеншна, а в более приземленных выручках и кэше. Поэтому они могут не видеть проблем там, где их увидит фудтех — например, в плохом клиентском опыте и том, что клиенты редко заказывают повторно.
Возможно, именно то, что фудтехи жили «в других метриках», однажды натолкнуло их на запуск собственной доставки. Последовательно фудтех-компании стали создавать собственные службы доставки, ознаменовав тем самым новую веху развития фудтеха. Появились команды, занимающиеся наймом, обучением и удержанием курьеров. Возникли приложения для курьеров, операционные метрики, системы мотивации и тысячи экспериментов про то, как лучше работать с курьерами, чтобы получить лучший сервис и себестоимость. И довольно скоро после запуска собственной доставки фудтех компании поняли, что они могут сделать доставку существенно более быстрой и качественной по сравнению с доставкой ресторанов.
Доставка силами ресторанов, при этом, никуда не делась. Для фудтех компании через какое-то время эта часть их бизнеса стала «дойной коровой» — рост там был не таким стремительным, но юнит-экономика значительно лучше. Но мышление на стороне ресторанов и на стороне фудтехов было разным. Одни думали про выручку и прибыль, другие — про ретеншн и юнит-экономику. Фудтехи иногда делали попытки перевести партнеров с собственными курьерами на доставку силами маркетплейса, но движение это шло очень неохотно.
Рестораны так же неохотно шли на переключение. Они уже понесли расходы на создание своей логистики — были созданы свои приложения, разработана своя форма, наняты люди. Другое важное обстоятельство — изменение условий работы с агрегатором. Если агрегатор занимается лишь тем, что сводит вместе клиента и ресторан, то он готов работать за 10-20% чека. Если же агрегатор еще и занимается собственно доставкой, то он попросит значительно больше — вплоть для более-менее стандартных для рынка 30-35% чека. И вот на месте ресторана платить кому-то 30-35% процентов чека — это часто перебор.
Проблема ретеншна ресторанов с собственными курьерами.
В сентябре 2021 года я пришел в Деливери Клаб на роль Head of non-QSR. Мы внутри Деливери Клаба под QSR подразумевали ровно три бренда — Макдональдс, КФС и Бургер Кинг. Все остальные рестораны — в терминологии Деливери Клаба были non-QSR. Так что получалось, что я руководил всем бизнесом по доставке еды из ресторанов, кроме этих трех брендов.
В моем периметре была как доставка еды курьерами ДК, так и доставка силами ресторанов. Не раскрывая конкретных цифр, могу сказать, что месячный ретеншн в сегменте с курьерами ресторанов был хуже другой части бизнеса примерно на треть — и это гигантская разница.
Итак, одной из моих задач в новой роли стало улучшение ретеншн в сегменте доставки из ресторанов с собственными курьерами.
Первый подход к снаряду — компоненты ценностного предложения.
Что вообще определяет то, закажет ли у нас клиент повторно? И в чем из этого кроется проблема в нашем случае? Именно с этих двух вопросов мы с командой начали решать задачу.
По привычке, приобретенной в консалтинге, я решил нарисовать дерево факторов, соблюдая принцип МЕСЕ (mutually exclusive, collectively exhaustive) . Получилось примерно так:
- Факторы, влияющие на возврат клиента
- Обещание Обещанное время доставки (Готов ли я снова ждать доставки столько?) Тип еды (Как часто я готов есть такую еду?) Стоимость (Как часто я готов столько тратить на еду?) Прошлый опытФактическое время доставки (Привезли ли мне заказ в обещанное время?) Качество еды (Была ли еда такой, как на картинке? Хочу ли я ее снова?) Прочее (Был ли курьер вежлив и опрятен? Была ли поддержка качественной? И тд)
В целом, если разница в ретеншне есть, то она кроется где-то в этих компонентах. Осталось только подобрать метрики и все посчитать, верно? Оказалось, все не так просто.
Когда агрегатор доставляет заказ сам, он фиксирует огромное количество событий, из которых позже считаются всякие метрики. Когда же агрегатор выступает лишь местом встречи клиента и ресторана, все события после оплаты почти всегда остаются ему неизвестны. Поэтому, например, нам оказалось сложно посчитать фактическое число опозданий и размер этих опозданий.
В результате мы сделали несколько аналитических упражнений, и выяснили следующее.
- Тип еды в ресторанах со своей доставкой оказывает влияние, но дело не в нем одном. Чтобы это понять, мы разбили все имеющиеся у себя рестораны на несколько сегментов, нашли представителей разных сегментов с похожими показателями по стоимости блюд, скорости доставки (обещанной) и прочим компонентам ценностного предложения и сравнили между собой. Оказалось, что наша коммерческая команда договорилась с несколькими брендами попробовать поработать с нашими курьерами в нескольких точках. Это было примером именно того перевода ресторанов с одной модели на другую, о котором я говорил в конце первой главы. Таким образом мы могли взять похожие рестораны одного бренда и сравнить их с точностью до доставки — в одном случае она будет собственной, а в другом — Деливери Клабовской. И на нескольких таких примерах мы увидели, что с нашей доставкой ретеншн лучше.
- Есть проблема с обещанным временем доставки. В нашем случае, обещанное время доставки определялось моделью работы курьеров. Как правило, рестораны с собственными курьерами закрепляли этих курьеров за определенными ресторанами. Курьер дожидался, пока наберется 3-5 заказов, кидал их в машину или мопед и отправлялся развозить — поочередно. При этом ресторан заинтересован возить заказы как можно большими пачками, так как так себестоимость доставки ниже. Деливери Клаб же в основном доставлял по 1-2 заказа, и освободившихся курьеров отправлял не обратно в ресторан отправки, а за следующим заказом поближе к последнему адресу доставки. Таким образом, сама модель работы — доставка курьерами ресторана — обуславливала то, что обещанное время доставки больше, а потому ретеншн ниже.
- Самая большая проблема — опоздания. В этом месте мы решили полагаться в основном на число обращений с жалобами на опоздания, деленными на число заказов. Такая метрика называется у нас Contact rate, данные о ней хорошо собирались нашей службой поддержки. И вот именно в ней мы увидели проблему — по заказам с доставкой курьерами ресторанов мы получали жалобы на опоздания примерно в 6-10 раз чаще, чем по заказам с нашими курьерами.
Итак, мы поняли, с чем нужно работать, чтобы починить ретеншн.
- Решить проблему опозданий
- Понизить обещанное время
Пробуем чинить опоздания.
Увидев размер проблемы с опозданиями, мы решили попробовать решить ее алгоритмически. По некоторым брендам у нас были данные о времени завершения заказа, и они согласовывались с жалобами клиентов на опоздания. У нас так же были обращения в поддержку по всем брендам. Обещанное время доставки выставляли сами рестораны, но мы могли его переписать и были готовы менять политику в этой части, чтобы реже врать своим клиентам. Поэтому мы собрали незамысловатый алгоритм, который следил за опозданиями и жалобами и увеличивал обещанное время доставки, приводя его в соответствие с вероятным фактическим.
На бумаге, идея была хорошей. Однако на практике сработала не блестяще — мы снизили число обращений лишь на 10-20% (напомню, разница с нормой была в 6-10 раз). Причина крылась в том, что данные, на который опирался алгоритм, оказались слишком плохого качества и малого объема для него. В результате мы сводили обещание и реальность сильно реже, чем хотели. Нужно было делать что-то еще.
Глазами ресторана.
Выкатив новый алгоритм, корректирующий обещанное время, мы словили вой от ресторанов. Нашим КАМам стали массово звонить разъяренные партнеры и спрашивать, почему у них стало резко меньше заказов или (если они были чуть подкованней) почему они получили более высокое обещанное время доставки и более низкие позиции в каталоге и поиске. В ответ мы стали общаться, рассказывать свое видение и слушать, что нам говорили рестораны.
Оказалось, что проблема опозданий не существовала в мире большинства рестораторов. Подавляющее большинство только от нас вообще узнали, что на их доставку жалуются из-за опозданий. Мы рассказали, чего хотим — реалистичных обещаний о скорости доставки и, по возможности, как можно более быстрой доставки. Партнеры нас услышали и поняли. Чтобы понять суть проблемы лучше, мы договорились зарыться в детали: отобрать несколько конкретных заведений, на которые много жалоб по опозданиям, и выяснить, почему же эти опоздания происходят.
Закопавшись в детали, мы обнаружили, что причины опозданий были весьма банальными. В существенной части случаев это был заболевший курьер, сниженная скорость курьеров из-за погоды или пробок, большая единовременная нагрузка на ресторан или большой заказ (в нашем приложении обещанное время выполнения заказа не увеличивалось, если кто-то заказал не 1 пиццу, а двадцать) . Управляющие заведений на местах часто не знали, что обещанное время доставки можно менять, и не были знакомы с тем, как это делать.
Мы договорились с ресторанами работать с опозданиями вместе и решили создать под это отдельный процесс. На нашей стороне команда аналитики настроила автоматические отчеты, которые на регулярной основе «подсвечивали» плохие с точки зрения опозданий рестораны и рассылала эти данные соответствующим ответственным аккаунт-менеджерам. Эти аккаунт менеджеры передавали информацию партнерам и договаривались о шагах и сроках решения проблем. Пока проблемы были не решены, мы поднимали обещанное время доставки. Как только проблемы были решены на стороне ресторанов, партнеры давали сигнал своим аккаунт-менеджерам в ДК. Мы снова опускали обещанное время доставки и следили за жалобами. Если их не было, оставляли. Если снова появлялись — поднимали снова и работали на проблемами дальше.
Результаты и выводы.
Вопреки ожиданиям СЕО (мы с ним про это спорили) , именно работа коммерции, а не автоматическая корректировка обещанного времени доставки, произвела реальный переворот. Мы снизили процент обращений с жалобами на доставку практически до уровня нашей собственной доставки именно после автоматических отчетов и работы через КАМов. К моменту начала интеграции ДК и Яндекса обращений по заказам силами курьеров ресторанов было всего на 10-20% больше, чем по заказам с нашей доставкой.
Подтвердился еще один тезис, часто имеющий место: никогда не стоит полагаться, что ваши контрагенты видят ситуацию и проблему так же, как и вы. Также в очередной раз мы убедились, что качественная коммуникация, подтвержденная уместными и железобетонными данными, творит чудеса. Когда мы показали ресторанам их проценты жалоб в сравнении с остальными, у них просто не было аргументов. «Вы врете нашим клиентам, коллеги. Это факт и это плохо.» Возможно, прямо так наши ребята не говорили, но посыл был примерно такой. И он был услышан, принят и взят в работу. И именно это устранило проблему.