Почему мобильное приложение пекарни тормозит на пике заказов
Утро в кондитерской — это 40-60 минут, в которые приходит основная часть заказов на день: корпоративные наборы, торты к самовывозу, предзаказы к открытию. Приём заказов на пике превращается в проверку на прочность: приложение, которое днём отвечает за 300 мс, в это окно начинает терять сессии и показывать пустые корзины.
Самый дорогой сбой — обрыв оформления заказа на шаге оплаты. Корзина живёт в памяти экрана, и переход в платёжное приложение или короткий разрыв сети обнуляет её: клиент возвращается к пустому экрану и либо уходит, либо собирает заказ заново. Так появляются дубли заказов — кондитерская печёт два торта вместо одного, а оператор вручную ищет совпадения по имени и телефону.
Отдельная история — нагрузка утренних часов на учёт точки. Если создание заказа уходит синхронным запросом в систему, которую видит оператор, то при задержке её ответа копятся незавершённые транзакции: интерфейс перестаёт реагировать, часть заказов «зависает» в промежуточном статусе. Дальше заказы принимают по телефону и переносят в учёт руками — с опозданиями и потерянными позициями.
Разбираем, как это закрывается: где хранить состояние корзины, чтобы она переживала разрыв, как защититься от повторной отправки и что делать с очередью заказов в утренний пик.
Эффект от запуска: скорость заказа и повторные покупки
Эффект от приложения измеряется не числом установок, а тем, сколько заказов проходит без звонка в точку и сколько гостей возвращается. Поэтому базовые показатели — время оформления заказа, долю повторных покупок, число обращений к продавцу — мы снимаем до запуска и сравниваем с ними первые месяцы работы.
Оформление: минуты вместо звонка
В приложении гость видит актуальный состав витрины, выбирает самовывоз или доставку и оплачивает в один шаг, поэтому время оформления заказа падает с нескольких минут разговора до пары экранов. Адрес и состав заказа остаются в профиле — повторный заказ собирается в два касания. Отдельным сценарием идёт предзаказ торта: конструктор начинки, коржей и декора с выбором даты и подсказкой, за какое время точку нужно предупредить.
Повторные покупки и разгрузка персонала
Баллы за заказ и напоминание в тот час, когда гость обычно берёт кофе или выпечку, поднимают долю повторных покупок: рассылка идёт из приложения, а не силами продавцов. Нагрузка на персонал точки падает — заказ приходит на отдельный экран, готовность отмечается одним касанием, оплата прошла онлайн, и кассиру не нужно принимать заказ по телефону и вбивать его вручную. Средний чек самовывоза растёт за счёт допродажи пары к выпечке в один клик.
Публикация в Google Play и на второй платформе плюс аналитика воронки показывают, на каком шаге гости отваливаются. Через несколько недель видно, какие напоминания возвращают гостей и какое время самовывоза выбирают чаще.
Форматы разработки: единая база, две нативные сборки, шаблон
Пекарне нужны обе платформы: часть гостей заказывает на одной, часть — на другой, а предзаказ и карта лояльности должны работать одинаково. Разница между вариантами не в том, что видит гость, а в объёме кода, который команда ведёт после релиза, и в сроках выпуска приложения.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Единая кодовая база | Каталог, предзаказ, лояльность, уведомления — интерфейс одинаков на обеих платформах | Тяжёлая графика и системные жесты проседают; нужен инженер, знающий обе платформы |
| Две нативные сборки | Нужны камера, оплата и уведомления на пределе возможностей системы | Двойной объём работ: две очереди правок, дольше сроки выпуска приложения |
| Готовый шаблон приложения | Одна точка, короткий сезон, нужен быстрый запуск заказов | Ограниченная логика: свои сценарии лояльности и связка с учётной системой достраиваются отдельно |
Если бизнес привязан к сезону
Готовый шаблон приложения закрывает запуск за считанные недели: витрина, корзина и уведомления уже есть, меняются оформление и состав товаров. Но свои механики — наборы к празднику, предзаказ торта, накопительные уровни — закладывают до старта сезона: дописывать логику в разгар спроса рискованно.
Если точек несколько
Сеть выигрывает от единой кодовой базы: одна логика лояльности, один кабинет администратора, поддержка двух платформ силами одной команды. Нативную сборку под платформу берут, когда нужно выжать из устройства максимум — например, устойчивую оплату на слабой связи в зале или мгновенную съёмку чека.
Как проходит внедрение: от разбора точки до передачи сборки
Внедрение начинается не с макетов, а с разбора точки: как принимают заказы сейчас, где копится очередь в утренний пик, кто закрывает смену и по какой бумаге сверяют выручку. Из этого вырастает схема данных заказ — оплата — выдача: именно она определяет, что видит гость и что попадает в отчёт точки.
Работа идёт этапами, каждый заканчивается проверяемым результатом:
- Разбор процессов точки: путь заказа от витрины и предзаказа до самовывоза, роли сотрудников, узкие места в час пик.
- Схема заказ — оплата — выдача: статусы заказа, способы оплаты, привязка к смене и точке, чтобы отчёты сходились без ручной сверки.
- Этапы разработки приложения: каркас с каталогом и корзиной, затем личный кабинет, повтор заказа и уведомления о готовности.
- Тестирование на реальных заказах: несколько смен с настоящими гостями, включая отмены, доплаты и позиции, которых нет в наличии.
- Выпуск обновления: публикация сборки, порядок выката исправлений и канал, куда приходят сообщения об ошибках.
- Передача и обучение персонала точки: памятки для кассы и сборщика, разбор спорных сценариев смены.
Проверка перед выпуском
Тестируем не по списку кнопок, а по потоку заказов — полный день работы точки на закрытой группе гостей, с возвратами и заказами на завтра. Позиция, закончившаяся к вечеру, должна честно уходить из каталога, а уже оплаченный заказ — не ломать смену.
Обучение персонала точки
Смена осваивает приложение за один разбор: где подтвердить готовность, как провести выдачу по номеру и что делать при расхождении оплаты. Памятка остаётся на точке, а мы сопровождаем первые дни работы, пока поток заказов не станет ровным.
Что вы получаете на руки: сборки, схемы, доступы, регламенты
Проект закрывается не показом на созвоне, а передачей работающего контура. Всё нужное для эксплуатации фиксируем в акте — заказчик проверяет каждый артефакт и может запустить приложение или доработать его своей командой.
- Сборки для магазинов приложений — подписанные и готовые к выгрузке, плюс отдельная сборка для тестирования на телефонах сотрудников.
- Передача исходников: полный репозиторий с историей изменений, доступы оформляем на аккаунт заказчика, а не на наш.
- Документация приложения: экраны и сценарии заказа, структура данных, сторонние библиотеки и их лицензии.
- Политика доступа сотрудников: роли кассира, пекаря, управляющего и владельца с разными правами на заказы, остатки и скидки.
- Регламент обновлений и порядок эскалации: к кому идёт обращение при сбое и в какой срок ждать ответа.
Карта интеграций
- Схема обмена с учётной системой: какие события — новый заказ, списание, остатки — в какую сторону идут и как часто синхронизируются.
- Поведение при обрыве связи: заказ не теряется, уходит в очередь и досылается, а гость видит понятный статус вместо ошибки.
Регламент выпуска версий
- Календарь: плановые обновления и внеплановые правки, кто даёт добро на выкладку.
- Список сценариев, которые обязаны пройти на тестовом контуре перед выпуском.
- Откат на предыдущую версию, если обновление поймало проблему в рабочей сборке.
Кейс: сеть кондитерских ускорила приём заказов вдвое
Сеть кондитерских с двенадцатью точками принимала предзаказы по телефону и в переписке: оператор вручную переносил состав корзины в учётную систему. В утренний пик и перед праздниками оформление занимало до четырёх минут, на кассе росла очередь, а часть заказов терялась в чатах. Доля отмен по вине точки доходила до 12%, и почти каждый третий гость звонил уточнять, готов ли заказ.
Мы сделали приложение с предзаказом к конкретному интервалу выдачи: покупатель выбирает точку, время и состав корзины, оплачивает и получает уведомление о готовности. Заказ попадает сразу в очередь рабочего места кассира, поэтому повторный ввод руками исчез, а статус виден и гостю, и сотруднику. Обмен с учётной системой 1С держит остатки по витрине и не даёт оформить то, что точка не успеет собрать.
Через три месяца: оформление сократилось с четырёх минут до сорока секунд, доля отмен — с 12% до 2,5%, обращения в поддержку точки упали втрое, звонки «готов ли заказ» практически прекратились. Одной смены кассира стало достаточно на утренний пик, без подменного оператора. Повторные предзаказы выросли до 34% — гости возвращаются за тем же тортом в тот же интервал.
Что сделали иначе на втором этапе
Первая версия отдавала заказы в общую очередь, и кухня в пик получала десятки позиций разом — отмены вернулись. На втором этапе мы ограничили число заказов на точку в час, ввели шаблоны частых сборок и срок автоматического подтверждения. Если точка не подтверждает заказ вовремя, интервал закрывается, а гость сразу видит альтернативное время.
Чем отличается единая кодовая база от двух нативных приложений?
Единая кодовая база — это один исходник, из которого собираются две сборки приложений под iOS и Android; нативный вариант — два независимых проекта на разных языках. На старте разница почти незаметна: обе схемы дают рабочий продукт. Она проявляется в эксплуатации, когда начинаются регулярные обновления, разбор падений и выходы новых версий операционных систем.
Скорость выпуска обновлений определяется числом релизных контуров. Правка сценария заказа в единой базе проходит один цикл проверки и в один выпуск уходит на обе платформы. В случае с двумя нативными сборками ту же правку делают дважды, тестируют дважды и выпускают по отдельному графику: пока вторая платформа ждёт выпуска, пользователи видят разное поведение приложения и присылают разные обращения в поддержку.
Доступ к функциям устройства — обратная сторона этого компромисса. Камера, уведомления, оплата, геолокация, биометрия и сканирование штрихкодов закрываются общим слоем почти без потерь. Сложнее с фоновой работой, внешними сканерами и датчиками, виджетами на домашнем экране, оплатой через встроенный чип: под каждую платформу пишется нативный модуль, а интерфейс к нему ведёт общий код. Поэтому правильный вопрос не «можно ли это сделать», а какая доля пользовательских сценариев лежит за пределами общего слоя.
Стоимость поддержки двух веток растёт нелинейно: две очереди обновлений, двойной прогон регрессии на парке устройств, отдельные исправления под правила каждого магазина приложений. Единая база держит одну очередь работ, но концентрирует риск — сбой в общем модуле уходит сразу на обе платформы. Отсюда обязательные автотесты на критичные пути и поэтапная раскатка выпуска.
Практический критерий выбора простой. Если ядро продукта — витрина, заказ и программа лояльности, выигрывает единая кодовая база: обновления выходят чаще, а поддержка не двоится. Если ценность в редком оборудовании и глубокой работе с периферией, часть логики всё равно остаётся нативной, и получается гибрид с общим слоем на бизнес-логику. Мы считаем долю кода, которая реально переиспользуется в обоих приложениях, и по этой цифре предлагаем схему.
Интеграции и оплата: что уточняют до старта разработки
До оценки фиксируем четыре технических узла: с какой учётной системой стыкуется приложение, какими способами принимаем оплату, как считаются баллы и штампы, и что происходит с заказом между самовывозом и доставкой курьером. Пока эти точки не описаны, смета остаётся диапазоном, а не планом работ.
Проверяем не по документации, а на стенде: копия меню и склада, тестовые заказы, прогон отмен и возвратов. Так видно, какие расхождения вылезут в первый месяц работы точки, — их дешевле закрыть до релиза, чем после запуска.
Приложение будет видеть остатки в реальном времени?
Если учётная система отдаёт данные через программный интерфейс, витрина обновляется с задержкой в несколько минут — этого хватает, чтобы не продавать проданное. При обмене выгрузками синхронизацию делаем чаще, а позиции с нулевым остатком по правилу уводим в «под заказ» или скрываем из меню конкретной точки.
Какие способы оплаты реально подключить?
Онлайн-оплата картой и по QR-коду, оплата при получении, списание баллов и подарочных сертификатов. Возврат по отменённому заказу проходит тем же путём, что и платёж, — это закладываем в логику статусов сразу, иначе отмены придётся закрывать вручную в кассе.
Где хранится программа лояльности?
Баллы и штампы надёжнее держать в учётной системе точки, а не внутри приложения: тогда касса и витрина видят один баланс, а iiko и аналогичные решения остаются единственным источником правды. Если учёт ведётся в таблицах, выносим лояльность в отдельный сервис с журналом операций и защитой от двойного списания.
Обсудим задачу: что прислать для оценки и плана
Чтобы оценка разработки приложения была предметной, а не «вилкой от и до», нам нужны вводные по процессам пекарни. Мы не просим готовить техническое задание — достаточно описать, как заказы живут сейчас, и указать, что из этого должно перейти в приложение. По этим данным собираем план работ с этапами, сроками и составом работ.
- Описание точки и точек продаж: формат (пекарня с посадкой, витрина, островок), часы работы, среднее число заказов в смену, самовывоз и доставка — от этого зависит логика слотов и загрузки кухни.
- Текущие каналы заказов: телефон, мессенджеры, соцсети, агрегаторы. Важно понять, где какой объём и где теряются заказы — в пиковые часы, при подтверждении или на оплате.
- Учётная система: касса, склад, рецептуры, программа лояльности. Нужно знать, есть ли выгрузка меню и остатков и можно ли отдавать статусы заказа обратно в учёт.
- Меню и примеры позиций: категории, состав, аллергены, варианты размеров и упаковки, сезонные и предзаказные позиции.
- Роли сотрудников: кто принимает заказ, кто собирает, кто подтверждает готовность и меняет статус — так проектируем права доступа и уведомления.
- Программа лояльности: баллы, купоны, скидки по дням, персональные предложения. Определяет, что переносим из текущих механик.
- Ограничения и ориентиры: сроки запуска, желаемый состав первой очереди, примеры приложений, которые нравятся или не нравятся.
Опишите задачу в свободной форме — этого хватит, чтобы вернуться с оценкой и планом работ.
