Поддержка и развитие foodtech-приложения по SLA

Чем поддержка foodtech отличается от поддержки обычного приложения

Поддержка приложения банка или обычного интернет-магазина — это плановый процесс с предсказуемой нагрузкой и редкими по-настоящему критическими инцидентами. Поддержка foodtech — другая дисциплина. Несколько отличий, которые меняют требования к команде, режиму и SLA:

• Часы пик критичны. Пятница-суббота с 19:00 до 23:00, обед в будни, ужин. Падение приложения в эти часы — это не «зайдут позже», а сорванный заказ, уход клиента к конкуренту и компенсация. Каждая минута простоя в час пик у крупной сети — это сотни тысяч рублей упущенной выручки.
• Технические работы в час пик невозможны. Релизы и обновления инфраструктуры — только в спокойные часы: ночь со вторника на среду, раннее утро. Любое окно в час пик клиент воспринимает как сбой.
• Сложная связка интеграций. POS (iiko / R-Keeper / Poster), эквайринг, агрегаторы (Яндекс.Еда, Купер), карты, CRM, push, аналитика — у каждого свой график доступности, свои лимиты запросов и обновления. Поддержка foodtech-приложения — это поддержка целой экосистемы.
• Регуляторика. ЕГАИС (если есть алкоголь), 152-ФЗ (персональные данные клиентов), требования платёжных систем. Любой инцидент с оплатой или биометрией — потенциальный регуляторный вопрос.
• Сезонность и кампании. Новый год, 14 февраля, 8 марта, лето — всплески нагрузки на 50–300%. К ним готовимся заранее: нагрузочное тестирование, разогрев кешей, усиление дежурной смены.
• Быстрая итерация под акции. Маркетинг запускает «−30% на пиццы в субботу» — значит, к субботе должны быть готовы баннер в приложении, цена в POS и сегменты для push. Это спринт за 3–5 дней, а не доработка по бэклогу через две недели.

Общий гайд по SLA-моделям — на странице «SLA-поддержка: что это и как составить». Здесь — foodtech-специфика.

Какой SLA нужен под ваш формат

«Foodtech-приложение» — собирательное понятие: под разные продукты нужен разный SLA и режим работы поддержки. Окончательный режим выбираем после аудита продукта.

Главные точки отказа foodtech-приложения

В foodtech-приложении 6–8 критических узлов, на которые приходится 80–90% инцидентов. Поддержка должна знать их в лицо.

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

Что делает дежурный в первые 15 минут

Сценарии для четырёх самых частых сбоев в часы пик — что делает дежурный смены.

В час пик отвалилась оплата

0–5 мин. Фиксируем инцидент по алерту мониторинга или жалобе клиента, проверяем графики ошибок на платёжном шлюзе и статус-страницы банков-эквайеров.

5–15 мин. Если сбой на стороне эквайера — переключаем на резервный канал оплаты; в оформлении заказа показываем «оплата временно недоступна, попробуйте другой способ»; уведомляем пользователей.

15+ мин. Эскалация на вторую-третью линию, разбор инцидента после восстановления.

Расхождение остатков с реальной кухней

0–5 мин. Алерт: товар «в продаже» в приложении, но кухня показывает «закончилось». Проверяем, пришло ли обновление от iiko.

5–15 мин. Принудительная синхронизация через iikoCloud API; если расхождение системное — временно отключаем продажу позиции и шлём алерт управляющему точки в DSR-приложение.

Потеря push после обновления iOS / Android

0–15 мин. Проверка тестового push после релиза ОС. Если сломался — быстрая сборка с обновлением SDK push, выпуск на тестовые устройства.

15–60 мин. Релиз в стор с ускоренной проверкой; параллельно обходное решение — SMS-уведомления для критичных статусов до публикации.

Обрыв связи с агрегатором

0–5 мин. Алерт от мониторинга API партнёра — определяем, наш это сбой или партнёрский.

5–15 мин. Если партнёрский — фиксируем простой в логах, переключаем поток заказов на собственный канал доставки, уведомляем клиентов.

Плейбук под конкретную сеть готовим при подключении к поддержке — это часть Discovery.

Развитие приложения после релиза

Поддержка — это не только «фиксим баги», а полноценное продуктовое развитие. В нашем кейсе KFC DSR за год работы в продакшене мы выпустили 58 фич — это темп федеральной сети с регулярным релизом. Что входит в развитие:

