Всем привет! 

Несколько недель назад Деливери Клаб (ДК) перестал существовать как отдельная компания. Он навсегда останется в моем сердце, как и у подавляющего большинства тех, кто застал последние его годы до сделки с Яндексом. Однако кроме общих теплых воспоминаний и огромного количества крутейших бывших коллег, я из ДК вынес и несколько историй (надеюсь, интересных), о которых охота рассказать. Ниже одна из таких историй.

Глава 1. Про рынок доставки еды и откуда у агрегаторов курьеры.

Агрегаторы вроде Деливери Клаба (ДК) и Яндекс.Еды (ЯЕ), как и их международные собратья вроде DoorDash, Just Eat Takeway, Careem и прочие, не придумали доставку еды. Задолго до их появления существовали и рестораны, и курьеры. Именно поэтому в первые годы развития фудтеха доминировала модель маркетплейса. Фактически, фудтех компании решали задачу поиска ресторанов с доставкой и выбора, и на первых порах этого хватало. Возникли сайты и приложения с заметной аудиторией, фудтехи заключили контракты с тысячами ресторанов и стали работать - причем, преимущественно в плюс. Оно и понятно - расходов не много (только маркетинг, продукт и общие административные, никакой операционки), доходов - много (рестораны с хорошими чеками плюс комиссия в десяток-два процентов). 

На этом этапе фудтех опирался на те типы ресторанов, что располагали своей доставкой - и 90% этих ресторанов были похожими с точки зрения типа компаний и кухонь. Это были заведения, готовящие пиццу, сущи, китайскую еду или фастфуд. Кроме того, большое количество точек (то есть физических ресторанов) представляли большие бренды вроде Subway или Domino’s. Рестораны при этом, даже имея доставку, далеко не всегда уделяли ей много внимания и внимательно работали с сервисом. По моему наблюдению, вообще большинство руководителей в ресторанном бизнесе мыслят не в терминах конверсий, юнит-экономики и ретеншна, а в более приземленных выручках и кэше. Поэтому они могут не видеть проблем там, где их увидит фудтех - например, в плохом клиентском опыте и том, что клиенты редко заказывают повторно. 

Возможно, именно то, что фудтехи жили «в других метриках», однажды натолкнуло их на запуск собственной доставки. Могу представить ход рассуждений кого-нибудь вроде руководства DoorDash: «На рынке так много ресторанов, в которые ходят люди, но у которых нет курьеров! Уверен, если бы мы дали нашим пользователям возможность заказать оттуда, они бы чаще пользовались нашим сервисом и позволили бы нам расти существенно быстрей! Кроме того, если мы будем работать с большим числом ресторанов и клиентов, то сможем минимизировать стоимость доставки, оставляя приемлемым заработок курьеров. И таким образом, сведем свою юнит-экономику.» 

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

Думаю, довольно скоро после запуска собственной доставки фудтех компании поняли, что они могут сделать доставку существенно более быстрой и качественной по сравнению с доставкой ресторанов. Кроме другой модели работы доставки - той, где курьеры не возвращаются к «родному» ресторану по завершении заказа, а берут следующий заказ поблизости - были еще и венчурные деньги. На венчурные деньги можно было нагнать кучу курьеров и обеспечить «oversupply» (то есть избыток «предложения» в виде времени курьеров), который в свою очередь помогает иметь курьера поблизости почти всегда и обеспечить качественно лучшее время доставки. Довольные такой быстрой доставкой клиенты стали чаще заказывать, когорты поползли вверх, и под впечатляющий скачок роста привлекались следующие раунды инвестиций по все более лакомой оценке компаний.

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

Рестораны так же не охотно шли на переключение. Они уже понесли расходы на создание своей логистики - были созданы свои приложения, разработана своя форма, наняты люди. Все без исключения компании подверженны феномену, хорошо изученному в поведенческой экономике: гораздо сложней признать понесенные расходы бесполезными или более не нужными, чем в очередной раз увеличить бюджет проекта или растянуть срок его жизни. Рестораны тут не исключение. Поэтому даже если они понимали, что могут зарабатывать больше, все равно обычно оставляли свои службы доставки. Другое важное обстоятельство - изменение условий работы с агрегатором. Если агрегатор занимается лишь тем, что сводит вместе клиента и ресторан, то он готов работать за 10-20% чека (в зависимости от переговорной силы фудтаха и ресторана). Если же агрегатор еще и занимается собственно доставкой, то он попросит значительно больше - вплоть для более-менее стандартных для рынка 30-35% чека. И вот на месте ресторана платить кому-то 30-35% процентов чека - это часто перебор. Нет уж, скажет вам ресторан, я лучше сам доставлю, спасибо. К тому же, полагаться на фудтех еще и в доставке значит в некоторой мере больше от него зависеть, а значит стать более уязвимым в переговорах.

