💼

Розділ зрілості

Продажі

Ліди, пропозиції, договори, рахунки, ПН, дебіторка. Питання тут не «скільки ви продаєте», а «скільки з цього справді отримаєте грошима і за який час». У defense-tech продаж іде через Прозоро.МО — з тендерною документацією і фіксованими контрактами.

Ключові питання Discovery

Це питання, які BA ставить на першому воркшопі. Відповіді нижче по матриці зрілості допоможуть зрозуміти, який варіант відповіді — ваш.

Скільки активних лідів зараз у вашому pipeline? Хто тримає ці дані?
Скільки часу минає від запиту клієнта до підписаного договору?
Як ви формуєте і реєструєте податкові накладні? Скільки відмов ЄРПН за минулий рік?
Чи можете на дату Х показати дебіторську заборгованість з aging-аналізом?
Який відсоток продавців працює в CRM щодня — не «час від часу»?

Матриця зрілості

L1 · Ремісниче

Excel + папір + у голові бухгалтера

L2 · Стандартизоване

BAS / 1С + окремі програми

L3 · Інтегроване

Odoo Enterprise + Oblik-ERP

Усі рівні Лише L1 Лише L2 Лише L3

Ліди та CRM

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

L1 · Ремісниче

Ліди живуть у голові продавця, у його телефоні, в Outlook-листах. Pipeline існує хіба умовно. Звільняється продавець — усі контакти йдуть разом із ним.

Симптоми

На питання «скільки активних угод?» відповідь — «зараз згадаю…»
Контакти клієнтів — у приватних телефонних книжках
Немає продавця на місці — клієнти зависають

Приклад: Продавець Олексій веде 40 лідів у власному Excel-файлі й не показує нікому. Звільнився — 40 лідів зникло, за 3 місяці вдалося відновити 12.

⚠ Клієнтська база зникає разом із людиною. Реальний pipeline неможливо оцінити, а отже й спрогнозувати.

L2 · Стандартизоване

Ліди — в Excel-таблиці або базовій CRM (HubSpot Free, Bitrix24 free). Заповнюють раз на тиждень чи коли «нагадає директор». Аналіз pipeline — на око.

Симптоми

Є файл «Ліди 2026.xlsx» на 200+ рядків
Востаннє оновлювали 2-3 тижні тому
Поля на кшталт «ймовірність закриття» заповнені навмання

Приклад: У CRM 150 лідів, з них 90% без оновлень за останній місяць. Справді активних — 25, але про це знає лише один продавець.

⚠ Прогноз pipeline хибить на 30-50%. Планувати виробництво чи закупівлі під «очікувані угоди» небезпечно.

L3 · Інтегроване

Odoo CRM із повним pipeline: Lead → Opportunity → Quote → Order. Воронка розбита на стадії, у кожної угоди є відповідальний, очікувана дата закриття та ймовірність. Завдання живі. Email-інтеграція сама логує листування.

Симптоми

Дашборд pipeline показує реальний стан у real-time
Угода без руху понад 14 днів — автоматичне нагадування
Прогноз продажів на 30/60/90 днів з оцінкою точності

Приклад: Дашборд продажів: 87 активних угод на 32 млн UAH. У stage «Quote sent» — 12 угод на 8 млн з очікуваним закриттям до 30-го. У stage «Negotiation» — 6 угод на 4.2 млн. Конверсія минулого кварталу — 18%: тверезо, без «усе закриємо».

Комерційні пропозиції

Шаблон — не дизайнерська забаганка, а швидкість і єдиний вигляд для всіх пропозицій.

L1 · Ремісниче

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

Симптоми

Пропозицію готують 1-3 дні
Помилки в цінах виринають уже після відправлення
Версії розрізняють назвою файлу — «Пропозиція клієнту Х v3 final FINAL»

Приклад: Продавець готує пропозицію на 50 дронів. Збирає специфікацію з трьох джерел, рахує в Excel, переносить у Word, форматує. 5 годин роботи — а у фінальній версії похибка в ціні на 8%. Виправляє постфактум і втрачає довіру.

⚠ Шлях до угоди вдвічі-втричі довший, ніж у конкурентів. Угоди зриваються через повільну реакцію.

L2 · Стандартизоване

Шаблон пропозиції в BAS або Word. Базовий конфігуратор продукту працює за прайс-листом. Пропозицію складають за 2-4 години. Версії веде CRM.

Симптоми

Шаблон із фірмовими реквізитами, базовим описом і місцями під специфікацію
Прайс-лист в Excel, оновлюють раз на квартал
Складні конфігурації все одно збирають руками

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

⚠ Зміняться ціни — треба оновити прайс і сповістити всіх продавців. Дехто тижнями працює зі старою версією.

L3 · Інтегроване

sale.order в Odoo з product configurator: динамічні опції, автоматичний розрахунок ціни за варіантами, знижки за матрицею. Комерційну пропозицію Odoo генерує одним кліком і надсилає клієнту з електронним підписом. Конверсія Quote → Order — теж один клік.

