B2B-додаток для замовлень виробника: вимоги

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

До проєктування варто відповісти на базове запитання: який процес додаток має спростити для партнера, а який — не дозволити порушити. Якщо відповідь звучить лише як «потрібен каталог», обсяг часто ще не визначений. Каталог без правил доступу, цін і підтвердження замовлення рідко закриває B2B-потребу.

Що має робити B2B-додаток виробника

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

Для виробника типовий маршрут оптового замовлення виглядає так:

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

Цей маршрут корисно намалювати до створення екранів. Він показує, де потрібна автоматизація, а де рішення має залишитися за менеджером. Наприклад, якщо фінальна ціна залежить від індивідуальної домовленості, додаток може показувати орієнтовну суму та фіксувати замовлення зі статусом «очікує підтвердження», а не імітувати повністю автоматичну оплату.

Вимоги до мобільного додатку для B2B-замовлень

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

Напрям	Що має отримати партнер	Правило або джерело даних	Рішення для першого релізу
Асортимент	Каталог із категоріями, пошуком, фото, характеристиками та одиницями виміру	Доступність категорій залежить від типу партнера; картка товару надходить з облікової системи або PIM	Показувати лише дозволені товари та ключові параметри для замовлення
Персональні ціни	Ціну, валюту, ПДВ або інше погоджене відображення умов	Прайс визначається договором, групою клієнта, кількістю чи акцією; джерело — ERP, CRM або окремий прайс-модуль	Запитувати актуальну ціну під час формування кошика й фіксувати її в заявці
Повторні покупки	Історію заявок, шаблон кошика та швидке повторення замовлення	Повторне замовлення не повинно копіювати застарілі ціну й залишок без перевірки	Дати змогу скопіювати позиції, після чого повторно валідовувати кошик
Погодження	Статус заявки, коментарі та, за потреби, можливість затвердити її в межах компанії	Ліміти та ролі узгоджуються окремо для кожного клієнта; менеджер виробника може мати право коригування	Почати з одного статусу «на погодженні» та журналу зміни статусів
Залишки	Ознаку доступності, очікувану дату або інформацію про резерв	Потрібно розрізняти фізичний залишок, вільний залишок і резерв; частота оновлення визначається процесом	Не обіцяти точну наявність, якщо система не підтримує резервування в реальному часі
Статуси поставки	Зрозумілий прогрес після оформлення заявки	Статуси мають відповідати фактичним етапам ERP, CRM чи логістичної системи, а не бути декоративними	Вивести лише ті статуси, які команда справді оновлює та може пояснити партнеру

Каталог — це комерційний інструмент, а не вітрина

Мобільний каталог виробника має відповідати способу закупівлі. Для одного бізнесу важливі артикул і швидкий пошук за кодом, для іншого — сумісність товарів, варіанти упаковки чи документи до продукції. Варто окремо погодити, які поля критичні в картці товару: доступна кількість, одиниця продажу, мінімальна партія, вага, термін виробництва, специфікація, аналоги. Не всі дані потрібно переносити в перший реліз; достатньо тих, без яких партнер не може впевнено сформувати заявку.

Ролі та права доступу треба моделювати на рівні компанії

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

Як спроєктувати сценарій замовлення без зайвих кроків

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

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

Перед дизайном варто прийняти кілька конкретних рішень:

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

Інтеграції: де виникає реальна складність

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

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

Окремо домовтеся про поведінку в конфліктних ситуаціях. Наприклад, партнер додав товар, але до підтвердження змінився доступний залишок. Система може запропонувати скоригувати кількість, розділити поставку або передати заявку менеджеру. Який варіант правильний, залежить від операційної моделі; універсального рішення тут немає.

Від чого залежить обсяг робіт і бюджет

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

На оцінку найбільше впливають: кількість ролей і юридичних осіб у кабінеті партнера; логіка прайсів і знижок; якість та доступність API облікових систем; потреба в офлайн-режимі; типи документів; процес резервування; вимоги до журналу дій і сповіщень; підтримка iOS та Android; обсяг адміністрування після запуску. Якщо правила ще не сформульовані, чесніше закласти етап їх уточнення, ніж фіксувати функції на припущеннях.

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

Як підготувати запуск і не перенести хаос у застосунок

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

Контрольний список для власника продукту:

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

Найкращою відправною точкою буде не перелік «бажаних екранів», а короткий опис одного реального замовлення: хто його створює, за якою ціною, з якими обмеженнями, хто підтверджує та звідки надходить статус. Коли цей ланцюг прозорий, можна обґрунтовано визначити склад MVP, інтеграції та пріоритети розвитку додатку для дилерів.

Поширені запитання

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

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

Чи обов’язково показувати точні залишки в додатку?

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

Як працюють персональні ціни для різних дилерів?

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

Чи можна запустити додаток без онлайн-оплати?

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

Що включити до MVP B2B-додатку?

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

Які дані потрібно підготувати до старту розробки?

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

Чому інтеграція з ERP або CRM впливає на обсяг проєкту?

Інтеграція визначає, як додаток отримує товари, ціни, залишки та статуси, а також як передає нові заявки. Обсяг залежить від доступності API, правил синхронізації, обробки помилок, резервування та того, яка система є джерелом істини для кожного типу даних.

Мобільний додаток для B2B-замовлень виробника: як спроєктувати без зайвих функцій