Розробка B2B порталу: де ламається облік замовлень
Розробка B2B порталу майже завжди впирається не в інтерфейс, а в облік замовлень. Поки менеджер вручну переносить заявку з пошти в облікову систему, клієнт бачить одну ціну, а в рахунку приходить інша — розбіжність випливає вже на етапі оплати. Кожна така помилка в заявках коштує повторного узгодження, а іноді й втраченого замовлення.
Синхронізація цін — друге джерело збоїв. Прайс оновлюється в обліковій системі, але на порталі залишається вчорашній: знижка за договором не підтягнулася, індивідуальні умови для дилера не врахувалися, залишки по складу розійшлися з реальними.
Клієнт оформлює замовлення за застарілою ціною, і далі починається ручне виправлення — те саме, заради усунення якого портал і будували.
Ручне введення замовлень небезпечне не швидкістю, а тим, що воно не залишає сліду. Незрозуміло, хто змінив кількість, чому змінилася ціна, на якому кроці заявка втратила позицію.
Коли таких замовлень десятки на день, помилки перестають бути винятком і стають тлом: повернення, спори щодо відвантаження, звірки, які сходяться не з першого разу.
Розбираємо, як це закривається на рівні архітектури: єдине джерело цін і залишків, автоматична передача замовлень в облікову систему, журнал змін по кожній позиції.
Що дає портал: вимірювані ефекти для відділу продажів
Розробка B2B-порталу дає ефект, який видно в цифрах відділу продажів, а не в презентації.
Швидкість оформлення замовлення падає з годин до хвилин: клієнт сам збирає кошик за своєю номенклатурою, бачить залишки та ціни за своїм договором, а заявка надходить в облікову систему без передруковування.
Менеджер перестає бути оператором введення — він займається угодою, а не перенесенням рядків з листа в таблицю.
Частка ручних операцій скорочується завдяки тому, що повторювані сценарії закриває портал: перерахунок цін за узгодженими умовами, перевірка лімітів і заборгованості, підстановка реквізитів і адрес доставки, формування документів за шаблоном.
Кожна така дія раніше займала в менеджера хвилини й була джерелом помилок — тепер виконується за правилом, однаково для всіх клієнтів.
Окрема стаття ефекту — усунені відмови. Портал відсікає замовлення на етапі оформлення, якщо позиції немає в наявності, термін виходить за обіцяний клієнту, сума перевищує кредитний ліміт або реквізити не збігаються з карткою контрагента.
Це ті відмови, які раніше випливали на етапі збирання й відвантаження, коли клієнт уже чекав, а менеджер витрачав час на узгодження.
Навантаження на менеджерів перестає зростати разом із кількістю клієнтів: потік замовлень іде через портал, а ручне втручання залишається лише на нестандартних умовах. Розбираємо, як це закривається на рівні інтеграції з обліковою системою та ролей доступу.
Варіанти реалізації: коробка, конструктор, замовна розробка
Вибір підходу визначає не лише термін запуску, а й те, що ви зможете змінювати в порталі через рік-два.
Готова платформа та конструктор дають швидкий старт, але їхня логіка фіксована: ціни під клієнта, ліміти, персональні умови договорів та обмін з обліковою системою доводиться вбудовувати в чужі правила.
Замовна розробка стартує довше, зате модель даних, ролі та інтеграції проєктуються під ваш процес продажів, а не навпаки.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готова платформа | Типовий каталог, стандартні ціни, обмін з обліковою системою «з коробки» | Логіку ціноутворення та ролі змінюєте лише в межах налаштувань вендора; нестандартний сценарій замовлення впирається в обмеження платформи |
| Конструктор сайтів | Швидкий запуск вітрини, невеликий асортимент, мінімум інтеграцій | Слабке масштабування порталу: складні права доступу, історія замовлень та обмін з обліковою системою потребують зовнішніх надбудов |
| Замовна розробка | Індивідуальні ціни та ліміти, кілька юросіб, глибока інтеграція з обліковою системою | Довший вихід на першу версію; потрібен підрядник, який веде портал і після запуску |
На що дивитися при виборі
Рахуйте не вартість ліцензії, а ціну доопрацювання під ваш сценарій: у платформи вона зростає з кожною нестандартною правкою, у замовної розробки — фіксується на етапі проєктування. Перевірте, як варіант переживе зростання: додавання філій, валют, договірних цін і ролей.
Де найчастіше впираються
Обмін з обліковою системою та права доступу — два місця, де готова платформа і конструктор потребують обхідних рішень. Якщо ці вузли у вас ключові, замовна розробка окупається на першому ж доопрацюванні.
Етапи робіт: від аудиту облікової системи до запуску
Порядок етапів не випадковий: кожен наступний крок спирається на артефакт попереднього. Якщо пропустити аудит облікової системи і одразу почати «малювати портал», інтеграція з 1С спливе на прийманні — і переробка зачепить і схему даних, і логіку замовлень.
- Аудит облікової системи. Розбираємо конфігурацію 1С: які довідники та регістри реально використовуються, де ведеться номенклатура, як влаштовані ціни та залишки, які доопрацювання вже є. На виході — карта даних і список вузьких місць, які не можна тягнути в портал як є.
- Проєктування схеми інтеграції. Визначаємо, що портал читає з облікової системи, а що пише назад, і в якому напрямку йдуть замовлення, статуси та ціни. Фіксуємо протокол обміну, склад сутностей і правила зіставлення номенклатури — це ядро всієї подальшої роботи.
- Налаштування обміну. Піднімаємо сервісний шар між порталом і 1С, налаштовуємо розклад синхронізації та обробку конфліктів, коли замовлення і залишок змінюються одночасно. Окремо закриваємо поведінку при недоступності облікової системи — портал не повинен втрачати замовлення.
- Складання порталу. Особистий кабінет, каталог з персональними цінами, кошик, історія замовлень, документи. Ролі та права розводимо за менеджерами, клієнтами й адміністраторами, щоб кожен бачив лише свої дані.
- Приймальні перевірки. Проганяємо сценарії на реальних даних: оформлення замовлення, перерахунок цін, статуси, вивантаження документів. Звіряємо суми та залишки між порталом і обліковою системою — розбіжність тут означає помилку в схемі обміну.
- Запуск порталу. Переносимо на робочий контур, підключаємо моніторинг обміну та оповіщення про помилки синхронізації, навчаємо менеджерів. Перші тижні ведемо посилене спостереження за чергою обміну.
Після запуску залишається регламент підтримки: як додаються нові сутності, як оновлюється облікова система без зупинки обміну. Опишіть вашу конфігурацію 1С і процеси — повернемося з оцінкою та планом за етапами.
Що замовник отримує на руки після впровадження
Впровадження закінчується не запуском, а передачею комплекту, за яким портал можна експлуатувати, розвивати та передавати іншій команді. Нижче — що саме залишається у замовника.
- Схема інтеграції — карта обміну між порталом, обліковою системою та зовнішніми сервісами: які сутності синхронізуються (номенклатура, ціни, залишки, замовлення, статуси), у який бік, з якою періодичністю і що відбувається при розходженні.
- Регламент обміну — правила поведінки при збоях: вікно синхронізації, порядок повторного вивантаження, обробка конфліктів цін і залишків, журнал операцій і точки, де адміністратор бачить причину розходження.
- Матриця доступу — ролі клієнтів, менеджерів і адміністраторів з розмежуванням за розділами, типами документів і операціями; окремо фіксуються права на зміну цін, підтвердження замовлень і вивантаження даних.
- Конфігурації середовищ — налаштування порталу, інтеграційних модулів і черг, схема резервного копіювання та порядок розгортання на новому середовищі без ручного складання «по пам'яті».
- Інструкція адміністратора — покрокові сценарії: додавання клієнта і менеджера, правка каталогу, розбір завислого обміну, відкат невдалої синхронізації, читання логів.
- Документація порталу — опис структури розділів, моделі даних, точок розширення та зовнішніх залежностей, щоб доопрацювання не починалися зі зворотного проєктування.
- Комплект для передачі — доступи, схема розміщення, контакти відповідальних і перелік відомих обмежень з планом їх закриття.
Комплект збирається по ходу робіт, а не в кінці: схема інтеграції та матриця доступу узгоджуються до розробки, регламент обміну — на етапі підключення облікової системи, інструкції — на приймальних сценаріях. До передачі кожна частина вже перевірена на реальних операціях, а не написана формально.
Опишіть задачу — повернемося з оцінкою та планом, включно зі складом документації, що передається, під ваш контур.
Кейс: як портал прибрав подвійне введення замовлень
До замовника прийшли з класичним болем: менеджери приймали замовлення в пошті та Excel, потім вручну переносили ті самі позиції в облікову систему. Одне замовлення проходило через два введення, і кожна звірка перетворювалася на окрему операцію.
Ми почали з аудиту процесу — заміряли, скільки часу йде на обробку одного замовлення і де виникають розбіжності.
Що було до порталу
Замовлення надходили у вільній формі: лист, дзвінок, таблиця від постійного клієнта. Менеджер збирав позиції, уточнював залишки по телефону зі складом і лише потім заводив документ.
На одне замовлення йшло в середньому 40 хвилин, а помилки комплектації спливали вже на відвантаженні — клієнт отримував не те, що замовляв.
Що змінили
Розробили B2B-портал з особистим кабінетом: клієнт бачить актуальні залишки, ціни за своїм договором та історію замовлень. Замовлення оформлюється в інтерфейсі й іде в облікову систему напряму, без ручного перенесення.
Інтеграцію з 1С налаштували в обидві сторони — статуси, рахунки та відвантаження повертаються в кабінет автоматично.
Що стало після запуску
Час обробки замовлення скоротився з 40 до 6 хвилин: менеджер лише підтверджує, а не перебиває позиції. Частка замовлень з помилками комплектації впала з 12% до 1,5% — розбіжності ловляться на етапі оформлення, а не на складі.
Навантаження на відділ продажів знизилося настільки, що два менеджери переключилися на роботу з новими клієнтами замість рутинного введення.
Результати замовник підтвердив за своєю внутрішньою статистикою за перші місяці роботи порталу. Окремо відзначив, що підтримку ми ведемо за регламентом: інциденти з інтеграцією закриваються протягом робочого дня, а не «коли дійдуть руки».
Чим відрізняється портал від особистого кабінету на готовій платформі?
Особистий кабінет на готовій платформі — це надбудова над чужою моделлю даних. Платформа задає структуру сутностей: користувач, замовлення, товар, рахунок. Ви можете перейменувати розділи, додати поля, налаштувати права — але зв'язки між сутностями залишаються вендорськими.
Щойно бізнес-логіка розходиться з цією моделлю (наприклад, ціна залежить від узгодженої з клієнтом матриці знижок, а платформа вміє лише фіксований прайс і промокод), починаються обхідні рішення: зовнішні таблиці, ручні операції, синхронізація «в один бік».
Замовний портал проєктується від процесів замовника, а не від шаблону. Модель даних, ролі та правила погодження описуються так, як вони реально працюють: хто затверджує замовлення, на якому етапі підключаються фінанси, як перераховується ціна при частковому відвантаженні.
Кастомізація логіки тут — не «допилювання» платформи, а її вихідний стан. Тому інтеграція з обліковою системою йде за подіями в обидва боки, а не пакетним вивантаженням за розкладом.
Обмеження типових рішень проявляються не відразу, а на зростанні. Поки замовлень десятки, кабінет справляється.
Коли з'являються філії, індивідуальні умови та кілька юросіб під одним клієнтом, платформа впирається у власні ж абстракції: частину сценаріїв доводиться виносити за її межі.
На замовному порталі такі гілки закладаються в архітектуру заздалегідь — розширення не ламає вже працюючі процеси.
Практичний критерій вибору простий. Якщо ваші процеси вкладаються в типовий сценарій «клієнт бачить каталог, кладе в кошик, отримує рахунок» — готова платформа закриє завдання швидше.
Якщо логіка ціноутворення, погодження та відвантаження унікальна і є конкурентною перевагою — кабінет на платформі стане постійним джерелом обхідних рішень, а замовний портал окупиться на першій же зміні правил.
Часті технічні сумніви перед стартом
Перед стартом розробки B2B-порталу замовники найчастіше піднімають три теми: чи витримає портал пікове навантаження, як захищені дані контрагентів і наскільки надійно він пов'язаний з обліковою системою. Нижче — розбір типових сумнівів, які ми закриваємо на етапі проєктування, а не після запуску.
Портал витримає, якщо завтра кількість замовлень зросте в рази?
Закладаємо запас за навантаженням з першого дня: горизонтальне масштабування застосунків, кешування каталогу та залишків, винесення важких вибірок в окреме сховище.
Пікові періоди — розпродажі, закриття місяця, масове введення заявок — відпрацьовуються без деградації, бо вузькі місця ми знаходимо на навантажувальних випробуваннях, а не в бою.
Зростання кількості користувачів і замовлень не потребує переписування порталу — додаються ресурси під уже спроєктовану архітектуру.
Як захищені дані контрагентів і розмежовані ролі?
Доступ будується на рольовій моделі: менеджер бачить лише своїх клієнтів, контрагент — лише свої замовлення, рахунки та документи, адміністратор керує довідниками. Дані шифруються під час передавання та зберігання, дії користувачів потрапляють до журналу аудиту. Це закриває і вимоги служби безпеки, і практику перевірок: видно, хто, коли і що змінив.
Наскільки надійна інтеграція з 1С і що буде при збої?
Обмін з обліковою системою йде через шар інтеграції з чергами та повторними спробами: якщо 1С недоступна, замовлення та залишки не губляться, а довантажуються при відновленні зв'язку. Синхронізуємо номенклатуру, ціни, залишки, взаєморозрахунки та статуси замовлень.
Резервне копіювання налаштовано за розкладом з перевіркою відновлення — ми знаємо час повернення в роботу, а не сподіваємося на нього.
Чи можна запускати портал поетапно і не зупиняти продажі?
Так. Виносимо критичний контур — каталог, замовлення, інтеграцію — у першу чергу, решту модулів підключаємо ітераціями. Стара схема приймання замовлень працює, поки нова не підтвердить стабільність на реальних даних. Так перехід проходить без розриву в обслуговуванні клієнтів.
Опишіть ваше завдання — повернемося з оцінкою та планом робіт за вашим контуром.
Обговоримо ваше завдання і повернемося з оцінкою
Порядок робіт над B2B-порталом ми показуємо на реальному кейсі: дистриб'ютор із 4000 позицій у каталозі вів замовлення в пошті та Excel, менеджери вручну звіряли залишки з обліковою системою.
Портал зібрали на 1С-Бітрікс з обміном номенклатурою та цінами за розкладом, особистим кабінетом з історією замовлень і рольовою моделлю для оптових клієнтів.
Що змінилося після запуску
Частка замовлень, оформлених через портал, зросла з нуля до 70% за перший квартал — менеджери перестали бути єдиним каналом приймання.
Розбіжність залишків між порталом і обліковою системою скоротилася з годин до хвилин завдяки регулярному обміну, а ручне введення позицій у замовлення прибрали повністю.
Що входить до плану робіт
- аудит поточних процесів продажів і облікової системи замовника;
- проєктування моделі даних: номенклатура, ціни, договори, ролі;
- прототип особистого кабінету та сценаріїв оформлення замовлення;
- інтеграція з 1С: обмін залишками, цінами, статусами замовлень;
- розробка й тестування на реальних даних замовника;
- перенесення на робочий контур і навчання менеджерів;
- підтримка після запуску та доопрацювання за зворотним зв'язком.
Щоб повернутися з оцінкою термінів і складу робіт, нам потрібен доступ до вашої облікової системи або вивантаження номенклатури, список ролей користувачів і розуміння, які сценарії замовлення критичні в першу чергу. Опишіть завдання — повернемося з планом і термінами.