Глава 2. Проблема ретеншна ресторанов с собственными курьерами.

На дворе сентябрь 2021 года. Я пришел в Деливери Клаб на роль Head of non-QSR. Где QSR - это quick-serving restaurants. В общем случае так называют фастфуд, но в случае фудтеха речь обычно идет не провесь фастфуд, а про крупнейших игроков. Там будут бургеры типа Макдоналдс и Бургер Кинга, пиццы вроде Домино’с и Папа Джонс, сэндвичи типа Сабвей. Однако мы внутри Деливери Клаба под QSR подразумевали ровно три бренда - Макдоналдс, КФС и Бургер Кинг. Все остальные рестораны - в терминологии Деливери Клаба были non-QSR. Так что получалось, что я руководил всем бизнесом по доставке еды из ресторанов, кроме этих трех брендов.

В моем периметре была как доставка еды курьерами ДК, так и доставка силами ресторанов. В целом, до моего прихода на мой сегмент бизнеса ровно так и смотрели обычно - вот кусок с нашими курьерами, в вот - с ресторанными. Вот их когорты и экономика, в такой же детализации составлен по ним бюджет. И на этой же детализации был виден слон в комнате - разница в удержании клиентов. Не раскрывая конкретных цифр, могу сказать, что месячный ретеншн в сегменте с курьерами ресторанов был хуже другой части бизнеса примерно на треть - и это гигантская разница. Весь кошмар заключался в том, что чем меньше ретеншн сегмента бизнеса, тем больше денег тебе нужно тратить на привлечение новых клиентов, чтобы бизнес хотя бы оставался на прежних объемах. А если у тебя есть несколько сегментов (как в ДК), и у всех них, кроме одного, ретеншн относительно высокий, то сегмент с низким ретеншн это такой party pooper. Все остальные смотрят на него с укоризной. Мол, молодец, просрал клиента. А мы бы ему еще что-нибудь продали. 

Итак, одной из моих задач в новой роли стало улучшение ретеншн в сегменте доставки из ресторанов с собственными курьерами.

Глава 3. Первый подход к снаряду - компоненты ценностного предложения.

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

По привычке, приобретенной в консалтинге, я решил нарисовать дерево факторов, соблюдая принцип МЕСЕ (mutually exclusive, collectively exhaustive). Получилось примерно так:

• Факторы, влияющие на возврат клиента

  • Обещание 

    • Обещанное время доставки (Готов ли я снова ждать доставки столько?)

    • Тип еды (Как часто я готов есть такую еду?)

    • Стоимость (Как часто я готов столько тратить на еду?) 

  • Прошлый опыт

    • Фактическое время доставки (Привезли ли мне заказ в обещанное время?)

    • Качество еды (Была ли еда такой, как на картинке? Хочу ли я ее снова?)

    • Прочее (Был ли курьер вежлив и опрятен? Была ли поддержка качественной? И тд)

В целом, если разница в ретеншне есть, то она кроется где-то в этих компонентах. Осталось только подобрать метрики и все посчитать, верно? Оказалось, все не так просто.

Когда агрегатор доставляет заказ сам, он фиксирует огромное количество событий, из которых позже считаются всякие метрики. Например, мы можем легко понять в каком числе случаев доставка произошла позже обещанного времени и насколько позже. Мы в целом можем понять, когда заказ доставлен, и записать соответствующее событие. Когда же агрегатор выступает лишь местом встречи клиента и ресторана, все события после оплаты почти всегда остаются ему неизвестны. Потому что ресторан на эту тему не заморачивается, а больше достоверную информацию взять неоткуда. Поэтому, например, нам оказалось сложно посчитать фактическое число опозданий и размер этих опозданий. При этом по нескольким брендам таки удалось. По счастливой случайности в нескольких наших API были предусмотрены события «заказ доставлен», которые мы получали от ресторанов. Как они появлялись, при этом, было не вполне ясно. Скорее всего, кто-то писавший интеграцию, оставил место под такое событие. И где-то в системе ресторана какое-то событие тригерило отправку информации по API. Однако все, кто имел отношение к созданию интеграции, покинули и ДК, и ресторан, и что там живет реально - никто не знает. 

В результате мы сделали несколько аналитических упражнений, и выяснили следующее.

