Скидки, купоны и программы лояльности

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

Скидки с временным окном

Самый простой тип акции, с которого начинает большинство сетей: скидка, действующая только в определённый период. Например, 20% на бизнес-ланч, акция на пиццу по вторникам или надбавка за бранч в выходные.

Настраивается в административной панели для каждой скидки отдельно:

• День недели и временной интервал — например, пн–пт, 11:00–14:00.
• Применимые категории — только «Ланч», только «Пицца» или любые другие.
• Минимальная сумма заказа — порог, выше которого действует скидка: это увеличивает сумму чека, а не просто срезает маржу с небольших заказов.
• Суммируемая или эксклюзивная — можно ли совмещать скидку с временным окном с купонными кодами.

Скидки применяются автоматически в течение действующего периода — гостям не нужно вводить код, а персоналу не нужно помнить правила.

Купонные коды

Для email-кампаний, публикаций в социальных сетях, партнёрских раздач или ситуаций, когда нужно вручить код расстроенному гостю. Доступны два формата:

• Одноразовые коды — каждый код используется для одного заказа. Генерируются пакетами и привязываются к кампании, чтобы отслеживать, какой канал дал конверсию.
• Многоразовые коды — один код, множество заказов. Типичный пример — кампании в стиле «WELCOME10».

Механика скидок гибкая:

• Процент от суммы (например, 15%) или фиксированная сумма (например, €5).
• Белый список товаров — скидка применяется только к определённым позициям.
• Минимальная сумма для активации.
• Защита от повторного использования одним гостем, чтобы один человек не исчерпал бюджет кампании.
• Дата истечения — коды автоматически деактивируются.

Массовая генерация для email-кампаний — создание сотен уникальных одноразовых кодов для рассылки через CRM — находится в активной разработке. На сегодняшний день многоразовые купоны закрывают большинство потребностей; массовые одноразовые коды — это пробел, который мы закрываем в первую очередь.

Карты лояльности (на базе POS)

Если ваш POS уже ведёт программу персональных карт, Fooodo подключается к ней напрямую. Актуальный пример для R-Keeper — Vilniaus Šeima для Čili Pizza; другие коннекторы POS предоставляют ценообразование по лояльности аналогичным образом через контракт коннектора.

• Гость, привязавший карту лояльности, видит в меню цены по программе лояльности, а не стандартные.
• Привязка карты выполняется один раз в профиле гостя и сохраняется между визитами.
• Ценообразование поступает из вашего POS. Fooodo не переопределяет его — он отображает то, что уже задано вашей карточной программой.

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

Предпочтения продуктов (фильтры гостей)

Лёгкий инструмент тегирования для организации меню в соответствии с тем, как гости делают выбор: Веганское, Без глютена, Острое, Рекомендуемое, Ланч-комбо — любая терминология, подходящая вашей аудитории. Каждый тег создаётся один раз на уровне компании, получает переводимое название (чтобы один и тот же тег корректно отображался в любой локали гостя) и затем применяется к продуктам из административной панели.

Гости видят предпочтения в виде фильтров-чипов в меню — нажав «Веганское», они получают список только отмеченных позиций. Это же тегирование используется для отображения рекомендуемых категорий на уровне конкретного ресторана. Теги управляются оператором, список продуктов для каждого тега задаётся явно — ничего здесь не выводится автоматически моделью.

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

Главная страница меню (Рекомендуемое и Популярное)

Верхняя часть меню может начинаться с блюд, а не с плоского списка, и адаптируется к тому, кто смотрит. Рядом с избранным самого гостя расположены два блока, управляемых оператором:

• Рекомендуемое — список, составленный оператором вручную, настраивается для каждого ресторана. Ваши фирменные блюда, текущие акции, позиции, которые вы хотите продвигать, в нужном вам порядке. Этот же список используется как запасной вариант для подсказки «что-то забыли?» на кассе.
• Популярное — реальные хиты продаж, вычисляемые автоматически на основе выполненных заказов за настраиваемый период (по умолчанию 30 дней). Операторы выбирают, из каких категорий формировать рейтинг и сколько продуктов показывать в каждой; сами блюда определяются данными и пересчитываются по мере изменения продаж, поэтому блок никогда не устаревает.

Над этими блоками авторизованный постоянный гость также видит свои Избранные — блюда, которые он отметил сердечком и недавно заказывал (см. Избранное гостей ниже) — так что первый визит и постоянный гость встречают разные меню. Рекомендуемое и Популярное настраиваются из административной панели; избранное и персонализация на основе истории работают автоматически, без панели оператора. Пошаговая инструкция по составлению Рекомендуемого и настройке Популярного находится в Руководстве оператора.

Перекрёстные продажи на кассе (запланированные апселлы)

Когда гость открывает кассу, Fooodo предлагает до пяти рекомендованных позиций рядом с корзиной. Рекомендации формируются через три уровня, по порядку:

1. Что обычно заказывает этот гость. Если гость авторизован и имеет историю повторных покупок за 30 дней в этом ресторане, эти продукты показываются первыми.
2. Запланированная акция, настроенная оператором. Если личной истории нет, Fooodo выбирает активную запланированную акцию для текущего дня недели и временного окна в этом ресторане.
3. Хиты продаж как базовый вариант. Если ничего другого не применимо, список рекомендаций возвращается к текущим бестселлерам ресторана.

