Перейти до вмісту

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

Матеріал з K2 ERP Wiki
Перенос з Гугл док.
 
Немає опису редагування
 
Рядок 1: Рядок 1:
Журнал лідів повинен відображати потенційних клієнтів і поточний стан роботи з ними.==== Графік воронки ====
Приклад послідовності статусів:


== Див. так само ==
! Колонка
 
! ![[Категорія:Корпоративна Wiki]]
 
У результаті виконання атестаційного задача має бути створений CRM-модуль K2 ERP. Разом
 
'''Умова складання.''' задача не здатна бути зараховане, якщо платформа не дає можливість пройти базовий цикл продажу: створення ліда → комунікація → зміна статусу → конвертація в клієнта та угоду → закриття угоди → звіт. Бали
 
{| class="wikitable" style="width:100%;"
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
== Журнал «Угоди» ==
|-
| В роботі
| Угода активна, менеджер продовжує роботу
|-
| Успішно закрито
| Угода завершилася продажем
|-
| Програно
| Угода втрачена
|}
 
Потенційні клієнти приходять із різних каналів: сайту, реклами, рекомендацій, холодних дзвінків, заходів, партнерів або повторних звернень.== Звіт «Ефективність менеджерів» ==
 
{| class="wikitable" style="width:100%;"
Через AJAX мають працювати:
{| class="wikitable" style="width:100%;"
|-
| Назва угоди
| Назва комерційної функції ERP або продажу
|-
| клієнт ERP
| клієнт ERP, з яким пов’язана угода
|-
| Стадія продажу
| Поточний етап у воронці
|-
| Вартість угоди
| Очікувана або фактична сума
|-
| Ймовірність успіху, %
| Оцінка шансів на успішне закриття
|-
| Менеджер
| Відповідальний за угоду
|-
| Дата відкриття
| Коли угоду створено
|-
| Дата закриття
| Коли угоду закрито або планується закрити
|-
| Статус
| В роботі, успішно закрито, програно
|}
 
[[Категорія:Ліди]]
 
компонент повинен підтримувати виконання ключових операцій через AJAX. так само потрібно реалізувати нотифікації при переході ліда у стадію '''«Угода»'''. !== Шкала оцінювання ==
|-
| ПІБ або назва компанії
| Ім’я потенційного клієнта або назва організації
|-
| Телефон
| базовий контактний номер
|-
| Email
| Email потенційного клієнта
|-
| Джерело ліда
| Вибір із довідника через AJAX
|-
| Статус
| Поточний статус у воронці
|-
| Примітки
| Додаткова інформаційні матеріали
|-
| Відповідальний менеджер
| Вибір зі списку користувачів
|-
| Очікувана сума
| Орієнтовна сума майбутньої угоди
|-
| Ймовірність успіху
| Оцінка шансів на успішний продаж
|}
 
! Тип події
 
Для реалізації задачі доцільно передбачити такі сутності:
Мінімальний сценарій:
{| class="wikitable" style="width:100%;"
|-
| Новий
| Лід щойно створений і ще не оброблений
|-
| Уточнюється
| Менеджер перевіряє потребу, контакти або деталі запиту
|-
| Презентація
| Клієнту проведено презентацію продукту або послуги
|-
| Комерційна пропозиція
| Клієнту підготовлено або надіслано пропозицію
|-
| Угода
| Лід переходить у роботу як потенційна угода
|-
| Успіх
| Лід успішно конвертовано в клієнта або продаж
|-
| Втрата
| Лід втрачено
|}


