B2B-портал поставки для ресторанов, кафе и гостиниц (HoReCa)

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

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

Ниже мы расскажем, как устроен B2B-портал для ресторанов, кафе и гостиниц, какие функции нужны ему на первом релизе, как он интегрируется с учетными системами и дополнительными сервисами. Вы узнаете, как создаются такие решения, и что следует продумать до начала разработки. 

Что такое B2B-портал поставок для HoReCa и какие задачи он решает

От телефонных заказов и таблиц к единой системе

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

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

Чем B2B-портал отличается от интернет-магазина и обычного личного кабинета

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

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

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

Кто работает с порталом

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

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

Кабинет для закупок HoReCa: ключевые возможности системы

Каталог товаров, актуальные остатки и персональные прайс-листы

Каталог — ядро ​​системы. Он должен поддерживать категории продуктов, напитков, химии и инвентаря; предлагать фильтры по поставщику, сезонности и температурному режиму. Актуальные остатки передаются из учетной системы, а для дефицитных позиций стоит предусмотреть режим «под заказ»: товара нет на складе, но его можно заказать с удлиненным сроком поставки. Персональные цены и индивидуальный прайс-лист формируются по группе клиента или по отдельному договору.

Быстрое создание, повторение и редактирование оптовых заказов

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

История закупок, статусы заказов и контроль доставки

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

Индивидуальные цены, скидки, отсрочка платежа

Условия для B2B-клиентов — это набор параметров: ценовая группа, уровень скидки по объему, лимит товарного кредита, отсрочка, работа с НДС или без него. Портал должен уметь показывать клиенту его текущий баланс и доступный лимит, в противном случае заказ будет проходить проверку вручную.

Мультидоставка одного заказа

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

Электронные накладные, счета и документооборот

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

Кабинет для оптовых закупок ресторанов: как автоматизировать регулярные заказы

B2B-система для оптовых закупок ресторанов дает самый большой эффект именно на регулярных, повторяющихся операциях.

Шаблоны закупок

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

Регулярные и автоматические заказы

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

Минимальные партии и кратность упаковки

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

Уведомление об изменении цены, отсутствии товара и сроках поставки

Закупщик должен узнавать о подорожании не из накладной. Особенно полезны три типа уведомлений: изменение закупочной цены на позиции по активным шаблонам, появление дефицитной позиции в наличии и изменение плановой даты поставки.

Минимизация ручных операций

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

Портал для ресторанов: централизованное управление закупками

B2B-портал для сети ресторанов решает несколько иные задачи, чем кабинет для одного заведения. Ключевое отличие — в структуре. 

Один корпоративный аккаунт для нескольких заведений

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

Отдельные каталоги, бюджеты и условия

Пивной паб и гостиничный ресторан в пределах одной сети могут иметь разный утвержденный ассортимент. Портал должен ограничивать каталог до разрешенного под конкретную точку и поддерживать раздельный контроль бюджета.

Роли и права доступа

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

Согласование заказов и лимиты расходов

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

Централизованные и локальные закупки

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

Аналитика расходов

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

Управление поставщиками через B2B-платформу HoReCa

Ресторан редко работает с одним поставщиком. Продукты, напитки, химия, упаковка, инвентарь — это разные контрагенты с разными графиками поставок.

Единый каталог от нескольких поставщиков

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

Сравнение цен и условий

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

Рекомендуемые и утвержденные поставщики

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

Контроль исполнения, замен и разногласий

Ключевой сценарий, часто выпадающий из первой версии: приемка поставки. Если привезли 8 кг вместо 10, портал должен зафиксировать фактическое количество, несовпадение и причину, а не просто закрыть заказ статусом «выполнен». Без этого данные о поставщике не будут отображать реальность.

История взаимодействия

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

Автоматизация закупок продуктов и расходных материалов для HoReCa

Перевод закупок HoReCa на автоматизированные рельсы становится экономически оправданным тогда, когда в одном кабинете объединены все категории, а не только продукты.

Продукты, напитки и ингредиенты

Самая сложная группа: короткие сроки годности, изменяемый вес, сезонность, температурный режим. Здесь критически важны точные даты поставки и поддержка весовых товаров.

Упаковка, одноразовая посуда и товары для доставки

Категория со стабильным потреблением и большими партиями. Идеальный кандидат для автоматизации и работы по рекомендуемым заказам на основе остатков.

Профессиональная химия и гигиенические средства

Часто закупается реже, но большими объемами, иногда с обязательными сертификатами. Портал должен хранить документы на каждую партию вместе с поставкой.

Оборудование и инвентарь

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

Как объединить категории

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

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

Интеграция кабинета для закупок HoReCa с учетными системами

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

Интеграция с ERP и бухгалтерским ПО

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

Синхронизация с POS и складским учетом

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

Передача остатков

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