1. Тип еды в ресторанах со своей доставкой оказывает влияние, но дело не в нем одном. Чтобы это понять, мы разбили все имеющиеся у себя рестораны на несколько сегментов, нашли представителей разных сегментов с похожими показателями по стоимости блюд, скорости доставки (обещанной) и прочим компонентам ценностного предложения и сравнили между собой. Предсказуемо, при прочих равных наши клиенты заказывали чаще какой-нибудь фастфуд, и реже - пиццу или что-то особенное типа дим-самов. Однако дополнил картину второй результат. Оказалось, что наша коммерческая команда договорилась с несколькими брендами попробовать поработать с нашими курьерами в нескольких точках. Это было примером именно того перевода ресторанов с одной модели на другую, о котором я говорил в конце первой главы. Таким образом мы могли взять похожие рестораны одного бренда и сравнить их с точностью до доставки - в одном случае она будет собственной, а в другом - Деливери Клабовской. И на нескольких таких примерах мы увидели, что с нашей доставкой ретеншн лучше.

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

3. Есть проблема с обещанным временем доставки. Дело в том, что при прочих равных вы закажете там, где вам пообещают привести быстрей. Самый яркий пример этого правила - успех Самоката, Яндекс.Лавки и международных аналогов вроде Getir с доставкой за 15 минут. Эти компании демонстрируют феноменальный ретеншн именно благодаря своей скорости. В нашем случае, обещанное время доставки определялось моделью работы курьеров. Как правило, рестораны с собственными курьерами закрепляли этих курьеров за определенными ресторанами. Курьер дожидался, пока наберется 3-5 заказов, кидал их в машину или мопед и отправлялся развозить - поочередно. Если ресторан старался не врать клиентам, он обещал всем клиентам такое время доставки, за которое курьер довезет последний заказ, ведь априори ресторан не мог знать, кому повезут первому, а кому последнему. При этом ресторан заинтересован возить заказы как можно большими пачками, так как так себестоимость доставки ниже. Деливери Клаб же в основном доставлял по 1-2 заказа, и освободившихся курьеров отправлял не обратно в ресторан отправки, а за следующим заказом поближе к последнему адресу доставки. Таким образом, сама модель работы - доставка курьерами ресторана - обуславливала то, что обещанное время доставки больше, а потому ретеншн ниже.

4. Самая большая проблема - опоздания. В этом месте мы решили полагаться в основном на число обращений с жалобами на опоздания, деленными на число заказов. Такая метрика называется у нас Contact rate, данные о ней хорошо собирались нашей службой поддержки. И вот именно в ней мы увидели проблему - по заказам с доставкой курьерами ресторанов мы получали жалобы на опоздания примерно в 6-10 раз чаще, чем по заказам с нашими курьерами. Более того, мы решили по странным данным о завершении заказа, которые ходили к нам по API от отдельных брендов, понять масштабы проблемы детальней. В итоге нашли несколько крупных брендов, до 80-90% (!!!) заказов которых доставлялись с опозданием на 10 минут и более. В нашем бизнесе это сродни кровопотере по литру в минуту.

Итак, мы поняли, с чем нужно работать, чтобы починить ретеншн.

1. Решить проблему опозданий - привести обещанное время доставки в соответствие с фактическим.

2. Понизить обещанное время - перевести больших партнеров на модель работы с нашими курьерами.

3. Разобраться с низким качеством еды по отдельным крупным брендам.

Забегая вперед, могу сказать, что хуже всего у нас вышло чинить качество еды. Фактических рычагов на нашей стороне было мало, да и сама конкуренция на платформе делала так, что рестораны с плохой едой проигравали своим конкурентам. Единственный знаковый шаг в этом отношении, на который мы пошли, это отказ от продвижения ресторанов с плохими отзывами на еду. Раньше более-менее любой ресторан мог сделать акцию внутри Деливери Клаба и получить дополнительный трафик и заказы. Теперь же мы стали отказывать в продвижении «плохим партнерам», в том числе из-за низкого качества еды. Ниже в статье я фокусируюсь на доставке.

Глава 4. Пробуем чинить опоздания.

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

На бумаге, идея была хорошей. Однако на практике сработала не блестяще - мы снизили число обращений лишь на 10-20% (напомню, разница с нормой была в 6-10 раз). Причина крылась в том, что данные, на который опирался алгоритм, оказались слишком плохого качества и малого объема для него. В результате мы сводили обещание и реальность сильно реже, чем хотели. Кроме того, увеличение обещанного времени доставки обрушило заказы ресторанов. Так что улучшив ситуацию по одной ветке логического дерева выше («размер опоздания при прошлом заказе»), мы одновременно ухудшили ситуацию по другой («обещанное время доставки»). Нужно было делать что-то еще.

Глава 5. Глазами ресторана.

Выкатив новый алгоритм, корректирующий обещанное время, мы словили вой от ресторанов. Нашим КАМам стали массово звонить разъяренные партнеры и спрашивать, почему у них стало резко меньше заказов или (если они были чуть подкованней) почему они получили более высокое обещанное время доставки и более низкие позиции в каталоге и поиске. В ответ мы стали общаться, рассказывать свое видение и слушать, что нам говорили рестораны.