=== 8. формування звітів ===
{| class="wikitable" style="width:100%;"
{| class="wikitable"


Приклади джерел:
На графіку потрібно показати:


* новий;
== Довідник «Джерела лідів» ==
* уточнюється;
* презентація;
* комерційна пропозиція;
* угода;
* успіх;
* втрата. !Бали


== Технічні вимоги ==
== Критерії оцінювання ==


* вебсайт;
* вебсайт;
Рядок 22: Рядок 129:
* реклама;
* реклама;
* холодний дзвінок;
* холодний дзвінок;
* захід. CRM''' — практична задача; так само реалізовано що передбачає створення CRM-модуля для керування лідами. * кількість лідів на менеджера;
* захід;
* кількість успішних угод;
* інтегратор;
* середню суму угоди. Звіт має показувати:
* повторне звернення;
* соціальні мережі;
* email-розсилка.== Звіт «Ліди за період» ==
 
== історія продукту дій по ліду ==
 
== Форма створення ліда ==
 
* запланований дзвінок;
* зустріч;
* повторний контакт;
* відправка комерційної пропозиції;
* контроль відповіді клієнта. Статус
 
'''провідний принцип.''' CRM — це не без зусиль довідник контактів.[[Категорія:Угоди]]
== Воронка продажів ==
! Статус ліда має оновлюватися без повного перезавантаження сторінки. Рівень


* клієнт ERP або лід;
Менеджери повинні бачити, хто звернувся, звідки прийшов лід, на якому етапі він перебуває, які комунікації вже були, яка очікувана сума угоди, хто відповідальний і що потрібно зробити далі. ! Журнал змін має зберігати:
* тип події;
Журнал лідів має підтримувати:
* дата;
Нотифікації можуть бути реалізовані через email, внутрішні сповіщення або WebSocket. CRM''' — це практична задача; так само реалізовано клієнтами. Бали
* SEO-опис;
== Практичне задача ==
* відповідальний.==== Довідник «Статуси лідів» ====
== Примітка ==
==== Основна інформаційні матеріали ====
=== 7. Воронка продажів ===
|-
|Бекенд
|K2 ERP на Python або PHP
|-
|БД
|PostgreSQL або MySQL
|-
|-
|Фронтенд
| 90–100
|HTML5, JavaScript, AJAX через Axios або Fetch API
| Відмінно
| CRM-модуль на 100% функціонує: ліди, клієнти, угоди, комунікації, воронка, звіти, AJAX і нотифікації реалізовані коректно
|-
|-
|UI-компоненти
| 75–89
|DataTables, Select2, Chart.js
| Добре
| Основна логіка функціонує, виступає як незначні недоліки, які не руйнують бізнес-процес продажів
|-
|-
|Нотифікації
| 60–74
|Email або внутрішні сповіщення через WebSocket, опціонально
| Зараховано
| Базовий сценарій функціонує, але частина функцій реалізована неповно або потребує доопрацювання
|-
|-
|Друк
| 0–59
|Можливість експорту списків в Excel або PDF
| Не зараховано
| Відсутня критична логіка: ліди, конверсія, угоди, комунікації, воронка або звіти
|}
|}


==== Функціональність журналу комунікацій ====
! CRM-модуль має допомогти не втрачати ліди, контролювати роботу менеджерів, бачити реальну воронку продажів і розуміти, які джерела та менеджери приносять найбільше результату. ! 100
компанія-користувач займається активними продажами своїх послуг і товарів.==== Звіт «Ліди за період» ====
 
__TOC__
 
