Атестаційні завдання K2 ERP/CRM: відмінності між версіями

Поточна версія на 18:22, 1 травня 2026

Атестаційне завдання K2 ERP — CRM — це практична задача для перевірки навичок розробника або впроваджувача K2 ERP у створенні CRM-модуля для управління лідами, клієнтами, угодами, комунікаціями, воронкою продажів та аналітикою ефективності менеджерів.

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

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

Назва завдання

Модуль CRM: управління лідами, клієнтами, угодами і комунікаціями.

Мета завдання

Мета завдання — створити в K2 ERP CRM-модуль, який автоматизує роботу відділу продажів.

Система повинна дозволяти:

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

Головний принцип. CRM — це не просто довідник контактів. Це система керування продажем: лід → комунікація → кваліфікація → угода → клієнт → результат → аналітика.

Реальний бізнес-контекст

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

Потенційні клієнти приходять із різних каналів: сайту, реклами, рекомендацій, холодних дзвінків, заходів, партнерів або повторних звернень.

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

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

Основний бізнес-процес

Типовий процес роботи CRM-модуля виглядає так:

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

Основні об’єкти модуля

Об’єкт	Призначення
Статуси лідів	Етапи проходження потенційного клієнта через воронку продажів
Джерела лідів	Канали, з яких приходять потенційні клієнти
Ліди	Потенційні клієнти, з якими ще ведеться первинна робота
Клієнти	Компанії або фізичні особи, які стали клієнтами
Угоди	Комерційні можливості, замовлення або продажі
Комунікації	Дзвінки, листи, зустрічі, коментарі та інші події
Заплановані події	Майбутні дзвінки, зустрічі, задачі та нагадування
Менеджери	Користувачі системи, відповідальні за ліди та угоди
Воронка продажів	Візуалізація етапів продажу, конверсій і втрат
Звіти	Аналітика лідів, угод, джерел і менеджерів

Довідник «Статуси лідів»

Довідник статусів лідів описує етапи проходження потенційного клієнта через воронку продажів.

Приклад послідовності статусів:

Статус	Значення
Новий	Лід щойно створений і ще не оброблений
Уточнюється	Менеджер перевіряє потребу, контакти або деталі запиту
Презентація	Клієнту проведено презентацію продукту або послуги
Комерційна пропозиція	Клієнту підготовлено або надіслано пропозицію
Угода	Лід переходить у роботу як потенційна угода
Успіх	Лід успішно конвертовано в клієнта або продаж
Втрата	Лід втрачено

Статуси повинні мати порядок проходження, щоб система могла будувати воронку продажів і рахувати конверсії між етапами.

Довідник «Джерела лідів»

Довідник джерел лідів описує, звідки прийшов потенційний клієнт.

Приклади джерел:

вебсайт;
рекомендації;
реклама;
холодний дзвінок;
захід;
партнер;
повторне звернення;
соціальні мережі;
email-розсилка.

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

Журнал «Ліди»

Журнал лідів повинен відображати потенційних клієнтів і поточний стан роботи з ними.

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

Колонки журналу лідів

Колонка	Опис
ПІБ або назва компанії	Ім’я потенційного клієнта або назва компанії
Джерело ліда	Канал, з якого прийшов лід
Дата створення	Коли лід був доданий у систему
Відповідальний менеджер	Хто веде ліда
Поточний статус	На якому етапі перебуває лід
Ймовірність успіху, %	Оцінка шансів на успішну угоду
Очікувана сума угоди	Потенційна сума продажу
Наступна дія	Запланований дзвінок, зустріч або інша дія

Функціональність журналу лідів

Журнал лідів має підтримувати:

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

Форма створення ліда

Форма створення ліда повинна бути простою, але достатньою для старту продажу.

Основна інформація ліда

У формі потрібно передбачити:

