Как синхронизировать стоп-листы между POS, сайтом и приложением

Стоп-лист кажется мелочью до первой отмены оплаченного заказа. Для гостя это срыв планов, для операций — звонки, компенсации и минус в рейтинге. Синхронизация — операционный процесс с измеримым SLA, а не галочка в ТЗ.

Назначьте источник истины

Изменение доступности делает смена или склад в POS — сайт и приложение только отражают состояние. Параллельное редактирование в админках витрин создаёт расхождения уже в первую неделю.

На практике достаточно одной кнопки «стоп» на кассе или планшете повара — если интеграция доставляет событие за 1–2 минуты.

Разделите блюдо и модификатор

Недоступность бывает у всего блюда, размера, добавки или ингредиента. Адаптер должен переводить ограничения POS в структуру каталога приложения.

Комбо и группы

• обязательная группа модификаторов целиком недоступна;
• опциональная добавка скрыта, блюдо остаётся;
• стоп ингредиента блокирует несколько позиций — нужен каскад.

Учитывайте точку и время

Одна позиция доступна на ул. Ленина и в стопе на пр. Мира. Храните location id, timestamp и TTL временного стопа. Гостю показывайте простой статус, причину — оператору.

Спроектируйте кеш и отказоустойчивость

Краткий сбой POS не должен валить витрину, но бесконечный кеш продаёт недоступное. Задайте TTL, safe-mode «только подтверждённое меню» и очередь догоняющих обновлений.

1. event push при изменении;
2. polling каждые N минут как страховка;
3. ручной master switch при аварии.

Контролируйте качество синхронизации

Метрики: p95 задержки, число заказов с недоступной позицией, ручные отмены по стоп-листу. Алерт не «ошибка API», а «точка X, блюдо Y, 12 минут рассинхрон».

Инциденты и эскалация

Регламент: кто дежурит, когда эскалировать в IT, когда временно закрыть канал. Один понятный playbook снижает время простоя с часов до минут.

Для dark kitchen стоп ингредиента должен закрывать все витрины брендов на одной кухне. Иначе соус в стопе в одном приложении остаётся доступен в другом.

Раз в квартал — учение: стоп тестовой позиции и замер времени до скрытия на всех каналах.

Логируйте каждое изменение стоп-листа с user id и причиной — это ускорит разбор инцидентов с гостями.

При акциях «только delivery» проверяйте, не открывает ли стоп-лист случайно блюда, которые в зале остаются доступны — правила channel-specific стопов должны быть в спецификации.

Для сети с franchisee важно право «кто может ставить стоп»: только управляющий точки или также центральный офис при force majeure.

Для marketplace-схем с несколькими ресторанами на одной витрине стоп должен быть addressable по merchant id — иначе стоп одной кухни закроет чужой каталог.

Выведите на дашборд операций p99 задержки стоп-листа, а не только среднее — редкие минутные лаги создают самые дорогие отмены.

При ночном обновлении меню отделяйте rollout каталога от rollout стоп-листов — совмещение повышает риск «пустой» витрины утром.

Связанные страницы