Камеры, которые видят, что гость заскучал: кейс видеоаналитики в ресторане

Этот кейс мы вспоминаем чаще других, потому что он хорошо показывает, чем «камеры для безопасности» отличаются от «камер, которые приносят деньги». Заказчик — городской ресторан на 22 стола в центре, средний чек выше рынка, кухня, к которой не придраться. И при этом регулярная история: в пятницу вечером зал забит под завязку, а выручка растёт совсем не так, как должна была бы при таком потоке.

Управляющий сформулировал боль одной фразой: «У меня аншлаг, а ощущение, что я теряю деньги прямо в зале, и я не вижу — где». Камеры в ресторане стояли — шесть Hikvision, писали архив, который открывали ровно один раз: когда нужно было разобрать спор с гостем или недостачу. То есть классическое видеонаблюдение, которое стоит денег и не отдаёт ничего, кроме записи «на всякий случай».

Что именно мы решили измерить

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

Первое — заполняемость зала по часам и дням недели (occupancy). Не «было много народу», а конкретно: в пятницу с 20:00 до 22:00 занято 90% столов, во вторник в это же время — 35%. Это основа для управления сменами и бронями.

Второе — средняя длительность визита (dwelling time). Сколько в среднем живёт стол от посадки до ухода. Если по пятницам гости сидят по 2 часа 40 минут вместо привычных полутора, в час пик это прямой недобор оборачиваемости: те же столы могли бы обернуться ещё раз.

Третье, и самое ценное — Speed of Service, скорость обслуживания. Сколько проходит от посадки гостя до того, как ему принесли меню, и от заказа до подачи. Именно здесь, как мы и подозревали, прятались утекающие деньги.

Как это устроено внутри

Под капотом — связка из трёх вещей, и ни одна из них не распознаёт лица. Это принципиально: мы работаем с силуэтным трекингом, без биометрии. Каждому вошедшему система присваивает анонимный ID и ведёт его по залу, «сшивая» переходы между камерами. Кто этот человек — система не знает и знать не должна; для 152-ФЗ это чистая ситуация, и гостям мы ничего, кроме обычной таблички о видеонаблюдении, не должны.

Дальше — разметка зон. На видеопотоке мы вручную обвели виртуальные области: каждый стол, барную стойку, кассовую зону, вход. Теперь система понимает не «пиксели», а «стол №4» и «зона бара».

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

Для Speed of Service таймлайн выглядит так: точка А — гость сел (зона стола стала занятой), точка Б — официант подошёл с меню, точка В — принесли первые блюда или напитки. Между этими точками — секунды, которые и есть качество сервиса. Мы задали пороги: если между «сел» и «подошли с меню» прошло больше 4 минут, администратору в Telegram падает короткое сообщение — «Стол №7 ждёт меню 4 минуты». Если горячее не несут дольше 25 минут — отдельный красный флаг.

Грабли, о которых редко пишут

Теперь честная часть, ради которой такие кейсы и стоит читать. Подсчёт людей на входе и тепловые карты — это давно коробка, такое умеют и Ivideon, и Macroscop, и TRASSIR. А вот глубокая аналитика стола упирается в физику, и первый пилот это показал быстро.

Перекрытия (occlusion). Гость загораживает собой тарелку, официант встаёт спиной к камере — и событие теряется. Две из шести камер висели «для красоты», под низким углом вдоль зала, и стол в дальнем ряду они видели через спины сидящих. Эти две камеры мы перевесили выше и развернули почти вертикально вниз, на посадочные зоны. Это был единственный «капитальный» расход проекта — остальное оставили как есть.

Распознавание посуды. Отличить пустую чашку от полной по неудачному ракурсу нейросеть толком не может, и закладываться на это — ошибка. Поэтому мы почти не опираемся на «состояние посуды» как на триггер. Гораздо надёжнее считать факты и интервалы визитов официанта к столу: подошёл, отошёл, сколько не появлялся. По этим интервалам система и понимает, что стол «осиротел».

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

Связка с iiko — где спрятались деньги

Самое интересное началось, когда мы сопоставили видео с кассой. У ресторана была iiko, и мы стянули логи POS: время открытия чека по каждому столу. Дальше простая, но безжалостная сверка — «когда стол занят по видео» против «когда открыт чек».

И вот тут вылезло то, что управляющий чувствовал, но не мог доказать. По пятницам в час пик средний разрыв между посадкой гостя и открытием чека составлял 11–14 минут. То есть гость уже сидит, уже готов заказывать и тратить, а к нему просто не успевают подойти — официантов физически не хватает именно в этот пик. Архив видеонаблюдения это «видел» всё время, но никто никогда не складывал две записи рядом.

Что в итоге получил ресторан

Никакого волшебства, обычная управленческая работа — но теперь по цифрам, а не по ощущениям. Под выявленный пятничный пик добавили одного официанта и перекроили зоны ответственности. Разрыв «посадка → чек» в час пик ужался до 4–5 минут.

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

• среднее время ожидания меню в час пик — с 11–14 до 4–5 минут;
• оборачиваемость столов в пятницу-субботу — плюс примерно 8% (те самые «лишние» посадки за вечер);
• средний чек — плюс около 12%, в основном за счёт вовремя предложенных напитков и десертов: система подсказывала официанту, у какого стола пустые бокалы и давно не было контакта.

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

Сколько это стоит и как мы это делаем

Несколько слов про деньги, потому что вопрос всегда один и тот же. Ставить новые камеры ради такой аналитики обычно не нужно — мы заходим поверх существующих IP-камер по RTSP, как и на остальных проектах. В этом кейсе из шести камер хватило всех шести, две просто перевесили. Для зала на 15–20 столов как раз нужно 6–8 камер с приличным разрешением, направленных на посадочные зоны.

Аналитику мы развернули на небольшом сервере прямо в ресторане — видео и метрики не уходят в чужое облако, это и спокойнее по закону, и дешевле в эксплуатации. По нашему опыту, сложные триггеры вроде Speed of Service обходятся в районе 4 000–7 000 ₽ в месяц за активную камеру, а на заведение целиком чаще берут комплексную подписку. Точную цифру мы всегда называем после пилота — когда уже видно, сколько камер реально задействовано и какие сценарии включены.

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

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