B2B-портал — це робочий кабінет для компаній, які регулярно купують у постачальника. На відміну від звичайного відкритого магазину, тут замовлення залежить від договору, ролі користувача, персональної ціни, відстрочки оплати та доступного складу. Основна задача порталу — дати партнеру потрібні дані й дії, не змушуючи менеджера вручну переносити кожен запит.
Почніть із правил між компаніями
Одна компанія-покупець може мати кількох співробітників. Закупівельник складає замовлення, керівник погоджує його, а бухгалтер переглядає рахунки. Тому поняття «клієнт» і «користувач» варто розділити. Портал має знати, до якої організації належить людина, які дії їй дозволені та хто може змінювати ці права.
До проєктування також входять мінімальна партія, кратність упаковки, доступні склади та обмеження за договором. Це не декоративні поля профілю: від них залежить, чи можна прийняти замовлення. Якщо правила залишаються лише в голові менеджера, інтерфейс не зможе надійно підказати партнеру наступний крок.
Персональна ціна потребує джерела та перевірки
Визначте, де обчислюється ціна: у порталі, ERP чи іншій системі. Погодьте валюту, округлення, знижки та час актуальності пропозиції. Покупець може відкрити кошик зранку, а надіслати його ввечері, коли умови вже змінилися. Перед підтвердженням замовлення система повинна повторно перевірити ціни й зрозуміло показати зміни.
Відображення правильної цифри у браузері недостатньо. На сервері перевіряють організацію, доступ до товару та застосовність умов. Користувач не повинен отримати чужий прайс або документи іншого партнера, просто змінивши номер у посиланні.
Навчальний сценарій: повторне замовлення
Уявімо дистриб’ютора, партнер якого щотижня закуповує однакові витратні матеріали. Закупівельник відкриває попереднє замовлення й повторює його. Частина позицій доступна, інша очікується на складі. Портал має запропонувати погоджений варіант: розділити постачання, зменшити кількість або передати питання менеджеру. Мовчки прибрати відсутні позиції означало б змінити потребу покупця.
Після погодження замовлення отримує спільний ідентифікатор у кабінеті та обліку. Якщо обмін перервався, повторне надсилання має продовжити ту саму операцію. Партнеру потрібен зрозумілий стан «очікує підтвердження», а команді постачальника — журнал, за яким можна знайти причину затримки.
Як формуємо вимоги до такого рішення
У напрямі B2B-розробки ALL IT Agency ми розглядаємо ролі, персональні умови та обмін з обліком як пов’язані частини задачі. До початку реалізації корисно скласти матрицю: роль, дія, дані, перевірка. Окремо описують ситуації, коли дія заборонена або потребує погодження. Така матриця стає основою інтерфейсу, серверних перевірок і приймальних сценаріїв.
-
Партнер бачить лише власні ціни, замовлення та документи.
-
Повторне надсилання не створює дубль замовлення.
-
Зміни цін і наявності показані до остаточного підтвердження.
-
Результат погодження однаково відображений у порталі та обліку.
Що передати команді після запуску
Разом із порталом потрібні правила створення партнерів, призначення ролей і відкликання доступу. Визначте відповідального за довідники та контакти з приводу помилок обміну. Зручний кабінет не усуває потребу в менеджері: він звільняє його від повторюваних операцій і залишає людині нестандартні домовленості, суперечки та винятки.
Джерела та подальше читання