API и EDI-интеграции

API-интеграция подходит для современных систем, EDI-интеграция — для крупных дистрибьюторов с собственными стандартами обмена. Часто в одном проекте сосуществуют оба подхода, плюс обмен файлами для отдельных документов.

Автоматическая передача заказов, цен, накладных и статусов

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

Еще одна недооцененная часть работы — маппинг статусов. Внутренние статусы учетной системы почти никогда не совпадают с тем, что должен видеть клиент: там может быть десяток технических состояний, часть из которых не имеет смысла для покупателя. Нужна отдельная таблица соответствия “статус в учете — статус в кабинете” и правило для неизвестных значений, иначе появление нового статуса в ERP приведет к пустому или некорректному отображению на портале. Практика показывает, что именно на этом этапе следует согласовать и перечень событий, генерирующих уведомления, чтобы клиент не получал письма на каждое техническое изменение состояния.

Как B2B-портал помогает контролировать food cost и расходы ресторана

Контролировать Food cost можно не в момент оплаты, а в момент заказа. Портал дает для этого данные.

Аналитика закупок

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

Контроль изменения закупочных цен

История цен по позиции за отчетный период — базовый инструмент. Полезно отдельно выводить позиции с наибольшим влиянием на общую сумму, а не просто с наибольшим процентом удорожания.

Сравнение затрат между заведениями

Когда два ресторана подобного формата имеют разную себестоимость одинакового блюда, причина обычно в закупках, или в дисциплине заявок. Портал делает это сравнение возможным.

Контроль закупок вне утвержденного ассортимента

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

Нормализация цены до сравниваемой единицы

Без этого аналитика закупок дает искривленную картину. Одна позиция поставляется в ящиках по 2 кг, другая — в упаковках по 900 г, третья — в литрах. Сравнивать их по цене упаковки бессмысленно, поэтому система должна сохранять цену за базовую единицу учета, параллельно с ценой продажи. Это же значение необходимо для корректного расчета влияния закупок на food cost.

Данные для переговоров

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

Как должен работать удобный B2B-кабинет для ресторана или отеля

Даже самая лучшая система закупок для ресторанов может провалиться, если сотрудникам неудобно ею пользоваться.

Быстрый поиск и персонализированный каталог

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

Мобильная версия

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

Повторный заказ в несколько кликов

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

Прозрачные статусы

Статусы должны описывать реальный процесс, а не внутренние состояния системы: "Принято", "Согласовывается", "Подтверждено поставщиком", "Комплектуется", "В пути", "Принято с разногласиями", "Выполнено".

Уведомления

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

Защита от ошибок ввода

Опыт показывает, что большинство инцидентов на старте — это не сбои системы, а обычная невнимательность: заказано 100 ящиков вместо 100 килограммов. Поэтому интерфейс должен явно подписывать единицу, показывать итоговый вес/объем и выводить предупреждение, если количество значительно отличается от средней по этой позиции за предыдущие периоды. Такие проверки стоят недорого, но заметно сокращают количество ручных корректировок со стороны менеджера поставщика.

Разработка B2B-портала для поставщика или сети HoReCa

Что анализировать к разработке

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

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

MVP

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

Когда нужна индивидуальная разработка

Готовая "коробочная" B2B-платформа оправдана, если процессы стандартные, и существенных изменений или масштабирования не планируется — под такую ​​логику на рынке можно подобрать готовое ПО или SaaS-платформу. Индивидуальная разработка или гибридный подход «готовое ядро ​​плюс кастомные доработки и интеграции» становятся актуальными, когда бизнес требует решения нетипичных задач: собственная логика ценообразования, мультидоставка одного заказа на несколько точек, сложная схема согласований или специфический учет.

Масштабирование

Портал растет по трем направлениям: новые заведения, новые регионы с иной логистикой, новые поставщики. Чаще всего узким местом становится не инфраструктура, а модель данных: в систему жестко "зашит" один склад, один регион или один контрагент. Закладывать мультискладовость и мультиконтрагентность дешевле на старте, чем прописывать через программные "костыли" в дальнейшем.

Безопасность и доступы

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

Какой результат получает HoReCa-бизнес после внедрения портала закупок

Сокращение ручной работы

Заказы перестают жить в телефонных звонках и мессенджерах. Менеджер поставщика не переносит позиции вручную, покупатель не сверяет артикулы, управляющий не ищет, кто что заказал.

Единый стандарт

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

Контроль цен и бюджетов

Видимые изменения закупочных цен, лимиты затрат и согласование внеочередных закупок позволяют принимать решения своевременно, а не реагировать на инциденты постфактум. 

Прозрачная история

Заказы, поставки, разногласия и взаиморасчеты хранятся в одном месте. Это снимает значительную часть споров с поставщиками.

Подготовка к дальнейшей автоматизации

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

FAQ