Пекарня: заказы от 20 кафе по расписанию — маленькая B2B-панель на своём VPS

MAATRIX

Если пекарня поставляет хлеб и выпечку в кафе оптом, рано или поздно приём заказов превращается в отдельную головную боль: звонки вперемешку с сообщениями в мессенджерах, у каждого кафе свой день поставки, кто-то путает багеты с чиабаттой, кто-то забывает продиктовать количество на завтра. Когда клиентов десяток-другой — условно 20, как в заголовке — держать всё это в голове и в блокноте технолога перестаёт работать. Решение не требует ни дорогой SaaS-подписки, ни отдела разработки: небольшая B2B-панель заказов на своём VPS, где каждое кафе само оформляет заявку на нужную дату, а пекарня видит структурированный список вместо вороха звонков.

Как сейчас выглядит приём заказов и где теряются деньги

Типичная схема в небольшой пекарне, которая работает с кафе оптом, выглядит примерно так: у технолога или менеджера есть телефон, на который в течение дня прилетают заявки — кто-то звонит, кто-то пишет в WhatsApp или Telegram, кто-то присылает голосовое сообщение по дороге на работу. Заявки записываются в блокнот, в заметки телефона, в общий Excel-файл, который открыт у нескольких людей одновременно. У этой схемы есть несколько предсказуемых точек отказа:

• Путаница в датах. Кафе просит "как обычно, на четверг", а на четверг уже стоит другой объём с прошлой недели — никто не сверился.
• Ошибки в количестве. Голосовое сообщение расшифровали на слух: "десять чиабатт" превратились в "десять багетов", потому что менеджер отвлёкся на печь.
• Забытые заказы. Кафе позвонило в выходной, трубку никто не взял, заявка потерялась — а в понедельник претензия.
• Нет истории. Через месяц невозможно быстро посмотреть, сколько кафе "Утро" заказывало в среднем за последние четыре недели, чтобы спланировать закупку муки.
• Ручной пересчёт под производство. Утром кто-то должен вручную свести заявки от всех кафе в один список для пекарей — форматы у всех разные, время на пересчёт уходит впустую.

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

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

Что должна уметь B2B-панель для пекарни

Перед тем как что-то разворачивать на сервере, стоит честно определить минимальный набор функций — потому что соблазн сделать "полноценную ERP-систему" для 20 клиентов обычно заканчивается тем, что проект зависает на полпути. Для пекарни, поставляющей продукцию оптом кафе, достаточно закрыть пять вещей:

1. Личный кабинет для каждого кафе — логин/пароль, чтобы кафе видело только свои заказы, а не заказы конкурентов по соседству.
2. Каталог продукции с единицами измерения — не просто "хлеб", а конкретные позиции: багет 250 г, чиабатта 300 г, круассан классический, черный хлеб буханка 500 г — с ценой, действующей для конкретного клиента (у сетевого кафе может быть одна цена, у разового заказчика — другая).
3. Форма заказа на дату — кафе выбирает дату поставки (обычно "завтра" или "по расписанию на неделю") и вбивает количество по каждой позиции.
4. Расписание по клиенту — у одних кафе поставка каждый будний день, у других — через день, у третьих только по вторникам и пятницам под выходной наплыв. Панель должна помнить это расписание и не позволять оформить заказ на "неправильный" день без явного подтверждения.
5. Сводный лист для производства — на утро список, сгруппированный по позициям (сколько всего багетов на завтра по всем клиентам) и отдельно — по клиентам (что именно везти в каждое кафе).

Всё, что сверх этого — интеграция с 1С, автоматическое выставление счетов, push-уведомления в приложении — это уже второй этап, если он вообще понадобится. Начинать стоит с формы заказа плюс сводного листа: это закрывает 80% боли за разумное время разработки.

Какой VPS нужен для панели на пару десятков кафе-клиентов

Здесь важно не переоценить нагрузку. B2B-панель для пекарни — это по сути CRUD-приложение с формами и таблицей заказов, которое открывают несколько десятков человек в день, в основном утром и вечером, когда оформляют заявки на завтра. Это далеко не интернет-магазин с тысячами посетителей в сутки.

Ориентировочно (именно ориентировочно — точная цифра зависит от того, какой стек вы выберете и сколько лишнего на сервер поставите) для 20-40 кафе-клиентов достаточно:

Это тот случай, когда гнаться за мощным тарифом бессмысленно — переплата за 8 ГБ RAM и 4 ядра здесь никак не отразится на удобстве кафе-клиентов. Разумнее взять недорогой VPS с запасом на рост (условно, до 100 клиентов на том же тарифе панель не почувствует разницы) и не усложнять инфраструктуру раньше времени. О том, что скромный тариф на практике справляется с задачами такого масштаба не хуже дорогого, есть отдельный разбор: дешёвый VPS против дорогого на практике.

Быстрый старт: MVP на no-code инструменте за один день

Если нет времени и ресурсов писать отдельное веб-приложение, вменяемый первый шаг — собрать MVP на no-code/low-code платформе, которая ставится на тот же VPS. Это честный компромисс: вы получаете рабочую панель за день-два вместо недель разработки, но с оговорками.

Практичный вариант — NocoDB: разворачивается в один Docker-контейнер, даёт табличную базу данных с формами для внешних пользователей. Логика такая: создаёте таблицу "Клиенты" (кафе, контакты, расписание поставок, цены), таблицу "Позиции" (каталог продукции) и таблицу "Заказы" (дата, клиент, позиция, количество). Дальше публикуете форму заказа — кафе переходит по ссылке (можно закрепить в закладках или отправить в Telegram), выбирает себя из списка, дату и количество по каждой позиции. Все заявки падают в общую таблицу, которую видит менеджер пекарни. Подробно про установку — в статье как установить и настроить NocoDB на VPS.

