Разработка мобильного приложения для кейтеринга и выездного обслуживания

Чем кейтеринг отличается от ресторана и доставки

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

Это не «доработать приложение ресторана кнопкой выезд», а отдельный класс продуктов. Для основной ресторанной услуги — на странице приложения для ресторана, для корпоративного питания в столовых — на странице приложения для столовой.

Какие форматы кейтеринга мы закрываем

Под «кейтерингом» живут разные продукты с разной экономикой и набором функций. Под бизнес обычно выбирают 1–2 приоритетных формата для MVP, остальные добавляют поэтапно.

Главный пользователь — кабинет корпоративного клиента

В кейтеринге главный пользователь приложения — не конечный гость, а менеджер компании-заказчика. Без удобного кабинета корпоративного клиента (B2B-кабинета) весь продукт держится на личных переписках менеджера с клиентом — и при росте сети это ломается. Что должно быть в кабинете:

• Профиль компании — реквизиты, ответственные лица, договоры, кредитные лимиты.
• Календарь поставок и событий — что заказано на ближайший месяц, с возможностью перенести, отменить или расширить.
• Конструктор меню — выбор блюд из каталога с учётом аллергий, диет, халяль / кошер для отдельных групп сотрудников; сохранение избранных меню для повторного заказа.
• Состав гостей и сотрудников — список с предпочтениями, который клиент обновляет сам.
• Сметы и счета — расчёт стоимости события, выставление счёта, оплата картой или с отсрочкой по договору.
• Закрывающие документы — акты и накладные через ЭДО (Контур, СБИС, Диадок).
• История событий — все прошлые заказы, оценки гостей, рекомендации.
• Уведомления и эскалации — когда что-то идёт не по плану, клиент видит проблему сразу, а не в день события.

Подход к интерфейсу кабинета — на странице foodtech-UX. Эта же модель «клиент управляет заказом без звонка в кол-центр» — основа нашего кейса Performance Food.

Календарь событий и заявки на дни вперёд

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

• Календарь занятости компании — все принятые заявки на день, неделю, месяц; видно, какие даты свободны.
• Календарь бригад и шеф-поваров — кейтеринг это люди, а не только кухня; если бригада занята, дата блокируется.
• Календарь оборудования — фургоны, термосумки, банкетная посуда, мебель ограничены в количестве; один комплект на 200 персон не может быть в двух местах сразу.
• Конструктор заявки — клиент выбирает дату, число гостей, формат и локацию, система проверяет доступность ресурсов и формирует предварительную смету.
• Депозит и предоплата — бронирование даты с депозитом 20–50%, возврат при отмене за оговорённый срок.
• Напоминания — за 7, 3 и 1 день до события push клиенту и менеджеру.
• Дегустация и согласование меню — отдельный шаг до подтверждения, особенно для свадеб и крупных событий.
• Дедлайны на изменения — за 48 часов до события менять меню нельзя; это фиксируется в договоре и в приложении.

Админка на месте события

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

• Чек-лист подготовки — бригада приехала, оборудование разгружено, термосумки на 2–6 ℃, столы накрыты; с фото-подтверждением.
• Список персонала на смене — кто работает, кто опоздал, замены.
• Расход алкоголя — при интеграции с ЕГАИС реальное списание по факту наливов.
• Расход блюд — сколько порций подано, сколько осталось; если что-то заканчивается — push кухне в офисе.
• Связь с клиентом — прямой канал к менеджеру корпоративного клиента или агентства.
• Инциденты — гость с аллергией просит блюдо вне меню, гость опоздал, у официанта порвалась рубашка — фиксация в логе.
• Закрытие события — подпись клиента на iPad-кассе, фото-отчёт, статус «событие закрыто».

По логике это родственник DSR-приложения для управляющего — те же принципы (mobile-first, чек-листы, дашборд показателей), но привязка к конкретному событию, а не к точке.

Расчёт меню по составу и числу гостей

Самая сложная часть кейтеринга — собрать меню под конкретную аудиторию. На свадьбе из 200 гостей могут быть 30 вегетарианцев, 20 мусульман, 10 детей и 5 человек с аллергией на орехи. Если просто «принести курицу с гарниром» — продукт не работает. Алгоритм автоматического расчёта:

1. Базовое меню по числу гостей — на 200 гостей столько-то кг основных блюд, закусок и напитков.
2. Сегментация по предпочтениям — 30 вегетарианцев → 30 вегетарианских порций, 20 халяль → блюда с сертификатом, 5 с аллергией на орехи → отдельная корзина без орехов.
3. Запас на 5–10% — гости часто берут не свою порцию, а соседскую; алгоритм считает разумный запас.
4. Сезонность и доступность сырья — если в меню свежий лосось, а на дворе март, цена скачет в 1,5–2 раза; алгоритм показывает альтернативы.
5. Расчёт сметы — себестоимость + маржа + транспортировка + работа бригады = итоговая цена для клиента.
6. Согласование — конструктор отправляет меню клиенту, тот корректирует через приложение и утверждает.

