Перегляд вихідного коду сторінки Особа, що приймає рішення

{{DISPLAYTITLE:Особа, що приймає рішення}}

{{SEO
|title=Особа, що приймає рішення — Decision Maker у CRM, B2B-продажах, договорах і Key Account Management
|description=Особа, що приймає рішення — це контактна особа клієнта, яка має повноваження затвердити покупку, бюджет, договір, вибір постачальника або продовження співпраці. У CRM та ERP decision maker є важливим елементом B2B-продажів, карти контактів, воронки продажів, договорів, оплат, Customer Success і Key Account Management.
|keywords=особа що приймає рішення, decision maker, DM, ЛПР, ЛПР у CRM, B2B продажі, контактна особа, карта контактів, B2B-клієнт, ключовий клієнт, CRM, ERP, K2 ERP, договори в CRM, контроль оплат, Key Account Management, Customer Success
|image=https://erp.kyiv.ua
}}

'''Особа, що приймає рішення''' або '''Decision Maker''' — це [[Контактна особа|контактна особа]] клієнта, яка має повноваження прийняти, затвердити або заблокувати рішення щодо покупки, договору, бюджету, постачальника, впровадження, продовження співпраці або зміни умов.

У [[CRM]] особа, що приймає рішення, є важливою частиною [[Картка клієнта|картки клієнта]], [[B2B-клієнт|B2B-клієнта]], [[Ключовий клієнт|ключового клієнта]], [[Воронка продажів|воронки продажів]], [[Задачі менеджерів|задач менеджерів]], [[Історія комунікацій|історії комунікацій]], [[Договори в CRM|договорів]], [[Контроль оплат|контролю оплат]], [[Customer Success]] і [[Key Account Management]].

В [[ERP]] decision maker може бути пов’язаний із договором, рахунком, погодженням бюджету, закупівельним процесом, оплатою, продовженням договору, сервісним контрактом або стратегічним рішенням щодо співпраці.

<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Головне.''' Особа, що приймає рішення, — це не обов’язково той, хто першим звернувся або щоденно користується продуктом. Це людина, яка може сказати фінальне “так”, “ні” або “потрібно погодити інакше”.
</div>

<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Для CRM.''' У картці B2B-клієнта потрібно чітко фіксувати, хто є decision maker, хто впливає на рішення, хто користується продуктом, хто погоджує бюджет, хто перевіряє договір і хто відповідає за оплату.
</div>

<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">
'''Для продажів.''' Якщо менеджер працює тільки з користувачем або ініціатором, але не має контакту з особою, що приймає рішення, угода може зупинитися на етапі погодження бюджету, договору або фінального вибору.
</div>

<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Важливо.''' У складних B2B-продажах рішення часто приймає не одна людина, а група: директор, фінансовий директор, IT, юрист, керівник підрозділу, закупівлі та майбутні користувачі. CRM має показувати цю карту впливу.
</div>

__TOC__

== Вступ ==

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

Але перший контакт не завжди є людиною, яка приймає фінальне рішення.

Наприклад:

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

Тому в CRM важливо не просто зберігати контакти, а розуміти, хто яку роль має в процесі прийняття рішення.

== Що таке особа, що приймає рішення ==

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

Вона може приймати рішення щодо:

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

У CRM така людина часто позначається як '''Decision Maker''', '''DM''' або '''ЛПР'''.

<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Суть decision maker.''' Особа, що приймає рішення, визначає, чи перейде клієнт до наступного етапу: купівлі, договору, оплати, впровадження, продовження або розвитку співпраці.
</div>

== Decision Maker, ЛПР і контактна особа ==

У CRM важливо розрізняти звичайну контактну особу та decision maker.