• Регулярный план развития. Спринты по 2 недели, релиз каждые 2–4 недели. Без этого «поддержка» вырождается в «исправление багов раз в квартал».
• A/B-тесты под акции. Перед запуском маркетинговой механики — тест на 10–20% аудитории. Снижает риск раскатить решение с отрицательным эффектом на всю базу.
• Сезонные оптимизации. Перед пиковыми периодами — нагрузочное тестирование, разогрев кешей, дополнительные дежурные. Ждём тройную нагрузку — заранее усиливаем инфраструктуру.
• Оптимизация под часы пик. Каждый месяц профилируем: где приложение медленнее всего в пятницу вечером, какие запросы лишние. Постоянная микро-оптимизация даёт суммарно +20–30% к скорости за год.
• Поддержка новых версий iOS / Android. Каждые 6 месяцев — новые версии ОС с новыми требованиями к фоновым задачам, push, геолокации, биометрии. Обновление под них — обязательная часть поддержки.
• Интеграции под новых партнёров. Новая площадка доставки, новый POS или эквайер — это новая интеграция в составе развития, а не отдельный проект с нуля.
• Внедрение AI в разработку. Услуга AI-внедрение в разработку применима и в поддержке — сжимает цикл «фича → продакшен» примерно вдвое и помогает удерживать темп релизов.

В реальных foodtech-проектах поддержка и развитие занимают 60–70% жизненного цикла продукта по времени и бюджету за 3–5 лет после релиза. Если команда исчезает после релиза — продукт теряет темп и через год отстаёт от рынка.

SLA-показатели специально для foodtech

Базовые метрики (время реакции, время устранения, доступность) мы адаптируем под отраслевые особенности.

• Доступность — отдельно для часов пик и спокойных часов. Доступность 99,9% — это около 43 минут простоя в месяц, но 5 минут в пятницу вечером дороже, чем 30 минут в среду в 4 утра. Для крупных сетей SLA пишется по двум показателям: общая доступность плюс доступность в часы пик (99,95–99,99%).
• Время реакции для платёжных инцидентов жёстче. Любое падение оплаты — критический инцидент без обсуждения, реакция 5–10 минут даже в режиме 12×7. Баги интерфейса — обычный приоритет.
• Время устранения для интеграций — мягче по вине партнёра. Если сбой на стороне внешнего API (Яндекс.Еда, эквайер, карты), наш отсчёт начинается с обнаружения и работы над обходным решением, а не с восстановления чужого API.
• Релизные сроки. Foodtech требует темпа: новая фича должна выходить в продакшен за 2–4 недели, а не за 3–6 месяцев. Срок фиксируем в соглашении.
• Реактивность под маркетинг. «Акция должна быть в приложении к субботе» — это не классический инцидент, но критичная часть foodtech-поддержки. Согласуем как отдельный показатель «время от запроса маркетинга до фичи в продакшене» — обычно 3–5 рабочих дней для базовых акций.

Кейсы Surf

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

Юнит-экономика поддержки foodtech

Стоимость поддержки кажется большой статьёй бюджета — на крупной сети от 600 тыс. до 1,5 млн ₽/мес. Считаем окупаемость.

• Стоимость инцидента в час пик. Для федеральной сети с месячным оборотом доставки 100–300 млн ₽ один час простоя в пятницу с 19:00 до 20:00 стоит порядка десятков миллионов рублей упущенной выручки. Один такой инцидент за год равен годовому бюджету поддержки 24/7.
• Меньше оттока после провалов. По публичным исследованиям удержания, после двух неудачных попыток заказа клиент уходит к конкуренту с вероятностью 60–80%. Качественная поддержка минимизирует такие моменты.
• Темп развития = темп выручки. Сеть с темпом 30+ новых фич в год растёт быстрее, чем сеть с 5–10 фич: это измеримый прирост к среднему чеку и частоте посещений.
• Меньше технического долга. Без поддержки технический долг накапливается лавинообразно: через 2–3 года продукт требует полного переписывания, а это в 3–5 раз дороже постоянной поддержки.
• Экономия на штатной команде. Содержать собственный дежурный контур 24/7 из 4–6 разработчиков обходится в 3–5 млн ₽/мес. Поддержка по SLA обычно дешевле и предсказуемее.

Модели поддержки под foodtech

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

Как подключаем поддержку

Стек мониторинга и инструменты

Команда: аккаунт-менеджер / тимлид поддержки (единая точка контакта), дежурные смены (1–3 на смену в зависимости от SLA), первая линия (диагностика), вторая линия (разработчики), третья линия (архитекторы для критических инцидентов), продакт-менеджер (план развития), QA, DevOps, а для модели выделенной команды — постоянная команда разработки 5–15 человек на полной загрузке.

Стоимость и режимы

Что влияет на бюджет: режим работы (8×5 против 24×7), сложность продукта (одно приложение против супераппа с 5+ mini-apps), глубина SLA (доступность 99% против 99,99%), объём развития (только инциденты против 30+ фич в год), мультитенант и мультибренд, нагрузочное тестирование перед пиками. По ориентирам общего гайда SLA переход с 8×5 на 12×7 добавляет 30–50% к стоимости, на 24×7 — 80–150%; для сложного foodtech-проекта — ещё 50–100%. Финальная цена согласуется на Discovery. Что бывает сразу после релиза MVP — на странице MVP foodtech.