* первинний дзвінок;
* презентація;
* комерційна пропозиція;
* email;
* зустріч;
* коментар менеджера;
* зміна статусу;
* запланована подія;
* результат комунікації. ! Джерело ліда потрібно використовувати у звітах, щоб бачити, які канали дають найбільше лідів, клієнтів і успішних угод. Менеджер має оперативно бачити, хто звернувся, з якого джерела, хто відповідальний, яка ймовірність успіху та на яку суму очікується угода.== базовий бізнес-процес ==
{| class="wikitable" style="width:100%;"
! Потрібно передбачити можливість експорту списків у Excel або PDF. Колонка
 
! ! Що перевіряється
 
платформа повинна дозволяти:
 
Потрібно реалізувати:
Потрібно реалізувати:


==== Функціональність журналу ====
{| class="wikitable" style="width:100%;"
!100


==== Колонки журналу ====
* створити клієнта на основі даних ліда;
* створити угоду, пов’язану з клієнтом;
* перенести історію комунікацій;
* зберегти зв’язок між початковим лідом, клієнтом і угодою;
* змінити статус ліда відповідно до логіки процесу;
* не створювати дублікати клієнтів, якщо клієнт ERP уже існує. !== Функціональність журналу комунікацій ==
== Журнал «Комунікації» ==
|-
| клієнт ERP або лід
| До кого прив’язана подія
|-
| Тип події
| Дзвінок, email, зустріч, коментар тощо
|-
| Дата
| Дата й час події
|-
| SEO-опис
| Суть комунікації
|-
| Відповідальний
| Хто виконав або запланував дію
|-
| Результат
| Підсумок комунікації
|}


* збору лідів — потенційних клієнтів;
== Технічні вимоги ==
* переведення лідів у клієнтів;
* керування угодами, комерційними пропозиціями та замовленнями;
* ведення історії контактів: дзвінків, листів, зустрічей;
* побудови воронки продажів;
* аналітики ефективності менеджерів.=== 1. Структура довідників ===
==== Типи подій ====


* зв’язування угод із клієнтами;
Після конвертації платформа повинна:
* зв’язування угод з історією комунікацій;
* відображення стадії воронки продажів.== Очікуваний результат ==
Окремо варто відзначити клієнтами, угодами, комунікаціями, воронкою продажів і аналітикою ефективності менеджерів виступає ключовою рисою розробника K2 ERP забезпечується через '''Атестаційне задача K2 ERP.=== 3. Форма створення ліда ===
==== Довідник «Джерела лідів» ====


* додавання події вручну;
* додавання події вручну;
* прив’язку події до ліда;
* прив’язку події до ліда;
* прив’язку події до клієнта. У результаті виконання атестаційного задача має бути створений CRM-модуль K2 ERP, який підтримує довідники статусів і джерел лідів, журнали лідів, клієнтів, угод і комунікацій, конверсію ліда у клієнта та угоду, воронку продажів, формування звітів, AJAX-інтерактив і нотифікації. |}
* прив’язку події до клієнта;
* прив’язку події до угоди;
* планування майбутніх подій;
* нагадування менеджеру;
* перегляд історії з картки ліда, клієнта або угоди.== Типи подій ==
 
! !== Основні об’єкти модуля ==
Воронка має відповідати на питання:
|-
| Назва компанії або особи
| клієнт ERP
|-
| Телефон
| Контактний номер
|-
| Email
| Email клієнта
|-
| Дата першого контакту
| Коли клієнт ERP уперше звернувся
|-
| Менеджер
| Відповідальний менеджер
|-
| Поточний статус взаємодії
| Активний, сплячий, втрачений, VIP або інший статус
|}
 
{| class="wikitable" style="width:100%;"
 
! * ліди;
* клієнтів;
* угоди;
* комунікації;
* звіти;
* воронку продажів.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
== Функціональність журналу лідів ==
== Очікуваний результат ==
|-
| Що потрібно створити? # створити джерела лідів;
# створити статуси лідів;
# створити нового ліда;
# вказати телефон, email, джерело та відповідального менеджера;
# додати першу комунікацію;
# змінити статус ліда через AJAX;
# запланувати майбутній дзвінок або зустріч;
# показати нагадування менеджеру;
# перевести ліда у стадію '''«Угода»''';
# виконати конвертацію ліда у клієнта та угоду;
# перевірити, що історія продукту комунікацій не втрачена;
# змінити стадію угоди;
# закрити угоду як успішну або програну;
# сформувати воронку продажів;
# сформувати звіт лідів за період;
# сформувати звіт ефективності менеджерів;
# експортувати список або звіт;
# показати журнал змін. {| class="wikitable" style="width:100%;"
 
У картці ліда потрібно відображати історію дій. SEO-опис
 
[[Категорія:Воронка продажів]]
 
Статуси повинні мати порядок проходження, щоб платформа могла будувати воронку продажів і рахувати конверсії між етапами. Питання
 
== Рекомендовані сутності бази даних ==
 
* створення ліда;
* оновлення версій статусу ліда;
* додавання комунікацій;
* зміна відповідального менеджера;
* конвертація ліда;
* створення угоди;
* оновлення версій стадії угоди;
* додавання запланованої події. Критерій
 
клієнт ERP повинен бути пов’язаний з угодами, комунікаціями, файлами, документами та історією продажів.== Колонки журналу комунікацій ==


Журнал лідів має підтримувати:
! Об’єкт
==== Важливий функції ERP ====
 
</div>
 
{| class="wikitable" style="width:100%;"
 
== Назва задача ==
 
У формі потрібно передбачити:
 
!<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
 
Журнал угод має підтримувати:
 
* скільки нових лідів з’явилося;
* скільки лідів дійшло до презентації;
* скільки отримало комерційну пропозицію;
* скільки стало угодами;
* скільки завершилося успішно;
* на якому етапі найбільше втрат;
* який менеджер має кращу конверсію. Це платформа керування продажем: лід → комунікація → кваліфікація → угода → клієнт ERP → результат → аналітичні інструменти. Колонка
 
Довідник джерел лідів описує, звідки прийшов потенційний клієнт ERP. |-
| Дзвінок вхідний
| клієнт ERP сам зателефонував у компанію
|-
| Дзвінок вихідний
| Менеджер зателефонував клієнту
|-
| Email
| Надіслано або отримано лист
|-
| Зустріч
| Проведено онлайн або офлайн-зустріч
|-
| Коментар
| Внутрішня примітка менеджера
|-
| Задача
| Запланована дія по клієнту
|}
 
== Див. так само ==
 
Звіт має показувати роботу з лідами за вибраний період. SEO-опис
|-
| Бекенд
| K2 ERP на Python або PHP
|-
| База даних
| PostgreSQL або MySQL
|-
| Фронтенд
| HTML5, JavaScript
|-
| AJAX
| Axios або Fetch API
|-
| UI-компоненти
| DataTables, Select2, Chart.js
|-
| Нотифікації
| Email або внутрішні сповіщення через WebSocket, опціонально
|-
| Друк / експорт
| Експорт списків в Excel або PDF
|}


=== 5. Журнал «Угоди» ===
== Нагадування та нотифікації ==
=== 6. Журнал «Комунікації» ===


{| class="wikitable"
== Мета задача ==


* статуси лідів;
* статуси лідів;
Рядок 100: Рядок 388:
* нотифікації;
* нотифікації;
* журнал змін;
* журнал змін;
* файли експорту. !Критерій
* файли експорту. Параметр


Такий компонент виступає як серцем будь-якої сучасної компанії, яка будує продажі та реалізація: IT-аутсорсингу, виробників обладнання, логістичних компаній, фінансових послуг і страхування. Воронка продажів повинна візуально показувати проходження лідів та угод по етапах.== Рекомендовані сутності бази даних ==
Окремо варто відзначити угодами, комунікаціями, воронкою продажів і аналітикою ефективності менеджерів виступає ключовою рисою перевірки навичок розробника або впроваджувача [[K2 ERP]] у створенні CRM-модуля для керування лідами забезпечується через '''Атестаційне задача K2 ERP. | CRM-модуль для керування лідами, клієнтами, угодами й комунікаціями
==== Колонки журналу ====
|-
| Які довідники потрібні? Типовий бізнес-процес роботи CRM-модуля виглядає так:


!Разом
CRM-модуль виступає як ключовим для компаній, які активно працюють із продажами: IT-аутсорсингу, виробників обладнання, логістичних компаній, фінансових послуг, страхування, сервісних компаній, B2B-продажів і консалтингу. * зв’язування угод із клієнтами;
Довідник статусів лідів описує етапи проходження потенційного клієнта через воронку продажів. компонент повинен підтримувати:
* зв’язування угод з історією комунікацій;
== Критерії оцінки ==
* відображення стадії воронки продажів;
 
* фільтрацію по менеджеру;
* конвертацію ліда у клієнта разом з угодою;
* фільтрацію по статусу;
* відображення історії дій:
* фільтрацію по періоду;
** первинний дзвінок;
* підрахунок очікуваної суми угод;
** презентація;
* підрахунок успішно закритих угод.</div>
** інші комунікації. Довідник джерел лідів описує, звідки прийшов потенційний клієнт ERP. Потрібно цифровізувати бізнес-процес:
! |-
| Статуси лідів
| Етапи проходження потенційного клієнта через воронку продажів
|-
| Джерела лідів
| Канали, з яких приходять потенційні клієнти
|-
| Ліди
| Потенційні клієнти, з якими ще ведеться первинна робота
|-
|-
|Реалізація журналів лідів, угод і клієнтів
| Клієнти
|20
| Компанії або фізичні особи, які стали клієнтами
|-
|-
|Конверсія ліда у клієнта та угоду
| Угоди
|20
| Комерційні функції ERP, замовлення або продажі та реалізація
|-
|-
|керування комунікаціями
| Комунікації
|20
| Дзвінки, листи, зустрічі, коментарі та інші події
|-
|-
|Воронка продажів і аналітичні інструменти
| Заплановані події
|20
| Майбутні дзвінки, зустрічі, задачі та нагадування
|-
|-
|Інтерактивність через AJAX
| Менеджери
|10
| Користувачі системи, відповідальні за ліди та угоди
|-
|-
|Загальна якість структури коду і БД
| Воронка продажів
|10
| Візуалізація етапів продажу, конверсій і втрат
|-
|-
==== Функціональність журналу угод ====
| Звіти
Журнал комунікацій зберігає історію контактів із лідами та клієнтами. Журнал угод повинен відображати комерційні функції ERP та замовлення. Журнал угод має підтримувати:
| аналітичні інструменти лідів, угод, джерел і менеджерів
'''компонент CRM: керування лідами, клієнтами, угодами і комунікаціями'''. У журналі мають бути такі колонки:
|}
!Параметр