Оказалось, что проблема опозданий не существовала в мире большинства рестораторов. Были отдельные партнеры с развитыми курьерскими службами, которые даже продвигали «доставку за Х минут» в своем маркетинге когда-то, и потому следили за фактами опозданий. Но подавляющее большинство только от нас вообще узнали, что на их доставку жалуются из-за опозданий. Что и понятно - жаловались-то в нашу поддержку. Мы рассказали, чего хотим - реалистичных обещаний о скорости доставки и, по возможности, как можно более быстрой доставки. Партнеры нас услышали и поняли. Чтобы понять суть проблемы лучше, мы договорились зарыться в детали: отобрать несколько конкретных заведений, на которые много жалоб по опозданиям, и выяснить, почему же эти опоздания происходят. 

Закопавшись в детали, мы обнаружили, что причины опозданий были весьма банальными. В существенной части случаев это был заболевший курьер, сниженная скорость курьеров из-за погоды или пробок, большая единовременная нагрузка на ресторан или большой заказ (в нашем приложении обещанное время выполнения заказа не увеличивалось, если кто-то заказал не 1 пиццу, а двадцать). Управляющие заведений на местах часто не знали, что обещанное время доставки можно менять, и не были знакомы с тем, как это делать. 

Мы договорились с ресторанами работать с опозданиями вместе и решили создать под это отдельный процесс. На нашей стороне команда аналитики настроила автоматические отчеты, которые на регулярной основе «подсвечивали» плохие с точки зрения опозданий рестораны и рассылала эти данные соответствующим ответственным аккаунт-менеджерам. Эти аккаунт менеджеры передавали информацию партнерам и договаривались о шагах и сроках решения проблем. Пока проблемы были не решены, мы поднимали обещанное время доставки. Как только проблемы были решены на стороне ресторанов, партнеры давали сигнал своим аккаунт-менеджерам в ДК. Мы снова опускали обещанное время доставки и следили за жалобами. Если их не было, оставляли. Если снова появлялись - поднимали снова и работали на проблемами дальше.

Добавлю отдельно, что этот новый процесс стал одним из триггеров изменения ролей аккаунт-менеджеров в ДК в целом. Раньше АМы отвечали за доходность своих партнеров и объем продаж по ним. Фактически же они могли весьма ограниченно влиять на эти показатели. Они могли договариваться о комиссии, оно это было тем, что происходило всего 1-2 раза в год. Они могли помогать добавлять новые точки на ДК, но это также было не самым частым событием. Они могли договариваться об особых маркетинговых компаниях. Но кроме всего, что могли делать АМы, была масса факторов, влияющих на продажи и доходность, лежащих за периметром того, на что они влияли. Стоимость доставки и общие рекламные кампании, определяющие трафик в Деливери Клабе в целом, были в ведении команды Маркетинга. Скорость и качество доставки - в ведении Операций. Продвижение внутри приложения через новые фичи - в ведении Продукта и Развития (последнее - моя команда). Таким образом, мы АМы были ответственными за дождь, а в руках у них было чуть больше бубна. После проекта про опоздания в сегменте ресторанов с собственными курьерами, роль коммерции внутри ДК изменилась. Ответственность за уровень комиссии, добавление новых точек и другие классические компоненты остались. Но появилась большая часть проектной работы над актуальными задачами. В один период мы могли наброситься вместе на починку сервиса. В другой - улучшение разнообразия доступных ресторанов в таком-то городе. В третий - продажа ресторанам новых сервисов, например электронных чаевых, платежей или доставки. 

Глава 6. Результаты и выводы.

Вопреки ожиданиям СЕО (мы с ним про это спорили), именно работа коммерции, а не автоматическая корректировка обещанного времени доставки, произвела реальный переворот. Мы снизили процент обращений с жалобами на доставку практически до уровня нашей собственной доставки именно после автоматических отчетов и работы через КАМов. К моменту начала интеграции ДК и Яндекса обращений по заказам силами курьеров ресторанов было всего на 10-20% больше, чем по заказам с нашей доставкой. 

Подтвердился еще один тезис, часто имеющий место: никогда не стоит полагаться, что ваши контрагенты видят ситуацию и проблему так же, как и вы. Как говорится, если один другому что-то сказал, то родилось три сущности: что первый подразумевал, что он сказал и что воспринял второй. Надежда на то, что автокорректировка времени доставки исправит большую часть проблемы частично была основано на том, что рестораны «сами все поймут». Фактически же мы с ними жили просто в разных измерениях, и без нашего глубоко вовлечения решить проблему рестораны бы не могли (да и не стали бы). Так что сколь хайповыми и модными бы не были ML и AI, и сколь бы вы не были подкованы в создании продвинутых инструментов как компания, реальные проблемы обычно решают реальные люди.

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