Поле	Опис
ПІБ або назва компанії	Ім’я потенційного клієнта або назва організації
Телефон	Основний контактний номер
Email	Email потенційного клієнта
Джерело ліда	Вибір із довідника через AJAX
Статус	Поточний статус у воронці
Примітки	Додаткова інформація
Відповідальний менеджер	Вибір зі списку користувачів
Очікувана сума	Орієнтовна сума майбутньої угоди
Ймовірність успіху	Оцінка шансів на успішний продаж

Історія дій по ліду

У картці ліда потрібно відображати історію дій.

До історії можуть входити:

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

Важливо. Лід без історії комунікацій швидко перетворюється на “мертвий контакт”. CRM має показувати, що саме робив менеджер і який наступний крок заплановано.

Конвертація ліда у клієнта та угоду

Потрібно передбачити конвертацію ліда у клієнта разом з угодою.

Після конвертації система повинна:

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

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

Журнал «Клієнти»

Журнал клієнтів містить усі компанії або фізичних осіб, які стали клієнтами.

Колонки журналу клієнтів

Колонка	Опис
Назва компанії або особи	Клієнт
Телефон	Контактний номер
Email	Email клієнта
Дата першого контакту	Коли клієнт уперше звернувся
Менеджер	Відповідальний менеджер
Поточний статус взаємодії	Активний, сплячий, втрачений, VIP або інший статус

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

Журнал «Угоди»

Журнал угод відображає комерційні можливості та замовлення.

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

Колонки журналу угод

Колонка	Опис
Назва угоди	Назва комерційної можливості або продажу
Клієнт	Клієнт, з яким пов’язана угода
Стадія продажу	Поточний етап у воронці
Вартість угоди	Очікувана або фактична сума
Ймовірність успіху, %	Оцінка шансів на успішне закриття
Менеджер	Відповідальний за угоду
Дата відкриття	Коли угоду створено
Дата закриття	Коли угоду закрито або планується закрити
Статус	В роботі, успішно закрито, програно

Функціональність журналу угод

Журнал угод має підтримувати:

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

Статуси угод

Статус	Значення
В роботі	Угода активна, менеджер продовжує роботу
Успішно закрито	Угода завершилася продажем
Програно	Угода втрачена

Журнал «Комунікації»

Журнал комунікацій зберігає історію контактів із лідами та клієнтами.

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

Типи подій

Тип події	Приклад
Дзвінок вхідний	Клієнт сам зателефонував у компанію
Дзвінок вихідний	Менеджер зателефонував клієнту
Email	Надіслано або отримано лист
Зустріч	Проведено онлайн або офлайн-зустріч
Коментар	Внутрішня примітка менеджера
Задача	Запланована дія по клієнту

Колонки журналу комунікацій

Колонка	Опис
Клієнт або лід	До кого прив’язана подія
Тип події	Дзвінок, email, зустріч, коментар тощо
Дата	Дата й час події
Опис	Суть комунікації
Відповідальний	Хто виконав або запланував дію
Результат	Підсумок комунікації

Функціональність журналу комунікацій

Потрібно реалізувати:

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

Воронка продажів

Воронка продажів повинна візуально показувати проходження лідів та угод по етапах.

Воронку можна реалізувати через просту діаграму, наприклад з використанням Chart.js.

Графік воронки

На графіку потрібно показати:

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

Аналітичний сенс воронки

Воронка має відповідати на питання:

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

Звіт «Ліди за період»

Звіт має показувати роботу з лідами за вибраний період.

У звіті потрібно відображати:

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

Звіт «Ефективність менеджерів»

Звіт має показувати результативність роботи менеджерів.

У звіті потрібно відображати:

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

Нагадування та нотифікації

Модуль повинен підтримувати автоматичні нагадування менеджерам про заплановані події.

Типові нагадування:

запланований дзвінок;
зустріч;
повторний контакт;
відправка комерційної пропозиції;
контроль відповіді клієнта.

Також потрібно реалізувати нотифікації при переході ліда у стадію «Угода».

Нотифікації можуть бути реалізовані через email, внутрішні сповіщення або WebSocket.

AJAX-інтерактив

Модуль повинен підтримувати виконання ключових операцій через AJAX.