!SEO-опис
[[Категорія:Атестаційні завдання K2]]


* дзвінок:
[[Категорія:Клієнти]]
** вхідний;
** вихідний;
* email;
* зустріч;
* коментар. * ПІБ або назву компанії;
* телефон;
* email;
* джерело ліда з вибором через AJAX;
* примітки;
* відповідального менеджера з вибором зі списку користувачів.==== Колонки журналу ====
Потрібно передбачити:


* ПІБ або назва компанії;
! Відповідь
* джерело ліда;
* дата створення;
* відповідальний менеджер;
* поточний статус;
* ймовірність успіху, %;
* очікувана сума угоди. Приклад послідовності статусів:
На графіку потрібно показати:


* виконання всіх операцій через AJAX:
{| class="wikitable" style="width:100%;"
** створення ліда;
** оновлення версій статусу;
** додавання комунікацій;
* миттєве оновлення версій статусу ліда без перезавантаження сторінки;
* автоматичні нагадування менеджерам про заплановані події:
** зустрічі;
** дзвінки;
* нотифікації при переході ліда у стадію '''«Угода»'''. * пошук по імені;
* пошук по телефону;
* пошук по email;
* фільтрацію за статусами;
* фільтрацію за менеджерами;
* фільтрацію за джерелами.==== Колонки журналу ====
==== Звіт «Ефективність менеджерів» ====


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


* назва угоди;
== Довідник «Статуси лідів» ==
* клієнт ERP;
* стадія продажу;
* вартість угоди;
* ймовірність успіху, %;
* менеджер;
* дата відкриття;
* дата закриття;
* статус:
** в роботі;
** успішно закрито;
** програно. Журнал клієнтів повинен містити всі компанії або фізичних осіб, які стали клієнтами.== Основні задача ==
=== 4. Журнал «Клієнти» ===


Форма створення ліда повинна містити:
компонент має підтримувати довідники статусів і джерел лідів, журнали лідів, клієнтів, угод і комунікацій, конверсію ліда у клієнта та угоду, воронку продажів, формування звітів, AJAX-інтерактив, нагадування, нотифікації, експорт і журнал змін. '''Правильна логіка.''' Конвертація ліда не повинна втрачати історію.== Коротко ==


* назва компанії або особи;
== Логування змін ==
* телефон;
</div>
* email;
'''компонент CRM: керування лідами, клієнтами, угодами і комунікаціями'''. * кількість лідів на кожній стадії;
* дата першого контакту;
* кількість угод на кожній стадії;
* менеджер;
* поточний статус взаємодії. Воронку можна реалізувати через просту діаграму, як приклад з використанням бібліотеки Chart.js. * кількість лідів на кожній стадії;
* конверсії між стадіями;
* конверсії між стадіями;
* втрати на кожному етапі.== Назва ==
* втрати на кожному етапі;
* очікувану суму угод;
* успішно закриті угоди. CRM має показувати, що саме робив менеджер і який наступний крок заплановано. Усі дзвінки, листи, коментарі та події мають залишитися доступними в картці клієнта або угоди. Журнал комунікацій зберігає історію контактів із лідами та клієнтами. Поле
 
== Примітка ==


=== 2. Журнал «Ліди» ===
* неможливо створити ліда;
Звіт має показувати:
* лід не має статусу або відповідального менеджера;
* неможливо конвертувати ліда у клієнта та угоду;
* під час конвертації втрачається історія продукту комунікацій;
* угода не пов’язана з клієнтом;
* комунікації не прив’язуються до ліда, клієнта або угоди;
* неможливо змінити статус ліда;
* воронка продажів не будується;
* звіти не відповідають даним у журналах;
* нотифікації або нагадування не працюють у базовому сценарії;
* немає журналу змін ключових дій. SEO-опис


* кількість нових лідів;
== AJAX-інтерактив ==
* конверсії в клієнтів;
* джерела лідів.== Реальний бізнес-контекст ==


* [[K2 Cloud ERP|K2 ERP]]
Журнал угод відображає комерційні функції ERP та замовлення. ! Потрібно фіксувати важливі зміни в CRM.== Колонки журналу лідів ==
== Реальний бізнес-контекст ==
== Графік воронки ==
Воронку можна реалізувати через просту діаграму, як приклад з використанням Chart.js. |-
| Реалізація журналів лідів, угод і клієнтів
| 20
| Списки, пошук, фільтри, статуси, менеджери, джерела, стадії
|-
| Конверсія ліда у клієнта та угоду
| 20
| Створення клієнта й угоди, збереження історії, відсутність дублів
|-
| керування комунікаціями
| 20
| Дзвінки, email, зустрічі, коментарі, прив’язка до лідів, клієнтів і угод
|-
| Воронка продажів і аналітичні інструменти
| 20
| Графік воронки, конверсії, втрати, звіти по лідах і менеджерах
|-
| Інтерактивність через AJAX
| 10
| Створення, оновлення версій статусів, додавання подій і комунікацій без перезавантаження
|-
| Якість структури коду і БД
| 10
| Логічна модель даних, підтримуваність, журнал змін, коректні зв’язки
|-
== Основна інформаційні матеріали ліда ==
!== Колонки журналу угод ==
! | історія продукту комунікацій, статуси, відповідальні, джерела, угоди й журнал змін
|-
| Яка аналітичні інструменти потрібна? * [[K2 Cloud ERP|K2 ERP]]
* [[K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[CRM]]
* [[CRM]]
Рядок 219: Рядок 513:
* [[Угоди]]
* [[Угоди]]
* [[Воронка продажів]]
* [[Воронка продажів]]
* [[Комунікації]]
* [[Chart.js]]
* [[Chart.js]]
* [[AJAX]]
* [[Ефективність менеджерів]]
== Функціональність журналу угод ==
{{DISPLAYTITLE:Атестаційні завдання K2 ERP/CRM}}
У звіті потрібно відображати:
[[Категорія:CRM]]
== Журнал «Клієнти» ==
компонент має допомагати компанії вести повний цикл продажів: від першого звернення потенційного клієнта до створення клієнта, відкриття угоди, фіксації комунікацій, контролю стадій продажу та аналізу результативності менеджерів.<div style="border:2px solid #f57c00; background:#fff3e0; padding:14px; margin:16px 0;">
компанія-користувач займається активними продажами своїх послуг або товарів. SEO-опис
{| class="wikitable" style="width:100%;"
== Журнал «Ліди» ==
! | Статуси лідів і джерела лідів
|-
| Які журнали потрібні? '''критично.''' Лід без історії комунікацій оперативно перетворюється на “мертвий контакт”. | Повний цикл продажу від ліда до угоди та звіту
|}
Форма створення ліда повинна бути простою, але достатньою для старту продажу. | Створення ліда, зміна статусу, додавання комунікацій і подій
|-
| Що виступає як критичною вимогою?== Статуси угод ==
Угода показує не без зусиль контакт із клієнтом, а потенційний або фактичний продаж. Правильна реалізація CRM дає можливість не втрачати ліди, контролювати роботу менеджерів, бачити реальну воронку продажів і приймати управлінські рішення для бізнесу на основі даних. Призначення
Критичними помилками вважаються ситуації, коли:
== Колонки журналу клієнтів ==
# у систему потрапляє новий лід;
# менеджер перевіряє контактні інформаційні дані;
# фіксує джерело ліда;
# встановлює початковий статус;
# проводить перший дзвінок або листування;
# додає комунікацію в історію;
# змінює статус ліда;
# за потреби планує наступну дію;
# після зацікавленості клієнта переводить ліда у стадію '''«Угода»''';
# платформа створює клієнта та угоду;
# менеджер веде угоду по стадіях продажу;
# після завершення угода закривається як успішна або програна;
# інформаційні дані потрапляють у воронку продажів і звіти. Статус
До історії можуть входити:
! Журнал лідів повинен відображати потенційних клієнтів і поточний стан роботи з ними. Комунікації потрібні для того, щоб бачити повну історію роботи менеджера: хто дзвонив, кому писали, коли була зустріч, що обговорювали та який результат отримали. Колонка
Експортувати можна:
|}
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
[[Категорія:K2 ERP]]
Довідник статусів лідів описує етапи проходження потенційного клієнта через воронку продажів. ! Значення
* кількість лідів на менеджера;
* кількість комунікацій;
* кількість створених угод;
* кількість успішних угод;
* кількість програних угод;
* середню суму угоди;
* суму успішно закритих угод;
* конверсію в успішні продажі та реалізація. | Ліди, клієнти, угоди, комунікації
|-
| Що виступає як ключовою дією? SEO-опис
Мета задача — створити в K2 ERP CRM-модуль, який автоматизує роботу відділу продажів. Приклади джерел:
Журнал клієнтів містить усі компанії або фізичних осіб, які стали клієнтами. SEO-опис
Типові нагадування:
|-
| ПІБ або назва компанії
| Ім’я потенційного клієнта або назва компанії
|-
| Джерело ліда
| Канал, з якого прийшов лід
|-
| Дата створення
| Коли лід був доданий у систему
|-
| Відповідальний менеджер
| Хто веде ліда
|-
| Поточний статус
| На якому етапі перебуває лід
|-
| Ймовірність успіху, %
| Оцінка шансів на успішну угоду
|-
| Очікувана сума угоди
| Потенційна сума продажу
|-
| Наступна дія
| Запланований дзвінок, зустріч або інша дія
|}
У звіті потрібно відображати:
== Аналітичний сенс воронки ==
* пошук по імені;
* пошук по телефону;
* пошук по email;
* фільтрацію за статусами;
* фільтрацію за менеджерами;
* фільтрацію за джерелами;
* фільтрацію за періодом створення;
* швидку зміну статусу;
* відкриття картки ліда;
* створення нового ліда. ! Воронка продажів повинна візуально показувати проходження лідів та угод по етапах. | Воронка продажів, ліди за період, ефективність менеджерів
|-
| Що має працювати через AJAX? | Конвертація ліда у клієнта та угоду
|-
| Що має зберігатися? {| class="wikitable" style="width:100%;"
! У межах атестації потрібно продемонструвати робочий сценарій. Максимальна оцінка
== Експорт даних ==
! Потрібно передбачити конвертацію ліда у клієнта разом з угодою. ! * кількість нових лідів;
* кількість лідів по джерелах;
* кількість лідів по менеджерах;
* конверсії в клієнтів;
* конверсії в угоди;
* втрати по статусах;
* очікувану суму потенційних угод.== Конвертація ліда у клієнта та угоду ==
</div>
</div>
* хто створив ліда;
* хто змінив статус;
* хто змінив менеджера;
* хто конвертував ліда;
* хто створив угоду;
* хто закрив угоду;
* дату й час зміни;
* старе та нове значення. '''Коротко.''' Потрібно реалізувати CRM-модуль, який дає можливість збирати ліди, переводити їх у клієнтів та угоди, вести історію комунікацій, контролювати воронку продажів, планувати дії менеджерів і формувати аналітику. SEO-опис
компонент повинен підтримувати автоматичні нагадування менеджерам про заплановані події. * реєструвати нові ліди;
* фіксувати джерела звернень;
* вести статуси лідів;
* призначати відповідальних менеджерів;
* конвертувати ліда у клієнта та угоду;
* вести журнал клієнтів;
* вести журнал угод;
* фіксувати комунікації з лідами та клієнтами;
* планувати дзвінки, зустрічі та інші дії;
* будувати воронку продажів;
* аналізувати ефективність менеджерів;
* формувати звіти за період. Значення
== Критичні помилки ==

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

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

! Колонка

! !

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

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

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

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

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

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

компонент повинен підтримувати виконання ключових операцій через AJAX. так само потрібно реалізувати нотифікації при переході ліда у стадію «Угода». !== Шкала оцінювання ==

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

! Тип події

Для реалізації задачі доцільно передбачити такі сутності: Мінімальний сценарій:

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

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

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

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

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

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

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

провідний принцип. CRM — це не без зусиль довідник контактів.

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

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

Менеджери повинні бачити, хто звернувся, звідки прийшов лід, на якому етапі він перебуває, які комунікації вже були, яка очікувана сума угоди, хто відповідальний і що потрібно зробити далі. ! Журнал змін має зберігати: Журнал лідів має підтримувати: Нотифікації можуть бути реалізовані через email, внутрішні сповіщення або WebSocket. CRM — це практична задача; так само реалізовано клієнтами. Бали

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

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

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

  • первинний дзвінок;
  • презентація;
  • комерційна пропозиція;
  • email;
  • зустріч;
  • коментар менеджера;
  • зміна статусу;
  • запланована подія;
  • результат комунікації. ! Джерело ліда потрібно використовувати у звітах, щоб бачити, які канали дають найбільше лідів, клієнтів і успішних угод. Менеджер має оперативно бачити, хто звернувся, з якого джерела, хто відповідальний, яка ймовірність успіху та на яку суму очікується угода.== базовий бізнес-процес ==
Потрібно передбачити можливість експорту списків у Excel або PDF. Колонка ! Що перевіряється

платформа повинна дозволяти:

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

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

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

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

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

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

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

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

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

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

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

Що потрібно створити? # створити джерела лідів;
  1. створити статуси лідів;
  2. створити нового ліда;
  3. вказати телефон, email, джерело та відповідального менеджера;
  4. додати першу комунікацію;
  5. змінити статус ліда через AJAX;
  6. запланувати майбутній дзвінок або зустріч;
  7. показати нагадування менеджеру;
  8. перевести ліда у стадію «Угода»;
  9. виконати конвертацію ліда у клієнта та угоду;
  10. перевірити, що історія продукту комунікацій не втрачена;
  11. змінити стадію угоди;
  12. закрити угоду як успішну або програну;
  13. сформувати воронку продажів;
  14. сформувати звіт лідів за період;
  15. сформувати звіт ефективності менеджерів;
  16. експортувати список або звіт;
  17. показати журнал змін. {| class="wikitable" style="width:100%;"

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

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

Рекомендовані сутності бази даних

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

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

Об’єкт

Назва задача

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

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

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

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

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

Див. так само

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

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

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

Мета задача

  • статуси лідів;
  • джерела лідів;
  • ліди;
  • клієнти;
  • угоди;
  • стадії продажів;
  • комунікації;
  • заплановані події;
  • користувачі-менеджери;
  • нотифікації;
  • журнал змін;
  • файли експорту. Параметр

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

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

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

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

! Відповідь

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

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

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

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

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

  • кількість угод на кожній стадії;
  • конверсії між стадіями;
  • втрати на кожному етапі;
  • очікувану суму угод;
  • успішно закриті угоди. CRM має показувати, що саме робив менеджер і який наступний крок заплановано. Усі дзвінки, листи, коментарі та події мають залишитися доступними в картці клієнта або угоди. Журнал комунікацій зберігає історію контактів із лідами та клієнтами. Поле

Примітка

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

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

Журнал угод відображає комерційні функції ERP та замовлення. ! Потрібно фіксувати важливі зміни в CRM.== Колонки журналу лідів ==

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

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

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

Основна інформаційні матеріали ліда

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

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

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

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

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

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

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

Статуси лідів і джерела лідів
Повний цикл продажу від ліда до угоди та звіту

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

Що виступає як критичною вимогою?== Статуси угод ==

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

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

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

  1. у систему потрапляє новий лід;
  2. менеджер перевіряє контактні інформаційні дані;
  3. фіксує джерело ліда;
  4. встановлює початковий статус;
  5. проводить перший дзвінок або листування;
  6. додає комунікацію в історію;
  7. змінює статус ліда;
  8. за потреби планує наступну дію;
  9. після зацікавленості клієнта переводить ліда у стадію «Угода»;
  10. платформа створює клієнта та угоду;
  11. менеджер веде угоду по стадіях продажу;
  12. після завершення угода закривається як успішна або програна;
  13. інформаційні дані потрапляють у воронку продажів і звіти. Статус

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

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

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

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

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

|- | Що виступає як ключовою дією? SEO-опис Мета задача — створити в K2 ERP CRM-модуль, який автоматизує роботу відділу продажів. Приклади джерел:

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

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

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

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

|- | Що має працювати через AJAX? | Конвертація ліда у клієнта та угоду |- | Що має зберігатися? {| class="wikitable" style="width:100%;"

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

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

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

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

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

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