На зрелых проектах добавляется AI-рекомендация меню по истории успешных событий: «для свадеб на 150–250 гостей в Подмосковье чаще всего выбирают такое-то меню». Подробнее про подход — на странице машинного обучения.

Холодовая цепь выездного обслуживания

Кейтеринг — это «приготовили на одной кухне, привезли на другое место, сервировали через 2–6 часов». Если холодовая цепочка прерывается, гости получают отравление, а бизнес — иск и потерю репутации. Приложение должно держать контроль:

• Температурные датчики в фургонах — данные телеметрии в реальном времени по каждому фургону; при выходе за 2–6 ℃ для холодных блюд или 60+ ℃ для горячих — алерт водителю и менеджеру.
• Чек-лист загрузки — бригадир подтверждает в приложении: «контейнеры загружены, фото», «температура измерена».
• Маршрут под холодовую цепь — строится так, чтобы общее время вне холодильника не превышало норматив; те же принципы, что на странице маршрутизации курьеров, применимы к фургонам.
• Документы качества от поставщиков — фиксируются в карточке события.
• Электронные журналы ХАССП — по требованиям ТР ТС 021/2011, критичная часть соответствия требованиям пищевой безопасности.

Этот слой выводит компанию из категории «делаем еду на выезд» в «делаем еду на выезд с подтверждённым качеством» — сильный аргумент в продажах корпоративным клиентам.

Интеграции

Кейсы Surf

Мы создаём foodtech-продукты для лидеров рынка — от стартапов до федеральных сетей. Несколько релевантных проектов из портфеля (полный — на странице foodtech-практики):

Юнит-экономика кейтеринга

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

• Высокий средний чек корпоративного клиента. Одна компания с дневной поставкой обедов на 100 сотрудников — это 30–60 тыс. ₽ в день, 6–12 млн ₽ контракта в год. Одна VIP-свадьба на 200 гостей — 1–3 млн ₽ за событие. По сравнению с доставкой частным клиентам при чеке 1–2 тыс. ₽ это другой класс ценности клиента.
• Повторяемость корпоративных клиентов. Контракт на год — это 240+ рабочих дней с поставками; один удержанный клиент — миллионы рублей в месяц без затрат на привлечение.
• Снижение операционных потерь. Без приложения 5–15% событий идут с расхождениями (не то меню, опоздание, неверный счёт); с приложением — снижение до 1–2%. Каждая ошибка — это репутационный риск и компенсация.
• Удержание корпоративных клиентов. Клиент с удобным кабинетом не уходит к конкуренту просто из-за «менеджер не берёт трубку»: удержание 85–95% год к году против 60–70% без такого инструмента.

На сети с месячным оборотом 15–30 млн ₽ кастомное приложение окупается за 6–12 месяцев.

Кастомная разработка или готовый конструктор

На рынке есть готовые конструкторы приложений и общие foodtech-разработчики. У каждого подхода свои сценарии.

Для маленькой компании с 5–10 событиями в месяц конструктор справится. Для сети с системными корпоративными контрактами на десятки миллионов рублей — кастомное приложение сразу: важна интеграция с 1С:Кейтеринг, ЭДО и ЕГАИС, и владение данными клиентов.

Процесс разработки

Стек технологий

Команда: продакт, бизнес-аналитик (карта процессов кейтеринга и согласований), UX/UI-дизайнер (кабинет клиента, админка на месте, мобайл), 1–2 мобильных разработчика Flutter, 1–2 backend-разработчика и инженер интеграций (POS + ЭДО + ЕГАИС), frontend-разработчик (веб-кабинет), QA, DevOps.

Стоимость и сроки

Что влияет на бюджет: глубина кабинета клиента (базовый или с CRM, ЭДО и бухгалтерией), холодовая цепь (телеметрия в фургонах) и журналы ХАССП, расчёт меню по составу гостей (базовый алгоритм или с AI-рекомендацией), число интеграций (POS / 1С:Кейтеринг / ЭДО / ЕГАИС / маршрутизация / эквайринг), мультибренд в одной кодовой базе (как в Performance Food), стек (Flutter или нативная пара iOS+Android). Если нужно проверить узкую гипотезу за 2–3 месяца — рассмотрите MVP foodtech. Сопровождение после запуска — отдельно, по модели поддержки foodtech-приложения по SLA.