Симптоми

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

Приклад: Запит на дрон із 8 опціями (камера, дальність, корисне навантаження, упаковка): продавець обирає опції в sale.order, і ціна сама перераховується за варіантами та кількістю. За 12 хвилин клієнтові йде комерційна пропозиція в PDF з електронним підписом. За 3 дні — accept, і sale.order створюється автоматично.

Договірна робота

Договори — не «папір на полиці», а звід юридичних зобов'язань, що б'ють по cashflow і по відповідальності.

L1 · Ремісниче

Договори паперові, лежать у шафі в юриста. Версії розрізняють датою на титульнику. Статус (виконано / порушено / закрито) тримає в голові тільки юрист — і то по пам'яті.

Симптоми

Знайти конкретний договір — 30-90 хвилин
Терміни поставок, оплат, рекламацій губляться
Штрафні санкції контрагентам не нараховують, бо «забули»

Приклад: Договір з МО на 8 млн UAH підписано 2025-12-15. Юрист пам'ятає, що договір є, але термінів ніхто не контролює. Поставку прострочили на 8 днів — штраф 4% від суми = 320k UAH, а виявили це лише на перевірці контракту через 6 місяців.

⚠ Штрафні санкції, втрачені контракти, судові спори — усе те, чого можна було уникнути.

L2 · Стандартизоване

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

Симптоми

Папка «Договори 2026» зі скан-копіями
Excel-реєстр на 50 полів, бухгалтер оновлює раз на тиждень
Контроль реактивний — про прострочення дізнаються постфактум

Приклад: Реєстр договорів в Excel: 240 рядків, остання колонка «Статус». Раз на тиждень бухгалтер проставляє «виконується / виконано / прострочено». Точність — 80%, відставання — 5-7 днів.

⚠ Прострочення все одно загрожують. Підготовка до аудиту — 2-3 тижні на саму лише викладку договорів.

L3 · Інтегроване

Договірний модуль в Odoo (Documents + Project + Approvals): історія версій, прив'язка до sale.order/purchase.order, контрольні точки за термінами. Електронний підпис через інтеграцію в стилі DocuSign. Автоматичні нагадування про терміни, що наближаються.

Симптоми

Кожен договір — об'єкт в Odoo з версіями, статусом і контрольними датами
Термін близько (поставка, оплата) — відповідальному йде автоматичне сповіщення
Електронний підпис обох сторін фіксується з timestamp

Приклад: Контракт з МО на 50 дронів підписано електронно 2026-04-10. Контрольні точки: 2026-05-15 (перший етап поставки), 2026-06-30 (фінальна). За 7 днів до кожної відповідальний менеджер дістає automated escalation із checklist. Прострочити, нічого не роблячи, тут просто неможливо.

Виставлення рахунків і ПН

ПДВ — найжорсткіша зона. Помилка в ПН тягне санкції за ПКУ, помилка в реєстрації в ЄРПН — штрафи.

L1 · Ремісниче

Рахунки виставляють в Excel руками, друкують, надсилають клієнту. Податкову накладну формують окремо в М.Е.Doc, дані вбивають вручну. Реєстрація в ЄРПН теж ручна, з затримками.

Симптоми

Рахунок-фактура в Excel-шаблоні, реквізити вбивають руками
ПН реєструють у ЄРПН через 5-15 днів після відвантаження
Штрафи за несвоєчасну реєстрацію за рік — 20-40%

Приклад: Відвантажили 10 дронів 3-го числа. ПН зареєстрували 18-го — через 15 днів. Штраф за ПКУ 1201 — 20% від суми ПН = 100k UAH. Бухгалтер виправдовується: «був завал».

⚠ Штрафи за ПКУ 1201 за прострочену реєстрацію ПН — 10-50% від суми ПН. За рік для середньої компанії це 500k-2 млн UAH.

L2 · Стандартизоване

BAS виставляє рахунки за наперед налаштованими шаблонами. ПН формується автоматично за продажем, але для реєстрації її експортують у М.Е.Doc. Реєструють за 5-10 днів, з помилками 5-15% — відмовами ЄРПН.

Симптоми

Рахунок у BAS — натиснув кнопку, маєш готовий PDF
ПН формується автоматично за sales document
Експорт у М.Е.Doc ручний, раз на день

Приклад: Уранці бухгалтер експортує з BAS усі вчорашні ПН, завантажує в М.Е.Doc, перевіряє, реєструє. Це 1-2 години на день. Відмови ЄРПН — 8-10%: не той код товару, не та ставка тощо.

⚠ Бухгалтерський час на ручний експорт. Помилки в ставці ПДВ — надто при пільгах, як-от оборонна продукція за ПКУ 197.6.

L3 · Інтегроване

Odoo сам формує ПН на підтвердженні відвантаження — за першою подією або за фактом. Пряма інтеграція з ЄРПН через API М.Е.Doc чи Vchasno. Реєстрація — протягом 15 хвилин після події. Перед відправкою спрацьовує pre-validation, що відсіює помилки.

Симптоми