{| class="wikitable" style="width:100%;"
! Поняття
! Що означає
! Приклад
|-
| Контактна особа
| Будь-яка людина, з якою компанія комунікує
| Менеджер, бухгалтер, користувач, юрист
|-
| Ініціатор
| Людина, яка першою виявила потребу або звернулася
| Керівник продажів шукає CRM
|-
| Користувач
| Людина, яка буде працювати з продуктом
| Менеджери продажів у CRM
|-
| Influencer
| Людина, яка впливає на вибір
| IT-директор, консультант, керівник відділу
|-
| Особа, що приймає рішення
| Людина, яка може затвердити або заблокувати рішення
| Директор, власник, фінансовий директор
|-
| Підписант
| Людина, яка юридично підписує договір
| Директор або уповноважена особа
|}

Decision maker може одночасно бути підписантом, власником бюджету або керівником, але це не завжди одна й та сама людина.

== Чому decision maker важливий ==

Особа, що приймає рішення, важлива тому, що без її участі угода може не завершитися.

Вона впливає на:

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

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

== Типи осіб, що приймають рішення ==

=== Власник бізнесу ===

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

Його цікавить:

* окупність;
* контроль бізнесу;
* зниження витрат;
* зростання продажів;
* прозорість;
* ризики;
* незалежність від працівників;
* довгострокова цінність.

=== Генеральний директор ===

Генеральний директор може затверджувати рішення щодо ERP, CRM, автоматизації, бюджету, підрядників і великих договорів.

Його цікавить:

* управлінська прозорість;
* план-факт;
* контроль підрозділів;
* відповідальність;
* швидкість процесів;
* результат для компанії.

=== Фінансовий директор ===

Фінансовий директор оцінює бюджет, оплату, економічну доцільність і фінансові ризики.

Його цікавить:

* вартість;
* окупність;
* умови оплати;
* бюджет;
* дебіторська заборгованість;
* контроль фінансів;
* звітність;
* ризики договору.

=== Керівник підрозділу ===

Керівник підрозділу може бути decision maker для рішень у межах свого напрямку.

Наприклад:

* керівник продажів — для CRM;
* керівник маркетингу — для email-розсилок;
* керівник сервісу — для Service Desk;
* керівник складу — для складського модуля;
* керівник виробництва — для виробничого обліку.

=== IT-директор ===

IT-директор може не завжди купувати рішення, але часто має право погодити або заблокувати його з технічних причин.

Його цікавить:

* інтеграції;
* безпека;
* API;
* інфраструктура;
* підтримка;
* масштабованість;
* доступи;
* резервне копіювання;
* цифровий суверенітет.

=== Закупівельний комітет ===

У великих компаніях або державних структурах рішення може приймати не одна людина, а група.

Це може бути:

* тендерний комітет;
* закупівельний відділ;
* фінансовий комітет;
* правління;
* робоча група;
* проєктний комітет.

У такому випадку в CRM потрібно фіксувати не одного decision maker, а кількох учасників процесу.

== Ролі в процесі прийняття рішення ==

{| class="wikitable" style="width:100%;"
! Роль
! Вплив на рішення
! Що важливо фіксувати в CRM
|-
| Ініціатор
| Запускає процес пошуку рішення
| Потребу, біль, очікування
|-
| Користувач
| Оцінює зручність і практичну користь
| Сценарії використання, заперечення, NPS
|-
| Influencer
| Формує думку decision maker
| Аргументи, ризики, ставлення до рішення
|-
| Technical approver
| Перевіряє технічну можливість
| Вимоги, API, безпеку, інтеграції
|-
| Legal approver
| Перевіряє договір
| Правки, ризики, строки погодження
|-
| Economic buyer
| Погоджує бюджет
| Суму, умови оплати, ROI
|-
| Decision maker
| Приймає або затверджує фінальне рішення
| Критерії вибору, пріоритет, ризики
|-
| Підписант
| Підписує договір
| Повноваження, ПІБ, реквізити
|}

== Як визначити особу, що приймає рішення ==

Щоб визначити decision maker, менеджер має з’ясувати процес прийняття рішення в клієнта.

