Представьте, что вы — управляющий пиццерии. Конвейер печи в вашем ресторане может приготовить максимум 100 пицц в час. Вдруг вы получаете на определённый час заказы от разных клиентов на 300 пицц.
В панике перестаёте принимать новые заказы, ожидания клиентов получить пиццу вовремя рушатся, а за опоздавшую доставку вы раздаёте промокоды в качестве извинения. Бизнес трещит по всем возможным швам: производственным, складским, клиентским. Как этого избежать?
В этой статье поделимся опытом, как на сайт и в приложение Додо Пиццы добавили информацию о загрузке пиццерий и смогли улучшить ситуацию с работой в пиковые дни продаж. Она будет интересна в первую очередь менеджерам, которые управляют продуктом, клиентским спросом и ищут пути улучшения пользовательского опыта.
Меня зовут Антон Савченков, я продакт-оунер в Dodo. Моя команда работает над улучшением производственных и управленческих интерфейсов ERP на рынке и созданием лучшей производственной линии с помощью IT. Как и в любом бизнесе, предоставляющем клиентский сервис с операционкой на последних этапах доставки продукта или услуги, мы ищем разные подходы и способы, чтобы спрогнозировать работу в пики и при этом оправдать ожидания клиентов.
В праздничные дни больше продаж. Это же хорошо?
Не всегда.
К праздничным дням у нас особое отношение: ожидания клиентов высокие, а мы можем сделать большую выручку и сильно увеличить прибыль, если всё операционно круто провести.
Но в эти же дни существует высокая вероятность ошибок. Она может быть в комплектации заказов, падении скорости приготовления и доставки, росте опозданий, горе выданных сертификатов — подставьте нужное. В итоге — сломанные ожидания клиентов, а у нас — затяжные стопы продаж из-за сильно возросшей нагрузки. Из-за непредсказуемости заказов невозможно планировать работу и запасы продуктов.
Инструмент для менеджеров, чтобы управлять нагрузкой
У управляющих пиццерий давно есть инструмент, который позволяет «уйти в стоп», т.е. прекратить принимать заказы, если на кухне перегрузка.
В 2019 году мы улучшили интерфейсы, которыми пользуется менеджер смены для того, чтобы понимать, как в пиццерии дела с загрузкой. Собрали все данные на одном экране, добавили визуализацию загрузки, вытащили ещё некоторые данные о заказах, которые раньше надо было смотреть в другом месте, добавили возможность совершать нужные действия с заказами быстрее.
Это дало возможность удобнее и быстрее управлять нагрузкой на пиццерию, лучше с ней справляться и реже уходить в стоп.
Ситуация улучшилась, но кардинально не поменялась. Мы продолжали получать жалобы от менеджеров и клиентов, о проблеме явно говорили наши метрики. В пики всё равно всем было сложно.
Но в чём именно проблема и как её можно решить?
Копаем глубже: чем недовольны менеджеры, а чем — клиенты?
Мы провели интервью с управляющими пиццерий, чтобы больше узнать об их болях в пики. Оказалось, много проблем было из-за невозможности их прогнозировать. Пугали внезапные перегрузки, был страх не успеть приготовить. Это тащило за собой ошибки в заказах, особенно у новичков.
Примерно после восьмого интервью стало понятно, что самая большая боль для пиццерий — это неожиданность пика внутри дня. И идеальный рабочий день для них выглядит как заранее известное распределение всех заказов по минутам внутри рабочего дня.
Интервью с клиентами показали, что в пики для них на первом месте стоит своевременность доставки, а потом уже скорость. Клиенту важно понимать, что заказ приедет с 99% вероятностью в 14:00, чем с 50% в — 13:00.
В целом проблема свелась к тому, что между клиентами и пиццериями была только запаздывающая обратная связь (извинения и выдача сертификата за опоздание), не было опережающей обратной связи.
Как справляются конкуренты?
Очевидно, что мы не одни страдаем в дни пиковых продаж. Поэтому параллельно мы изучали, как обстоят дела у наших конкурентов и соседей по сегменту в пики — механики могут быть похожими и близкими, ведь проблема одинаковая.
Например, в такси в период высокго спроса увеличивается минимальная стоимость поездки. Delivery Club сигналит на старте заказа о повышенном времени доставки. «Кухня на районе» предупреждает на каждом продукте, что придётся подождать, а если кухня уже перегружена, то сообщает, когда примерно она вернётся в строй.
Все что-то пытаются предпринять — это классическая задача балансировки спроса-предложения. Работа с ожиданиями клиентов на старте, а не разбор полётов в конце.
Что если предупреждать клиентов заранее о загрузке пиццерии?
Мы осознали, что ничего похожего у нас в приложении нет.
Тогда решили попробовать грубую модель без повышения минимального чека и скидок за сдвинутый во времени заказ — сообщать клиенту на чекауте, что пиццерия перегружена. Предполагалось, что клиенты, которые увидят уведомление о загруженности пиццерии в момент заказа, всё равно его сделают, выбрав менее загруженный интервал доставки. Гипотезу поддержала вся команда, мы решили запустить А/В тесты.
Выбрали 5 городов, в которых на чекауте мобильного сайта показывали предупреждение о перегрузке: это были захардкоженные вечерние часы, выбранные по согласованию с пиццериями.
После набора статистической значимости получили следующее перераспределение в тестовой группе:
Берёмся за разработку
Чтобы её реализовать, на сайте и в приложении нужно было доработать чекаут с уведомлениями:
прокинуть контракт между трекингом кухни и клиентскими сервисами, по которому трекинг будет слать ивенты на запуск показа перегрузки;
сделать настройку порога перегрузки в бэкофисе для каждой пиццерии.
Но сначала нужно научить трекинг понимать, когда он перегружен, а когда нет.
Трекинг — это система, которая работает с отдельными позициями заказов или же с заказом целиком, но никак не со всеми заказами в пиццерии.
Соответственно, чтобы научить трекинг оповещать клиентские сервисы об изменении состояния перегрузки, нужно было сначала научить сам трекинг понимать, сколько продуктов будет на кухне в пиццерии в тот или иной момент времени.
Делаем «модуль сбоку»
Мы не хотели смешивать ответственности за операционку (фактическое приготовление продуктов) и аналитику (тот самый режим перегрузки). Думали о том, чтобы иметь возможность вынести эту логику в отдельный сервис — по крайней мере попробовать так сделать и на практике оценить сложности такого подхода. Также не хотелось нагружать основные таблицы постоянными запросами вроде SELECT COUNT(*) FROM productionitems WHERE UnitId = @unitId. Поэтому мы пришли к решению сделать небольшой модуль сбоку.
Этот модуль должен следить за двумя вещами:
временем, когда заказы попадают на трекер для приготовления и когда их отмечают приготовленными;
типом заказов: отложенные на определённое время и «как можно скорее».
Имея эту информацию, можно понять, что происходит на кухне.
Модуль подписывается на события, которые трекинг публикует в шину, строя по ним модель представления. Но при этом он всё ещё находится внутри трекинга и имеет доступ к остальной части базы данных, в которой есть информация о пиццериях, их часовых поясах и настройках режима перегрузки (о настройках будет дальше).
Стоит отметить, что заказы «как можно скорее» и «отложенные» обрабатываются по-разному.
Как можно скорее
Тут довольно просто: считаем все продукты в заказе, которые есть на трекинге прямо сейчас. Т.е. времени готовности нет, а время выхода на трекинг меньше, чем текущее время. Если этих позиций больше, чем настраиваемый порог, то входим в режим перегрузки, если меньше — то выходим из него.
Отложенные
Тут уже сложнее. Как понять, что если заказать на конкретный интервал, то высок риск опоздания? Когда клиент выбирает в приложении или на сайте опцию «Доставить с 15:30 до 16:00», заказ появится на трекинге не ровно в 15:30, а заранее. Причём это «заранее» отличается для доставки и самовывоза.
Алгоритм в итоге получился примерно такой:
берём каждый доступный для заказа интервал. Т.е.
[ 00:00-00:30, 00:15-00:45, 00:30-01:00 ... ];каждый из этих интервалов сдвигаем назад на среднее время приготовления плюс время доставки заказа (или просто приготовления для самовывоза). Этот сдвиг также может настраиваться индивидуально, под каждую пиццерию;
считаем количество продуктов, которые выйдут на трекинг в полученный интервал;
если количество продуктов превышает какой-то настраиваемый порог, значит, интервал является перегруженным;
Шаги выше отдельно исполняются для доставки, и отдельно для самовывоза. В случае, если перегруженные интервалы как-то изменились с момента последнего расчёта, мы публикуем событие для клиентских сервисов.
На разработку ушло примерно примерно полгода, потому что мы докручивали модуль по результатам аналитики.
Результаты
В середине декабря 20-го года раскатали фичу на всю Россию, а через пару дней — на все страны. За первый месяц из аналитики мы увидели, что в 2 раза срезается конверсия, когда пиццерия в перегрузке — значит, нам удалось в 2 раза снизить нагрузку на пиццерии в пики, когда они могли бы уйти в стоп. 30% из дошедших до заказа делают отложенную доставку.
Тут важно заметить, что фича определяет поведение клиентов на чекауте в перегрузке — то, что мы увидели на АВ-тесте. Мы пробуем контролировать то, на что можем повлиять. Операционные метрики пиццерий зависят от множества локальных факторов (расписания сотрудников, своевременности их прихода на смену, точности прогноза закупки сырья и бесперебойности поставок, плана продаж и т.д.).
В пиковые моменты 1 сентября в пиццериях России мы срезали спрос в заказах примерно на 4,5% , а отток клиентов на чекауте (т.е. не дошедших до создания заказа) составил примерно 98% — перераспределения заказов по времени внутри дня, как в декабре, не случилось. Зато не сломали ожидания наших клиентов и позволили пиццериям пройти пики спокойней ;)
P.S. При этом 33% из тех клиентов, которые закрыли сайт или приложение в перегрузке, вернулись и сделали заказ в течение 12 часов. Маленькая победа!
Надеюсь, что эта статья была полезной. Буду рад прочитать в комментариях, как вы справляетесь с работой в пиковые дни.
