Ресторан: бронирование столов на своём сайте вместо 3 000 ₽ в месяц конструктору

MAATRIX

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

Что почём: считаем годовой счёт за подписку и за свой сервер

Возьмём условие из заголовка: конструктор сайтов с модулем бронирования столов стоит 3 000 ₽ в месяц. Это распространённая модель у конструкторов ресторанного сегмента — базовый сайт-визитка дешевле, а именно функция брони, синхронизация с залом и уведомления гостям идут отдельным платным блоком поверх.

Годовой счёт считается прямо:

3 000 ₽ × 12 месяцев = 36 000 ₽ в год

И это по сегодняшнему тарифу — конструкторы регулярно пересматривают цены модулей вверх, добавляют лимиты на число броней в месяц или берут отдельную плату за SMS-напоминания гостям сверх бесплатного пакета. За три года при неизменной цене это 108 000 ₽, а на практике почти всегда больше.

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

Первый год со своим сервером может обойтись примерно в ту же сумму, что и год подписки, или дороже — вся стоимость настройки ложится сразу, а не размазывается по 12 платежам. Разница проявляется дальше: со второго года расходы падают до цены аренды сервера и домена, а подписка продолжает стоить 36 000 ₽ в год бессрочно. На горизонте трёх лет разрыв обычно уже в пользу своего сервера, а на горизонте пяти — заметно в его пользу, при условии что сайт не требует постоянных доработок.

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

Что реально должна уметь бронь столов на сайте ресторана

Форма «имя, телефон, время» — это не бронирование, а заявка на обратный звонок. Рабочая система для зала должна закрывать несколько задач одновременно:

• Видеть занятость столов, а не просто время. Стол на 2 персоны в 19:00 занят — это не значит, что стол на 6 персон тоже занят. Логика должна знать вместимость и расположение столов, а не просто «слот времени».
• Учитывать длительность визита. В ресторане бронь — это не час, как в салоне красоты, а условные 1,5–2,5 часа с запасом на задержку предыдущей компании. Слишком плотная сетка слотов приводит к тому, что гостя сажают за грязный стол.
• Разделять будни и пиковые дни. Пятница и суббота вечером — это в среднем в разы больше заявок, чем вторник днём. Форма должна одинаково выдерживать оба режима, а хостес — видеть картину сразу по всему залу.
• Спрашивать про особые случаи. День рождения, банкетный зал, детский стул, аллергии — поля, которые обычный конструкторский виджет часто не поддерживает без доплаты за «расширенный» тариф.
• Уведомлять и гостя, и персонал. Гость должен получить подтверждение (SMS или email), хостес — увидеть новую бронь без обновления страницы каждые пять минут.

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

Как это устроено технически: минимальный стек на своём VPS

Для сайта с формой брони не нужен тяжёлый стек. Рабочий минимум на одном небольшом сервере:

• Nginx — отдаёт статику сайта (меню, фото зала, страницы) и работает реверс-прокси перед бэкендом брони.
• Небольшой бэкенд (например, на Python/FastAPI или Node.js/Express) — реализует саму логику: список столов, доступные слоты, проверка пересечений по времени, запись брони.
• PostgreSQL — хранит столы, брони и гостей. Схема на старте компактная:

CREATE TABLE tables (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,        -- "Стол 4", "Терраса 2"
  seats INT NOT NULL,
  zone TEXT                  -- зал / терраса / банкетный
);

CREATE TABLE reservations (
  id SERIAL PRIMARY KEY,
  table_id INT REFERENCES tables(id),
  guest_name TEXT NOT NULL,
  guest_phone TEXT NOT NULL,
  party_size INT NOT NULL,
  starts_at TIMESTAMPTZ NOT NULL,
  ends_at TIMESTAMPTZ NOT NULL,
  status TEXT DEFAULT 'confirmed', -- confirmed / cancelled / no_show / completed
  note TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

Проверка «стол свободен на это время» — это один запрос на пересечение интервалов, без внешних сервисов:

SELECT id FROM reservations
WHERE table_id = $1
  AND status = 'confirmed'
  AND starts_at < $3   -- ends_at новой брони
  AND ends_at > $2;    -- starts_at новой брони

Если результат пустой — стол свободен, можно писать бронь. Эта же логика в конструкторе скрыта за платным модулем, а тут — обычный SQL-запрос, который вы полностью контролируете и можете подстроить под особенности своего зала (например, разрешить овербукинг на 10% в будни, если статистика показывает регулярные ранние уходы).

Минимальный docker-compose.yml для такого сайта:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: booking
      POSTGRES_USER: booking
      POSTGRES_PASSWORD: change_me
    volumes:
      - pgdata:/var/lib/postgresql/data

  app:
    build: ./app
    environment:
      DATABASE_URL: postgresql://booking:change_me@db/booking
    depends_on:
      - db

  nginx:
    image: nginx:alpine
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./static:/usr/share/nginx/html
    ports:
      - "80:80"
      - "443:443"
    depends_on:
      - app

volumes:
  pgdata:

Для уведомлений гостям и хостес используется отдельный вызов к SMS- или email-провайдеру по API из бэкенда, без привязки к конкретному сервису — это меняется легче всего, если один провайдер не устроит по цене или доставляемости.

Депозит и защита от no-show без комиссии посреднику

No-show — реальная головная боль ресторанного бизнеса, особенно в пятницу-субботу вечером и в праздничные даты: стол держат под бронь, отказывают другим гостям, а бронирующая компания не приходит и не предупреждает. У конструкторов это обычно решается либо никак, либо через встроенный платёжный модуль с собственной комиссией за каждую транзакцию депозита — сверх и без того платной подписки на бронирование.

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

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

Клиентская база и история броней остаются у ресторана

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

На своём сервере база броней и гостей — это обычные таблицы PostgreSQL, из которых в любой момент можно выгрузить полный список в CSV, построить отчёт по постоянным гостям или подключить рассылку ко дню рождения без ограничений тарифного плана. Плюс это прямее ложится в требования 152-ФЗ к персональным данным — телефон и имя гостя обрабатываются на сервере, за который вы отвечаете сами, а не передаются стороннему облачному сервису на неопределённых условиях обработки.

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

Обратная сторона: что вы берёте на себя, отказываясь от подписки

Честно: отказ от конструктора — это не бесплатный обед. Ресторан берёт на себя то, что раньше делал провайдер за свои 3 000 ₽ в месяц:

• Обновления и безопасность. Сервер и приложение нужно обновлять, иначе форма брони со временем становится дырой в безопасности, а не удобством.
• Резервные копии. База с бронями на вечер пятницы — это данные, потеря которых прямо бьёт по выручке. Регулярный pg_dump в отдельное хранилище — не опция, а обязательный пункт.
• Кто-то должен уметь это чинить. Если форма брони легла в четверг вечером перед пиковыми днями, а единственный человек, разбирающийся в коде, в отпуске — это реальный риск для небольшого заведения без своего IT-специалиста.
• Первоначальная настройка требует времени или денег. Либо вы или сотрудник разбираетесь в развёртывании сами, либо платите разработчику разово — это тот самый первый год в таблице выше, где экономия ещё не наступила.

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

Частые вопросы