Корисні питання:

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

У CRM відповіді на ці питання мають фіксуватися структуровано, а не тільки в коментарях.

== Ознаки decision maker ==

Ознаки особи, що приймає рішення:

* має право затвердити бюджет;
* може сказати фінальне “так” або “ні”;
* підписує договір або погоджує підписання;
* визначає пріоритет проєкту;
* впливає на вибір постачальника;
* може змінити умови;
* відповідає за результат;
* може зупинити або пришвидшити угоду;
* має доступ до керівництва або правління;
* є власником проблеми на рівні бізнесу.

Не завжди decision maker має найвищу посаду. Іноді фактичне рішення приймає керівник напряму, а директор лише формально підписує.

== Decision maker у CRM ==

У [[CRM]] decision maker має бути окремо позначений у картці клієнта або контактної особи.

Бажано фіксувати:

* ПІБ;
* посаду;
* роль;
* компанію;
* контактні дані;
* рівень впливу;
* ставлення до рішення;
* критерії вибору;
* бюджетні повноваження;
* участь у зустрічах;
* заперечення;
* пов’язані задачі;
* історію комунікацій;
* останній контакт;
* наступну дію.

CRM має допомагати менеджеру бачити, чи є контакт із decision maker, а не лише з ініціатором.

== Decision maker в ERP ==

В [[ERP]] особа, що приймає рішення, може бути пов’язана з документами та процесами.

Наприклад:

* погодження договору;
* підписання договору;
* затвердження рахунку;
* бюджетне погодження;
* продовження сервісного договору;
* затвердження специфікації;
* погодження умов оплати;
* прийняття актів;
* погодження додаткової угоди.

ERP допомагає бачити не тільки комунікаційну роль, а й юридичний або фінансовий слід decision maker.

== Decision maker у K2 ERP ==

У '''[[K2 ERP]]''' особа, що приймає рішення, може бути пов’язана з CRM та ERP-процесами.

Можливі зв’язки:

* картка клієнта;
* контактна особа;
* B2B-клієнт;
* ключовий клієнт;
* карта контактів;
* угода;
* задача менеджера;
* історія комунікацій;
* комерційна пропозиція;
* договір;
* рахунок;
* оплата;
* Customer Success;
* Key Account Management;
* повторні продажі;
* Power BI-аналітика;
* AI-підказки;
* відкриті API.

