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

Закупівлі в HoReCa довго залишалися однією з найменш цифровізованих ділянок бізнесу. Кухня формує потребу в продуктах у месенджері, бар пише окремо, керуючий уточнює залишки по телефону, а бухгалтерія отримує накладні у вигляді фотографій. У невеликому закладі це працює. У мережі з десяти закладів і трьох десятків постачальників така схема починає щодня генерувати помилки: пропущені позиції, невраховані зміни цін, дублювання замовлень, недопоставки, які ніхто не зафіксував письмово.

B2B-портал постачання – це спосіб перевести цей процес у контрольовану цифрову форму, де замовлення, ціни, документи та статуси поставок живуть в одній системі, а не в переписці.

Розберемо, як влаштований B2B-портал для ресторанів, кафе та готелів, які функції потрібні в першій версії, як він інтегрується з обліковими системами й що варто продумати до початку розробки.

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

Від телефонних замовлень і таблиць до єдиної системи

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

Головна відмінність від будь-якої «таблиці в спільному доступі» – наявність бізнес-логіки. Портал знає, які товари доступні конкретному клієнту, за якою ціною, з якою кратністю упаковки, з якою мінімальною сумою замовлення та з якими умовами оплати.

Чим B2B-портал відрізняється від інтернет-магазину та звичайного особистого кабінету

Зовні B2B-портал схожий на eCommerce-сайт, але логіка інша. У роздрібному магазині ціна публічна й однакова для всіх. У B2B eCommerce ціна – це функція від клієнта, обсягу, договору та групи, до якої клієнт віднесений.

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

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

Хто працює з порталом

Реальних ролей більше, ніж «клієнт» і «менеджер». Шеф-кухар формує потребу по кухні, бармен – по бару, керуючий закладом підтверджує замовлення в межах ліміту, закупівельник консолідує позиції та веде управління постачальниками, бухгалтерія працює з накладними та рахунками. З боку постачальника – менеджер, який обробляє замовлення, і логіст, який планує гуртові поставки. Кожна з цих ролей потребує різного інтерфейсу й різного обсягу даних.

Для постачальника вигода не менш очевидна. Менеджер перестає бути «людиною-інтерфейсом», яка вручну переносить позиції з переписки в облік, і починає працювати з винятками: узгодженням замін, дефіцитом, спірними поставками. Це змінює економіку відділу продажів – одна людина здатна обслуговувати більше клієнтів без зростання кількості помилок.

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

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

Каталог – ядро системи. Він має підтримувати категорії продуктів, напоїв, хімії та інвентарю, фільтри за постачальником, сезонністю й температурним режимом. Актуальні залишки передаються з облікової системи, а для дефіцитних позицій варто передбачити режим «під замовлення»: товару немає на складі, але його можна замовити з подовженим строком поставки. Персональні ціни й індивідуальний прайс-лист формуються за групою клієнта або за окремим договором.

Швидке створення, повторення та редагування оптових замовлень

Основний сценарій у HoReCa – не пошук нового товару, а повторення регулярного кошика. Тому кнопка «Повторити замовлення», редагування вже створеного замовлення до моменту його підтвердження й швидке додавання позицій за артикулом впливають на adoption сильніше, ніж будь-який дизайн головної сторінки.

Історія закупівель, статуси замовлень і контроль доставки

Історія замовлень повинна зберігати не тільки склад і суму, а й фактичні коригування: заміну позиції, зменшення кількості, розбіжності при прийманні. Саме ці дані потім використовуються для претензійної роботи й переговорів.

Індивідуальні ціни, знижки, відстрочка платежу

Умови для B2B-клієнтів – це набір параметрів: цінова група, рівень знижки за обсягом, ліміт товарного кредиту, відстрочка, робота з ПДВ або без нього. Портал має вміти показувати клієнту його поточний баланс і доступний ліміт, інакше замовлення проходитиме перевірку вручну.

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

Окремий сценарій, характерний саме для HoReCa: закупівельник мережі формує одне замовлення, але частину позицій потрібно доставити в один заклад, частину – в інший. Технічно це означає, що адреса доставки прив'язується не до замовлення, а до його рядків, а сума мінімальної партії й логістичні умови перевіряються для кожної точки окремо. Якщо цей сценарій не врахований у моделі даних одразу, доводиться або дробити замовлення вручну, або переписувати логіку кошика та документів. При мультидоставці зазвичай формується кілька накладних на одне замовлення, і це також потрібно передбачити в інтеграції з обліком.