Запланированные акции настраиваются для каждого ресторана из административной панели. Каждая акция содержит:

• День недели и временной интервал — например, пн–пт, 11:30–14:00. Время интерпретируется в местном часовом поясе ресторана.
• Применимые категории — привяжите акцию к «Напиткам», «Десертам», пользовательской группе «Добавки к ланчу» или любой другой категории — чтобы дневной апселл не оказался рекомендацией вина.
• Список продуктов с явным порядком — операторы сами решают, какие продукты показывать, в каком порядке и по какой цене.

Позиции, уже находящиеся в корзине, деактивированные в ресторане и позиции без цены автоматически исключаются — гости никогда не видят «нет в наличии» или дублирующихся рекомендаций.

Суть не в AI — а в том, чтобы дать оператору тот же апселл-запрос, который сделал бы хороший официант, но стабильно, за каждым столиком, без необходимости инструктировать персонал. Уровень истории — это дополнительная персонализация по желанию, а не основная механика.

Триггеры на уровне позиции в корзине — «когда в корзину добавляется Маргарита, предложить Колу за €X» — включены в дорожную карту как дополнение к модели запланированных акций, а не замена ей.

Всплывающие изображения

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

Это намеренно ограниченный инструмент — не система управления кампаниями, не сегментированные сообщения, не A/B-тестирование. Цель — дать операторам быстрый рычаг для одного срочного сообщения без привлечения разработчиков.

Пожертвования

Опция на кассе для гостей, позволяющая направить пожертвование партнёрской организации — в качестве живого примера используется Красный Крест. Настраивается на уровне компании:

• Фиксированные суммы (€1, €2, €5) плюс поле для произвольной суммы.
• Описание цели — краткий текст о том, чем занимается партнёр.
• Необязательное значение по умолчанию — opt-in (выключено, пока не выбрано) или opt-out (включено по умолчанию, гость может отменить).

Пожертвования проводятся через ту же транзакцию Mollie, которой гость уже оплачивает заказ, но сумма пожертвования направляется на счёт партнёрской организации в Mollie. С точки зрения гостя: одно списание. С точки зрения оператора: пожертвование не отображается в выручке ресторана и в отчётах о продажах POS — оно чисто попадает в бухгалтерию партнёрской организации с правильным налоговым учётом.

Это шаг к доверию гостей без какого-либо влияния на маржу ресторана.

Чаевые

Чаевые — не совсем промо-механика, но смежная тема, и именно здесь сети обычно видят самый быстрый рост выручки после запуска Fooodo. Процесс начисления чаевых:

• Фиксированные процентные варианты (10%, 15%, 20%) плюс произвольная сумма.
• Включение/отключение для каждого стола — отключите чаевые у стойки навынос, оставьте включёнными за столиками в зале.
• Процент по умолчанию настраивается на уровне ресторана.

Чаевые включаются в тот же платёж Mollie, что и заказ, а затем оседают в вашем POS отдельной строкой чаевых — существующие процессы распределения чаевых не меняются. Код POS, представляющий доход от чаевых, задаётся для каждого ресторана (в действующем коннекторе R-Keeper это код выручки R-Keeper; другие коннекторы предоставляют ту же настройку).

Отзывы

Запрос оценки после оплаты фиксирует мнение гостя для просмотра оператором. Оценки не отображаются публично — они существуют для вас, а не для других гостей. Процесс:

1. Гость оплачивает заказ.
2. Необязательный запрос оценки от 1 до 5 с полем для свободного комментария.
3. Оценка привязывается к заказу, столику и персоналу/смене.

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

Избранное гостей

Авторизованные гости могут добавлять отдельные позиции меню в избранное — одним нажатием, и это сохраняется между визитами. Привязки к конкретному ресторану нет: гость, отметивший Маргариту как избранное в одной локации Čili Pizza, увидит то же избранное при следующем сканировании QR в другой локации.

Избранным управляет гость. Панели оператора для редактирования избранного гостя не существует; избранное — это инструмент на стороне гостя для быстрого повторного заказа, а не рычаг мерчандайзинга. Оно намеренно отделено от системы рекомендаций — уровень перекрёстных продаж на кассе использует повторные покупки гостя за 30 дней, а не его явное избранное. Гость, не прошедший авторизацию, может просматривать меню в обычном режиме; избранное просто недоступно.

Что намеренно не включено в систему

• Нет публичных отзывов. Оценки гостей видны оператору, но не отображаются другим гостям. Если вам нужны публичные отзывы — это Google, TripAdvisor или Wolt; Fooodo не конкурирует с ними.
• Нет реферальных вознаграждений. Механики «пригласи друга за €5, получи €5» сегодня нет.
• Нет многоуровневой лояльности. Карточная программа вашего POS — единственный инструмент лояльности; никакой параллельной системы «Бронза/Серебро/Золото» внутри Fooodo нет.
• Нет автоматических email-рассылок из Fooodo. Генерация купонных кодов происходит здесь; сама отправка выполняется в вашей CRM.

Что делать дальше

• Ежедневные операции: Начало работы — онбординг и пробный запуск.
• Сторона заказов: Потоки заказов — как Pay-First и Pay-Later взаимодействуют с акциями (например, купонные коды применяются в обоих потоках).
• Финансовая сторона: Платежи — подробно о чаевых, пожертвованиях и механике возвратов.