<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''K2 ERP і decision maker.''' У K2 ERP особа, що приймає рішення, може бути частиною карти контактів B2B-клієнта та впливати на угоди, задачі, договори, оплати, повторні продажі й Customer Success.
</div>

== Decision maker і картка клієнта ==

У [[Картка клієнта|картці клієнта]] має бути видно:

* хто є decision maker;
* хто є ініціатор;
* хто є користувач;
* хто є фінансовий контакт;
* хто є юридичний контакт;
* хто є технічний контакт;
* хто впливає на рішення;
* з ким був останній контакт;
* які заперечення є в decision maker;
* яка наступна дія.

Це особливо важливо для B2B та ключових клієнтів.

== Decision maker і контактна особа ==

[[Контактна особа]] може мати роль decision maker.

У картці контактної особи потрібно фіксувати:

* роль у процесі;
* рівень впливу;
* повноваження;
* ставлення до продукту;
* критерії рішення;
* зацікавленість;
* заперечення;
* очікуваний результат;
* участь у зустрічах;
* історію комунікацій.

Одна контактна особа може бути одночасно decision maker, sponsor і підписантом.

== Decision maker і B2B-клієнт ==

Для [[B2B-клієнт|B2B-клієнта]] визначення decision maker є критично важливим.

У B2B часто є:

* кілька користувачів;
* кілька керівників;
* фінансовий контакт;
* IT-контакт;
* юридичний контакт;
* закупівельник;
* підписант;
* зовнішній консультант;
* фактичний decision maker.

Без карти контактів менеджер може помилково вважати, що працює з decision maker, хоча насправді спілкується лише з ініціатором.

== Decision maker і ключовий клієнт ==

Для [[Ключовий клієнт|ключового клієнта]] потрібно мати стабільний контакт із decision maker.

Важливо:

* знати актуального decision maker;
* не залежати від одного контакту;
* підтримувати регулярні зустрічі;
* розуміти стратегічні цілі клієнта;
* знати ризики;
* відстежувати зміну посад;
* оновлювати карту контактів;
* залучати керівництво своєї компанії;
* вести account plan.

Якщо decision maker змінився, key account може перейти в зону ризику.

== Decision maker і воронка продажів ==

У [[Воронка продажів|воронці продажів]] контакт із decision maker часто впливає на просування угоди.

Наприклад:

{| class="wikitable" style="width:100%;"
! Етап воронки
! Роль decision maker
|-
| Кваліфікація
| Підтверджує, що проблема важлива для бізнесу
|-
| Демонстрація
| Оцінює цінність і стратегічну користь
|-
| Комерційна пропозиція
| Порівнює вартість, результат і ризики
|-
| Переговори
| Узгоджує умови
|-
| Договір
| Затверджує або передає на погодження
|-
| Рахунок
| Погоджує оплату або бюджет
|-
| Повторний продаж
| Затверджує розвиток співпраці
|}

Якщо decision maker не залучений, угода може зависнути після презентації або комерційної пропозиції.

== Decision maker і задачі менеджерів ==

[[Задачі менеджерів]] мають враховувати decision maker.

Приклади задач:

* визначити decision maker;
* отримати контакт decision maker;
* призначити зустріч із decision maker;
* підготувати презентацію для керівництва;
* уточнити критерії рішення;
* зібрати заперечення decision maker;
* надіслати коротке резюме для затвердження;
* підготувати фінансове обґрунтування;
* провести follow-up після зустрічі;
* зафіксувати рішення.

У CRM задача має бути прив’язана до конкретної контактної особи.

== Decision maker і історія комунікацій ==

[[Історія комунікацій]] має показувати, чи була взаємодія з decision maker.

Потрібно фіксувати:

* дзвінки;
* email;
* зустрічі;
* презентації;
* заперечення;
* критерії вибору;
* погодження;
* рішення;
* причини паузи;
* причини відмови;
* домовленості;
* наступні дії.

Якщо вся історія є тільки з ініціатором, але decision maker не залучений, ризик угоди вищий.

== Decision maker і договори ==

[[Договори в CRM]] часто проходять через decision maker або підписанта.

Потрібно розуміти:

* хто погоджує договір;
* хто підписує;
* хто може змінити умови;
* хто погоджує бюджет;
* хто затверджує оплату;
* хто відповідає за ризики;
* хто може прискорити процес;
* хто може заблокувати договір.

У B2B decision maker і юридичний контакт можуть бути різними людьми.

== Decision maker і контроль оплат ==

[[Контроль оплат]] може залежати від decision maker, фінансового директора або бухгалтера.

Потрібно знати:

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

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

== Decision maker і Customer Success ==

[[Customer Success]] має працювати не лише з користувачами, а й з decision maker.

Причини:

* decision maker оцінює бізнес-результат;
* він може продовжити або не продовжити договір;
* він може затвердити розширення;
* він може ініціювати зміну постачальника;
* він може впливати на бюджет;
* він може оцінювати ROI.

Для Customer Success важливо регулярно показувати decision maker цінність, яку клієнт отримує від продукту або послуги.

== Decision maker і NPS ==

[[NPS]] може відрізнятися залежно від ролі контактної особи.

Наприклад:

* користувач може бути задоволений зручністю;
* директор може не бачити фінансового ефекту;
* IT може мати претензії до інтеграцій;
* бухгалтерія може бути незадоволена документами;
* Customer Success може бачити ризик, який decision maker ще не озвучив.

Тому важливо знати, хто саме дав NPS-оцінку: decision maker, користувач, фінансовий контакт чи інша роль.

== Decision maker і повторні продажі ==

[[Повторні продажі]] часто потребують нового погодження decision maker.

Наприклад:

* новий модуль;
* додаткові користувачі;
* сервісний контракт;
* інтеграція;
* навчання;
* Power BI-аналітика;
* AI-функціональність;
* продовження договору;
* перехід на більший тариф;
* автоматизація нового підрозділу.

Для повторного продажу потрібно не тільки знайти потребу, а й показати decision maker бізнес-цінність.

== Decision maker і Key Account Management ==

У [[Key Account Management]] decision maker є одним із ключових контактів.

Для key account потрібно:

* знати decision maker;
* підтримувати регулярний контакт;
* розуміти його цілі;
* знати критерії рішення;
* мати sponsor всередині клієнта;
* вести карту контактів;
* оновлювати account plan;
* контролювати ризики;
* планувати зустрічі на рівні керівництва.

Key Account Manager має працювати не лише з операційними контактами, а й зі стратегічними особами.

== Decision maker і сегментація ==

[[Сегмент клієнта|Сегментація]] може враховувати наявність decision maker.

Приклади сегментів:

* B2B-клієнти з визначеним decision maker;
* B2B-клієнти без decision maker;
* key accounts без контакту з decision maker;
* угоди без доступу до decision maker;
* клієнти, де decision maker змінився;
* клієнти з активним sponsor;
* клієнти з фінансовим decision maker;
* клієнти з кількома decision makers.

Такі сегменти допомагають керівнику бачити ризики у воронці продажів.

== Decision maker і аудит клієнтської бази ==

Під час [[Аудит клієнтської бази|аудиту клієнтської бази]] потрібно перевіряти наявність decision maker.

Питання для аудиту:

* чи є decision maker у B2B-клієнтів;
* чи є decision maker у key accounts;
* чи актуальна ця контактна особа;
* чи вказана її посада;
* чи є телефон або email;
* чи була комунікація з decision maker;
* чи є задачі по decision maker;
* чи не змінився decision maker;
* чи не ведеться угода тільки через користувача;
* чи є карта контактів.

Відсутність decision maker у великих угодах — серйозний ризик.

== Decision maker і AI в CRM ==

[[AI в CRM]] може допомагати аналізувати ролі контактних осіб.

AI може:

* визначати ймовірного decision maker за посадою;
* підказувати, що в угоді немає decision maker;
* підсумовувати історію комунікацій із decision maker;
* пропонувати наступну дію;
* виявляти ризик угоди без доступу до decision maker;
* аналізувати заперечення;
* готувати персональний лист;
* допомагати створювати executive summary;
* знаходити зміну контактних осіб.

AI може допомагати, але остаточну роль контакту має підтверджувати менеджер.

== Decision maker і Power BI ==

[[Power BI CRM]] може показувати аналітику по decision makers.

Можливі показники:

* кількість B2B-клієнтів із визначеним decision maker;
* кількість угод без decision maker;
* сума воронки без доступу до decision maker;
* key accounts без decision maker;
* угоди, де decision maker не контактував понад 30 днів;
* конверсія угод із decision maker і без нього;
* середній цикл продажу при наявності decision maker;
* кількість контактів із роллю decision maker;
* ризикові клієнти після зміни decision maker.

== Decision maker і відкриті API ==

[[Відкриті API]] можуть передавати інформацію про контактні особи й ролі між системами.

Приклади:

* сайт створює контакт у CRM;
* CRM зберігає роль decision maker;
* ERP отримує підписанта для договору;
* Power BI аналізує угоди без decision maker;
* AI аналізує історію контактів;
* email-сервіс надсилає персональні матеріали керівникам;
* сервіс-деск передає інформацію Customer Success;
* клієнтський портал оновлює контактні дані.

API допомагає не втрачати роль decision maker між CRM, ERP та іншими системами.

== Приклад карти прийняття рішення ==

{| class="wikitable" style="width:100%;"
! Контакт
! Роль
! Вплив
! Інтерес
! Наступна дія
|-
| Директор
| Decision maker
| Високий
| Бізнес-результат, контроль, ROI
| Провести зустріч на рівні керівництва
|-
| Фінансовий директор
| Economic buyer
| Високий
| Бюджет, умови оплати, окупність
| Надіслати фінансове обґрунтування
|-
| Керівник продажів
| Ініціатор / Sponsor
| Високий
| CRM, задачі, воронка продажів
| Узгодити детальні потреби
|-
| IT-директор
| Technical approver
| Середній / високий
| API, безпека, інтеграції
| Провести технічну консультацію
|-
| Юрист
| Legal approver
| Середній
| Договір, ризики, відповідальність
| Надіслати договір на погодження
|-
| Менеджери
| Користувачі
| Середній
| Зручність, швидкість, щоденна робота
| Провести демонстрацію функцій
|}

== Приклад процесу роботи з decision maker ==

{| class="wikitable" style="width:100%;"
! Крок
! Дія
! Результат
|-
| 1
| Менеджер отримує лід
| Є первинний контакт
|-
| 2
| Проводиться кваліфікація
| Визначено потребу й компанію
|-
| 3
| Уточнюється процес прийняття рішення
| Відомо, хто впливає на вибір
|-
| 4
| У CRM створюється карта контактів
| Зафіксовані ролі
|-
| 5
| Визначається decision maker
| Зрозуміло, хто затверджує рішення
|-
| 6
| Створюється задача на контакт із decision maker
| Є наступна дія
|-
| 7
| Проводиться зустріч або презентація
| Decision maker розуміє цінність
|-
| 8
| Фіксуються критерії рішення
| Угода стає керованішою
|-
| 9
| Погоджується договір і бюджет
| Угода переходить до фінального етапу
|-
| 10
| Після продажу decision maker залучається до Customer Success
| Підтримується довгострокова цінність
|}

== KPI роботи з decision maker ==

Основні KPI:

* частка B2B-клієнтів із визначеним decision maker;
* частка key accounts із актуальним decision maker;
* кількість угод без decision maker;
* сума воронки без доступу до decision maker;
* конверсія угод із decision maker;
* середній цикл продажу при залученні decision maker;
* кількість задач по decision maker;
* кількість зустрічей із decision maker;
* кількість клієнтів зі зміненим decision maker;
* кількість key accounts без контакту з decision maker понад 30/60/90 днів;
* кількість програних угод через відсутність доступу до decision maker.

== Типові помилки ==

Типові помилки в роботі з особами, що приймають рішення:

* вважати першого контакта decision maker;
* не питати про процес прийняття рішення;
* не фіксувати ролі контактних осіб;
* не мати доступу до decision maker;
* вести угоду тільки через користувача;
* не готувати окрему цінність для керівництва;
* не враховувати фінансового decision maker;
* не залучати технічного або юридичного approver;
* не оновлювати decision maker після зміни посад;
* не фіксувати заперечення decision maker;
* не створювати задачі на контакт із decision maker;
* не аналізувати угоди без decision maker у звітах.

== Хороші практики ==

Для якісної роботи з decision maker бажано:

* визначати процес прийняття рішення на етапі кваліфікації;
* фіксувати ролі контактів у CRM;
* створювати карту контактів;
* не плутати ініціатора, користувача й decision maker;
* готувати аргументи для кожної ролі;
* мати окрему задачу на контакт із decision maker;
* фіксувати критерії рішення;
* вести історію комунікацій;
* контролювати зміну контактних осіб;
* залучати керівництво до key accounts;
* аналізувати угоди без decision maker;
* використовувати Power BI та AI-підказки.

== Коротко ==

{| class="wikitable" style="width:100%;"
! Питання
! Відповідь
|-
| Хто така особа, що приймає рішення?
| Це контактна особа клієнта, яка має повноваження затвердити або заблокувати покупку, бюджет, договір, постачальника чи продовження співпраці.
|-
| Чим decision maker відрізняється від контактної особи?
| Контактна особа — будь-який представник клієнта, а decision maker — той, хто реально впливає на фінальне рішення.
|-
| Чи завжди decision maker — директор?
| Ні. Це може бути власник, директор, фінансовий директор, керівник підрозділу, закупівельний комітет або інша уповноважена особа.
|-
| Чому це важливо для CRM?
| CRM має показувати, чи є в угоді доступ до людини, яка приймає рішення, і які задачі потрібні для просування продажу.
|-
| Як це важливо для B2B?
| У B2B рішення часто приймає група людей, тому потрібно вести карту контактів, ролі та вплив кожного учасника.
|-
| Як K2 ERP може підтримувати decision maker?
| У [[K2 ERP]] decision maker може бути пов’язаний із карткою клієнта, контактами, угодами, задачами, договорами, оплатами, Customer Success, BI та AI.
|-
| Яка головна помилка?
| Вважати ініціатора або користувача особою, що приймає рішення, не перевіривши реальний процес погодження.
|}

== Переваги правильної роботи з decision maker ==

Основні переваги:

* вища конверсія B2B-продажів;
* коротший цикл погодження;
* менше угод, що зависають;
* кращий контроль бюджету;
* точніші комерційні пропозиції;
* краща робота з запереченнями;
* менше ризику програшу конкуренту;
* кращий Customer Success;
* більше повторних продажів;
* ефективніший Key Account Management;
* краща управлінська аналітика;
* менша залежність від одного користувача або ініціатора.

== Ризики без визначення decision maker ==

Якщо decision maker не визначений, виникають ризики:

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

<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Ризик без decision maker.''' Якщо в CRM немає особи, що приймає рішення, менеджер може мати активну комунікацію, але не мати реального впливу на фінальне рішення клієнта.
</div>