Електронні накладні, рахунки та документообіг

Тут є важливий архітектурний нюанс. Рахунок не варто генерувати на сайті в момент оформлення замовлення. До підтвердження менеджер може змінити кількість, замінити товар або скорегувати склад замовлення, тому фінальний документ повинен формуватися вже на основі підтверджених даних облікової системи й лише потім ставати доступним у кабінеті. Інакше клієнт отримує рахунок, який не відповідає фактичній поставці, а бухгалтерія – зайвий цикл узгоджень.

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

Кабінет для гуртових закупівель ресторанів дає найбільший ефект саме на регулярних, повторюваних операціях.

Шаблони закупівель

Окремі списки для кухні, бару, кондитерського цеху, господарських потреб. Шаблон – це не просто збережений кошик, а список позицій без фіксованих кількостей, який закупівельник щоразу наповнює під поточну потребу.

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

Для позицій зі стабільним споживанням – хліб, молочна продукція, вода, серветки – можна налаштувати автоматичне замовлення за розписом. Тут варто закласти запобіжник: перед відправкою система формує чернетку, а відповідальний співробітник підтверджує її. Повністю автоматична відправка без підтвердження в HoReCa часто призводить до поставок у дні, коли заклад закритий або працює в скороченому режимі.

Мінімальні партії та кратність упаковки

Це одне з найпоширеніших джерел помилок в оптових замовленнях. Один ящик може містити 2 кг товару, і клієнт замовляє п'ять ящиків, тобто 10 кг. Якщо система дозволяє вводити довільну кількість у кілограмах, розбіжність між замовленням і фактичною поставкою гарантована. Правильна модель даних розділяє одиницю продажу, одиницю обліку й коефіцієнт перерахунку, а інтерфейс явно показує, що саме потрапить у накладну.

Сповіщення про зміну ціни, відсутність товару та строки поставки

Закупівельник має дізнаватися про подорожчання не з накладної. Корисні три типи сповіщень: зміна закупівельної ціни на позиції з активних шаблонів, поява дефіцитної позиції в наявності, зміна планової дати поставки.

Менше ручних операцій

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

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

Портал для мережі ресторанів вирішує іншу задачу, ніж кабінет одного закладу. Тут головне – структура.

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

Мультифіліальне управління передбачає ієрархію: юридична особа – заклад – склад – користувач. Причому в реальності мережа закладів рідко відповідає одній юридичній особі: частина точок може працювати через окремі ФОП або ТОВ, а договори й реквізити відрізняються. Модель даних, у якій «клієнт = один контрагент», ламається на першому ж франчайзинговому закладі, тому зв'язок «кілька контрагентів – один акаунт» краще закладати одразу.

Окремі каталоги, бюджети та умови

Пивний бар і готельний ресторан у межах однієї мережі можуть мати різний затверджений асортимент. Портал має обмежувати каталог до дозволеного для конкретної точки й тримати окремий контроль бюджету.

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

Керуючий, шеф-кухар, закупівельник, бухгалтер, регіональний менеджер. Ролі користувачів у 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-платформа виправдана, якщо процеси стандартні. Індивідуальна розробка або гібридний підхід «готове ядро плюс кастомні доопрацювання й інтеграції» стає необхідним, коли є нетипове ціноутворення, мультидоставка одного замовлення на кілька точок, складна схема погоджень або специфічний облік.

Масштабування

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

Безпека та доступи

B2B-портал містить комерційно чутливі дані – персональні ціни, обсяги, умови договорів. Потрібні розмежування доступу на рівні контрагента, корпоративна авторизація через SSO для великих мереж, журнал критичних дій із фіксацією користувача, часу, дії й об'єкта. При цьому в логи не повинні потрапляти паролі, токени та інші секрети.

Який результат отримує HoReCa-бізнес після впровадження порталу закупівель

Менше ручної роботи

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

Єдиний стандарт

Усі заклади мережі працюють за однаковими правилами: затверджений асортимент, ліміти, погодження, документи. Це особливо помітно при відкритті нової точки – процес закупівель уже описаний системою.

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

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

Прозора історія

Замовлення, поставки, розбіжності й взаєморозрахунки зберігаються в одному місці. Це знімає значну частину суперечок із постачальниками.

Підготовка до подальшої автоматизації

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

FAQ