Через AJAX мають працювати:

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

Статус ліда має оновлюватися без повного перезавантаження сторінки.

Експорт даних

Потрібно передбачити можливість експорту списків у Excel або PDF.

Експортувати можна:

ліди;
клієнтів;
угоди;
комунікації;
звіти;
воронку продажів.

Логування змін

Потрібно фіксувати важливі зміни в CRM.

Журнал змін має зберігати:

хто створив ліда;
хто змінив статус;
хто змінив менеджера;
хто конвертував ліда;
хто створив угоду;
хто закрив угоду;
дату й час зміни;
старе та нове значення.

Технічні вимоги

Параметр	Опис
Бекенд	K2 ERP на Python або PHP
База даних	PostgreSQL або MySQL
Фронтенд	HTML5, JavaScript
AJAX	Axios або Fetch API
UI-компоненти	DataTables, Select2, Chart.js
Нотифікації	Email або внутрішні сповіщення через WebSocket, опціонально
Друк / експорт	Експорт списків в Excel або PDF

Практичне завдання

У межах атестації потрібно продемонструвати робочий сценарій.

Мінімальний сценарій:

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

Критерії оцінювання

Критерій	Бали	Що перевіряється
Реалізація журналів лідів, угод і клієнтів	20	Списки, пошук, фільтри, статуси, менеджери, джерела, стадії
Конверсія ліда у клієнта та угоду	20	Створення клієнта й угоди, збереження історії, відсутність дублів
Управління комунікаціями	20	Дзвінки, email, зустрічі, коментарі, прив’язка до лідів, клієнтів і угод
Воронка продажів і аналітика	20	Графік воронки, конверсії, втрати, звіти по лідах і менеджерах
Інтерактивність через AJAX	10	Створення, оновлення статусів, додавання подій і комунікацій без перезавантаження
Якість структури коду і БД	10	Логічна модель даних, підтримуваність, журнал змін, коректні зв’язки
Разом	100	Максимальна оцінка

Шкала оцінювання

Бали	Рівень	Опис
90–100	Відмінно	CRM-модуль повністю працює: ліди, клієнти, угоди, комунікації, воронка, звіти, AJAX і нотифікації реалізовані коректно
75–89	Добре	Основна логіка працює, є незначні недоліки, які не руйнують бізнес-процес продажів
60–74	Зараховано	Базовий сценарій працює, але частина функцій реалізована неповно або потребує доопрацювання
0–59	Не зараховано	Відсутня критична логіка: ліди, конверсія, угоди, комунікації, воронка або звіти

Критичні помилки

Критичними помилками вважаються ситуації, коли:

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

Умова складання. Завдання не може бути зараховане, якщо система не дозволяє пройти базовий цикл продажу: створення ліда → комунікація → зміна статусу → конвертація в клієнта та угоду → закриття угоди → звіт.

Очікуваний результат

У результаті виконання атестаційного завдання має бути створений CRM-модуль K2 ERP.

Модуль має підтримувати довідники статусів і джерел лідів, журнали лідів, клієнтів, угод і комунікацій, конверсію ліда у клієнта та угоду, воронку продажів, звітність, AJAX-інтерактив, нагадування, нотифікації, експорт і журнал змін.

Примітка

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

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

Коротко

Питання	Відповідь
Що потрібно створити?	CRM-модуль для управління лідами, клієнтами, угодами й комунікаціями
Які довідники потрібні?	Статуси лідів і джерела лідів
Які журнали потрібні?	Ліди, клієнти, угоди, комунікації
Що є ключовою дією?	Конвертація ліда у клієнта та угоду
Що має зберігатися?	Історія комунікацій, статуси, відповідальні, джерела, угоди й журнал змін
Яка аналітика потрібна?	Воронка продажів, ліди за період, ефективність менеджерів
Що має працювати через AJAX?	Створення ліда, зміна статусу, додавання комунікацій і подій
Що є критичною вимогою?	Повний цикл продажу від ліда до угоди та звіту

Див. також