Честная оговорка про ограничения такого подхода: форма NocoDB — это одна открытая ссылка на всех, а не персональный кабинет с логином под каждое кафе. Значит, разграничить "кафе видит только свои прошлые заказы" через голую форму не получится — для этого понадобится либо платный тариф с ролями, либо переход на полноценное приложение с авторизацией (следующий раздел). Для старта на 5-10 клиентов, пока вы проверяете саму идею, ограничение не критично. Когда клиентов становится 20+ и они начинают спрашивать "а что я заказывал на прошлой неделе", это уже повод вложиться в нормальные личные кабинеты.

Расписание поставок, повторяющиеся заказы и время отсечки

Ключевая особенность именно B2B-заказов для кафе (в отличие от розницы) — предсказуемость и повторяемость. Кафе редко заказывает хаотично: у него есть проходимость, есть план по меню, есть более-менее стабильный объём с поправкой на выходные и праздники. Панель должна использовать это, а не заставлять клиента каждый раз вводить всё с нуля.

Практическая модель, которая работает на практике у небольших производств:

• Шаблон заказа по клиенту. Кафе один раз настраивает "стандартный набор": 15 багетов, 10 чиабатт, 20 круассанов на каждый будний день. Дальше при оформлении заказа на дату форма уже предзаполнена этим шаблоном, и клиенту нужно только скорректировать цифры (или подтвердить как есть) — это тот самый переход "от диктовки по телефону к правке готового шаблона", который экономит время на обеих сторонах.
• Дни поставки по расписанию. У каждого клиента в карточке хранится список дней недели, когда он в принципе получает поставки. Если кафе пытается оформить заказ на день, которого нет в его расписании, форма подсвечивает это предупреждением — не блокирует жёстко (расписание иногда меняется), но не даёт создать заказ незаметно для менеджера.
• Время отсечки (cutoff). Производство должно понимать заранее, сколько печь. Разумная практика — установить время, до которого заказ на завтра можно оформить или изменить (например, до 18:00 предыдущего дня), а после — заказ уходит в производство и правки возможны только через звонок менеджеру. Это можно реализовать простым флагом в таблице заказов ("locked"), который выставляется по cron-задаче в нужное время, либо проверкой текущего времени в коде формы.
• Уведомления о новых и изменённых заказах. Чтобы менеджеру не нужно было каждые полчаса открывать панель и проверять, не пришло ли что-то новое, удобно настроить уведомление в Telegram при появлении новой заявки или её редактировании после отсечки — это уже прямая замена того самого звонка, который раньше отвлекал от печи. Как поднять такие уведомления на своём сервере, описано в статье как установить и настроить алерты в Telegram на VPS.

Сводный лист для производства в этой модели генерируется автоматически каждый вечер (или рано утром) простым SQL-запросом, который группирует все заказы на завтрашнюю дату по позициям — и это уже готовый список "что печь" без единого звонка.

Развёртывание: домен, HTTPS и бэкапы

Дальше — практическая часть, независимо от того, выбрали вы no-code MVP или отдельное приложение. Три вещи обязательны для панели, к которой подключаются внешние люди (сотрудники кафе-клиентов), даже если это скромный внутренний B2B-сервис.

Домен и HTTPS. Ссылка вида http://12.34.56.78:8080 выглядит несерьёзно и настораживает браузеры кафе-клиентов предупреждением о небезопасном соединении. Заведите поддомен, например zakazy.вашапекарня.ru, направьте A-запись на IP сервера и поставьте nginx как обратный прокси с бесплатным сертификатом Let's Encrypt:

server {
    listen 80;
    server_name zakazy.example.ru;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo apt update && sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d zakazy.example.ru

Пошаговый разбор certbot и автопродления сертификата — в статье как установить и настроить Let's Encrypt SSL на VPS.

Docker Compose как основа. Даже для небольшого приложения удобнее держать всё в контейнерах — проще переносить, проще откатывать при обновлении:

version: "3.8"
services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: bakery_orders
      POSTGRES_USER: bakery
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db_data:/var/lib/postgresql/data

  app:
    build: ./app
    restart: unless-stopped
    depends_on:
      - db
    environment:
      DATABASE_URL: postgres://bakery:${DB_PASSWORD}@db:5432/bakery_orders
    ports:
      - "127.0.0.1:8080:8080"

volumes:
  db_data:

Бэкапы базы заказов. Заказы — это операционные данные, потеря которых на день означает реальный сбой поставок. Ежедневный дамп с ротацией — минимальная защита:

#!/bin/bash
# /opt/scripts/backup-orders.sh
DATE=$(date +%Y-%m-%d)
docker exec -t $(docker ps -qf "name=db") pg_dump -U bakery bakery_orders | gzip > /opt/backups/orders-$DATE.sql.gz
find /opt/backups -name "orders-*.sql.gz" -mtime +30 -delete

# crontab -e
0 3 * * * /opt/scripts/backup-orders.sh

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

Права доступа. Каждому кафе — отдельный логин, который видит только свои заказы (фильтрация по client_id на уровне запросов к базе, а не только в интерфейсе). Менеджеру пекарни — отдельная административная роль с доступом ко всем заказам и сводному листу. Не давайте клиентам общий пароль "на всех" — тогда пропадает и учёт по конкретному кафе, и минимальная защита от ошибочного редактирования чужого заказа.

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