== Висновок ==

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

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

У [[CRM]] decision maker допомагає керувати угодами, задачами, комунікаціями й воронкою продажів. В [[ERP]] ця роль може бути пов’язана з договорами, рахунками, оплатами й погодженнями. У [[K2 ERP]] особа, що приймає рішення, може бути частиною єдиної карти контактів клієнта разом із CRM, ERP, Customer Success, Key Account Management, Power BI, AI та відкритими API.

'''Особа, що приймає рішення, — це не просто контакт у CRM. Це один із головних факторів успішного продажу, продовження договору та розвитку клієнта.'''

== Див. також ==

* [[Контактна особа]]
* [[Картка клієнта]]
* [[Клієнт]]
* [[B2B-клієнт]]
* [[Ключовий клієнт]]
* [[Клієнтська база]]
* [[Клієнтський шлях]]
* [[Сегмент клієнта]]
* [[Аудит клієнтської бази]]
* [[CRM]]
* [[CRM система]]
* [[CRM для бізнесу]]
* [[CRM-модуль]]
* [[ERP]]
* [[K2 ERP]]
* [[Ліди]]
* [[Воронка продажів]]
* [[Історія комунікацій]]
* [[Задачі менеджерів]]
* [[Договори в CRM]]
* [[Контроль оплат]]
* [[Повторні продажі]]
* [[Email-розсилки в CRM]]
* [[Дублі клієнтів]]
* [[Неякісні дані CRM]]
* [[NPS]]
* [[Customer Success]]
* [[Key Account Management]]
* [[Омніканальна CRM]]
* [[AI в CRM]]
* [[Power BI CRM]]
* [[Відкриті API]]
* [[Цифровий суверенітет]]
* [[Автоматизація продажів]]
* [[Цифровізація бізнесу]]