ПН реєструється автоматично, без участі бухгалтера
Відмов ЄРПН менше 1%, кожна з автоматичним сповіщенням і виправленням
Для оборонної продукції ставка 0% за ПКУ 197.6 застосовується автоматично

Приклад: Відвантаження 50 дронів МО за договором зі ставкою 0% ПДВ. Sale.order підтверджено о 14:30. О 14:32 Odoo сформував ПН. О 14:45 — реєстрація в ЄРПН через API. О 14:47 — підтвердження. Бухгалтер бачить «Готово» й нічого не робить.

Дебіторка

Cash flow компанії = «коли заплатить клієнт» мінус «коли платити вам». На L1 ви бачите лише другу частину, першу — ні.

L1 · Ремісниче

Раз на тиждень бухгалтер обдзвонює клієнтів з нагадуваннями. Точну суму дебіторки до кінця місяця ніхто не знає. Aging — на око.

Симптоми

На питання «скільки нам винні?» — приблизна оцінка
Прострочена дебіторка понад 60 днів — звична річ
Безнадійну ДЗ не списують — вона роками висить на 36 рахунку

Приклад: ДЗ на 1-ше число — «приблизно 3.5 млн». Насправді — 4.2 млн. З них 800k старші за 90 днів, і бухгалтер про них забув.

⚠ Касові розриви, неспроможність планувати оплати постачальникам. ДЗ тліє прихованою проблемою — аж поки клієнт не збанкрутує.

L2 · Стандартизоване

BAS-звіт «Заборгованість покупців» з aging-розподілом, раз на тиждень. CFO його отримує й реагує заднім числом. Менеджери відділу продажів його не бачать.

Симптоми

Звіт ДЗ доступний у BAS
Раз на тиждень CFO його переглядає і дає вказівки бухгалтеру
Менеджер дізнається про прострочення свого клієнта з третіх рук

Приклад: Понеділок: CFO відкриває BAS-звіт і бачить, що ТОВ «Х» винне 240k UAH уже 35 днів. Передає вказівку менеджеру Олексію. Олексій телефонує клієнту — оплата за тиждень.

⚠ Реакція замість випередження. Менеджер особисто не відповідає за дебіторку своїх клієнтів.

L3 · Інтегроване

Real-time дашборд на рівні менеджера: «Моя дебіторка» з aging. Клієнту автоматично йдуть нагадування на email/SMS за 7/3/0 днів до терміну. У KPI менеджера входить середній DSO (Days Sales Outstanding). CFO бачить зведену картину.

Симптоми

Кожен менеджер бачить у дашборді ДЗ своїх клієнтів
Нагадування на email ідуть автоматично за заданим графіком
DSO — KPI менеджера, що впливає на бонусну частину

Приклад: Менеджер Олексій відкриває Odoo: «Моя ДЗ — 1.8 млн UAH, з них 200k прострочено. ТОВ Х (180k) — лист-нагадування пішов учора автоматично. ТОВ Y (20k) — піде завтра». Олексій передзвонює в ТОВ Х і узгоджує графік оплати. І все це — без бухгалтера.

Як рости

L1 → L2 (від ручного до BAS/1С)

Заведіть базову CRM (хай навіть безкоштовну) й зробіть ведення лідів обов'язком продавців
Зробіть єдиний шаблон комерційної пропозиції з фірмовими реквізитами і структурою
Складіть Excel-реєстр договорів із ключовими полями і контрольними датами
Запровадьте щотижневий звіт дебіторки для CFO з aging-аналізом
Налаштуйте щоденну автоматичну реєстрацію ПН у ЄРПН через М.Е.Doc

L2 → L3 (від BAS до Odoo + Oblik-ERP)

Спроєктуйте sales pipeline в Odoo CRM зі стадіями, активностями, KPI
Впровадьте product configurator для типових продуктів з варіантами
Запустіть API-інтеграцію з ЄРПН через М.Е.Doc/Vchasno для real-time реєстрації
Для defense — інтеграція з Прозоро через API для тендерних закупівель
Розгорніть портал клієнта з акцептом пропозицій і оплатою онлайн
Налаштуйте автоматичні нагадування дебіторам з ескалацією за aging-bracket

Продажі — ділянка, де перехід L1 → L3 дає найшвидший видимий ROI: цикл продажу коротшає на 30-50%, прострочення дебіторки спадають на 40-60%, штрафи ЄРПН сходять до нуля. Надто в defense-tech, де продаж іде через Прозоро.МО — з тендерною документацією і жорсткими вимогами до швидкості реакції.

Є один нюанс: сама технологія не змусить продавця працювати в CRM, якщо цього не вимагає менеджмент. Тому L1→L2 — це на 70% про дисципліну і на 30% про систему. L2→L3 — навпаки: дисципліна вже є (30%), а решта 70% — інтеграції: ЄРПН, банк, Прозоро, портал клієнта. Бюджет проєкту — 4-8 місяців. Окупність зазвичай у перший рік — за рахунок менших штрафів і коротших касових розривів.