Как управлять спросом без дарк-паттернов, промокодов, регистрации и смс?

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

В панике перестаёте принимать новые заказы, ожидания клиентов получить пиццу вовремя рушатся, а за опоздавшую доставку вы раздаёте промокоды в качестве извинения. Бизнес трещит по всем возможным швам: производственным, складским, клиентским. Как этого избежать?

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

Меня зовут Антон Савченков, я экс-продакт в Dodo. Работал над улучшением производственных и управленческих интерфейсов ERP на рынке и созданием лучшей производственной линии с помощью IT.
Как и в любом бизнесе, предоставляющем клиентский сервис с операционкой на последних этапах доставки продукта или услуги, мы ищем разные подходы и способы, чтобы спрогнозировать работу в пики и при этом оправдать ожидания клиентов.

Не всегда.

К праздничным дням у нас особое отношение: ожидания клиентов высокие, а мы можем сделать большую выручку и сильно увеличить прибыль, если всё операционно круто провести.

Но в эти же дни существует высокая вероятность ошибок. Она может быть в комплектации заказов, падении скорости приготовления и доставки, росте опозданий, горе выданных сертификатов — подставьте нужное. В итоге — сломанные ожидания клиентов, а у нас — затяжные стопы продаж из-за сильно возросшей нагрузки. Из-за непредсказуемости заказов невозможно планировать работу и запасы продуктов.

У управляющих пиццерий давно есть инструмент, который позволяет «уйти в стоп», т.е. прекратить принимать заказы, если на кухне перегрузка.

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

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

Ситуация улучшилась, но кардинально не поменялась. Мы продолжали получать жалобы от менеджеров и клиентов, о проблеме явно говорили наши метрики. В пики всё равно всем было сложно.

Но в чём именно проблема и как её можно решить?

Мы провели интервью с управляющими пиццерий, чтобы больше узнать об их болях в пики. Оказалось, много проблем было из-за невозможности их прогнозировать. Пугали внезапные перегрузки, был страх не успеть приготовить. Это тащило за собой ошибки в заказах, особенно у новичков.

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

Интервью с клиентами показали, что в пики для них на первом месте стоит своевременность доставки, а потом уже скорость. Клиенту важно понимать, что заказ приедет с 99% вероятностью в 14:00, чем с 50% в — 13:00.

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

Здесь вспоминается закон из ТРИЗ: если нет обратной связи между частями системы, то сделай её. Есть она есть, то усиль её до предела.

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

Например, в такси в период высокго спроса увеличивается минимальная стоимость поездки. Delivery Club сигналит на старте заказа о повышенном времени доставки. «Кухня на районе» предупреждает на каждом продукте, что придётся подождать, а если кухня уже перегружена, то сообщает, когда примерно она вернётся в строй.

Все что-то пытаются предпринять — это классическая задача балансировки спроса-предложения. Работа с ожиданиями клиентов на старте, а не разбор полётов в конце.

Мы осознали, что ничего похожего у нас в приложении нет.

Тогда решили попробовать грубую модель без повышения минимального чека и скидок за сдвинутый во времени заказ — сообщать клиенту на чекауте, что пиццерия перегружена. Предполагалось, что клиенты, которые увидят уведомление о загруженности пиццерии в момент заказа, всё равно его сделают, выбрав менее загруженный интервал доставки. Гипотезу поддержала вся команда, мы решили запустить А/В тесты.

Выбрали 5 городов, в которых на чекауте мобильного сайта показывали предупреждение о перегрузке: это были захардкоженные вечерние часы, выбранные по согласованию с пиццериями.

После набора статистической значимости получили следующее перераспределение в тестовой группе:

Группа перераспределилась с пикового времени примерно на 40%. Гипотеза подтвердилась!

Чтобы её реализовать, на сайте и в приложении нужно было доработать чекаут с уведомлениями:

Но сначала нужно научить трекинг понимать, когда он перегружен, а когда нет.

Трекинг — это система, которая работает с отдельными позициями заказов или же с заказом целиком, но никак не со всеми заказами в пиццерии.

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

Мы не хотели смешивать ответственности за операционку (фактическое приготовление продуктов) и аналитику (тот самый режим перегрузки). Думали о том, чтобы иметь возможность вынести эту логику в отдельный сервис — по крайней мере попробовать так сделать и на практике оценить сложности такого подхода. Также не хотелось нагружать основные таблицы постоянными запросами вроде

Поэтому мы пришли к решению сделать небольшой модуль сбоку.

Этот модуль должен следить за двумя вещами:

Имея эту информацию, можно понять, что происходит на кухне.

Модуль подписывается на события, которые трекинг публикует в шину, строя по ним модель представления. Но при этом он всё ещё находится внутри трекинга и имеет доступ к остальной части базы данных, в которой есть информация о пиццериях, их часовых поясах и настройках режима перегрузки (о настройках будет дальше).

Стоит отметить, что заказы «как можно скорее» и «отложенные» обрабатываются по-разному.

Как можно скорее

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

Отложенные

Тут уже сложнее. Как понять, что если заказать на конкретный интервал, то высок риск опоздания? Когда клиент выбирает в приложении или на сайте опцию «Доставить с 15:30 до 16:00», заказ появится на трекинге не ровно в 15:30, а заранее. Причём это «заранее» отличается для доставки и самовывоза.

Алгоритм в итоге получился примерно такой:

Шаги выше отдельно исполняются для доставки, и отдельно для самовывоза. В случае, если перегруженные интервалы как-то изменились с момента последнего расчёта, мы публикуем событие для клиентских сервисов.

На разработку ушло примерно примерно полгода, потому что мы докручивали модуль по результатам аналитики.

Вот так сейчас предупреждаем клиента, как обстоят дела в пиццерии. Дальше он сам выбирает, готов ли ждать.

В середине декабря 20-го года раскатали фичу на всю Россию, а через пару дней — на все страны. За первый месяц из аналитики мы увидели, что в 2 раза срезается конверсия, когда пиццерия в перегрузке — значит, нам удалось в 2 раза снизить нагрузку на пиццерии в пики, когда они могли бы уйти в стоп.
30% из дошедших до заказа делают отложенную доставку.

Тут важно заметить, что фича определяет поведение клиентов на чекауте в перегрузке — то, что мы увидели на АВ-тесте. Мы пробуем контролировать то, на что можем повлиять. Операционные метрики пиццерий зависят от множества локальных факторов (расписания сотрудников, своевременности их прихода на смену, точности прогноза закупки сырья и бесперебойности поставок, плана продаж и т.д.).

В пиковые моменты 1 сентября в пиццериях России мы срезали спрос в заказах примерно на 4,5% , а отток клиентов на чекауте (т.е. не дошедших до создания заказа) составил примерно 98% — перераспределения заказов по времени внутри дня, как в декабре, не случилось. Зато не сломали ожидания наших клиентов и позволили пиццериям пройти пики спокойней ;)

P.S. При этом 33% из тех клиентов, которые закрыли сайт или приложение в перегрузке, вернулись и сделали заказ в течение 12 часов. Маленькая победа!

Надеюсь, что эта статья была полезной. Буду рад прочитать в комментариях, как вы справляетесь с работой в пиковые дни.

#додопицца #фидбэк #спрос #продукт