Коли ти запитуєш своїх працівників, скільки у них запитів «в роботі», можна отримати три різні відповіді. Один рахує лише ті, на які відправив кошторис. Другий — усі повідомлення, які прочитав. Третій — будь-який контакт, який хоча б раз надійшов, незалежно від того, чи він відповів. Один запит, три різних стани — і ніхто не бреше. Просто ніхто ніколи не говорив їм, що насправді означає кожен етап воронки. Ця стаття показує, як побудувати визначення та критерії переходу, щоб всі рахували однаково.
Чому визначення мають значення
Уяви таку ситуацію: клієнт телефонує в понеділок, залишає повідомлення. У вівторок перетелефонуєш, розмовляєш 15 хвилин, домовляєшся про кошторис. У середу відправляєш пропозицію. Клієнт не відповідає. У четвер робиш follow-up. У п'ятницю телефонуєш — не бере. У суботу відправляєш смс. У неділю клієнт пише, що обрав конкурента.
Тепер запитай трьох працівників, на якому етапі цей запит:
- Перший скаже: «новий» — бо не отримав відповіді на кошторис.
- Другий: «кошторис відправлено» — бо пропозиція пішла.
- Третій: «програно» — бо клієнт написав, що пішов до іншого.
Кожна відповідь логічна. Кожна — різна. І кожна перетворює твій звіт про продажі на середню температуру по лікарні — виглядає конкретно, але нічого не означає.
Проблема не в тому, що люди некомпетентні. Проблема в тому, що ніхто не визначив їм, що означає кожен етап, що означає вхід на етап і що означає вихід з нього. Без цього кожен прогнозує на основі своїх критеріїв, а ти не бачиш реальну картину бізнесу.
Ця стаття дає тобі готову структуру воронки для фірми послуг. Можна впровадити її сьогодні — в CRM, в таблиці Excel або на дошці на стіні. Принципи однакові.
Базова воронка продажів для фірми послуг
Воронка продажів у фірмі послуг складається з шести етапів. У кожного етапу є визначення, подія входу, власник та максимальний час, який запит може провести на цьому етапі. Таблиця нижче показує повну модель.
| Етап | Визначення | Подія входу | Власник | Максимальний час |
|---|---|---|---|---|
| Новий | Запит надійшов і ще не був оброблений | Запис в системі / повідомлення від клієнта | Дедікований оператор | 4 години |
| Контакт відбувся | Відбулася телефонна або особиста розмова, під час якої встановлена потреба клієнта | Нотатка про розмову в системі | Продавець | 24 години |
| Потреба підтверджена | Клієнт підтвердив, що зацікавлений і знає обсяг робіт | Визначення обсягу в системі | Продавець | 48 годин |
| Кошторис відправлено | Комерційна пропозиція відправлена клієнтові | Відправлений документ / лист з кошторисом | Продавець / відділ пропозицій | 72 години |
| Рішення | Клієнт розглядає пропозицію, ще не прийняв рішення | Підтвердження отримання пропозиції / немає відповіді протягом 3 днів | Продавець | 5 днів |
| Виграно / Програно | Запит завершився угодою або відмовою | Підписання договору / вписана причина програшу | Продавець | — |
Події входу, не відчуття
Головне правило: запит переходить на наступний етап не тоді, коли «здається, що клієнт зацікавлений», а коли відбувається конкретна річ. Телефонна розмова — це подія. Кошторис відправлено — це подія. Підтвердження отримання пропозиції — це подія. Внесення авансу — це подія.
Подія має бути об'єктивною і верифікованою. Коли ти кажеш «клієнт зацікавлений» — це твоя думка, не факт. Коли ти кажеш «клієнт підтвердив дату візиту» — це факт, дата є в системі. CRM автоматично змінює етап в момент події, якщо ти це налаштуєш. В таблиці робиш це вручну. На дошці — перекладаєш картку. Метод не важливий. Принцип важливий.
Чому «клієнт зацікавлений» — не критерій
Коли ти кажеш «клієнт зацікавлений», ти оперуєш суб'єктивною оцінкою. Ця оцінка залежить від того, як конкретний продавець розуміє слово «зацікавлений». Це означає, що клієнт не сказав «ні»? Що він кивнув? Що він запитав додаткову інформацію? Кожен із цих сигналів різний, і у тебе немає способу їх уніфікувати.
Тому критерії переходу мають бути поведінковими, не перцептивними. Замість «клієнт зацікавлений» кажи «клієнт підтвердив обсяг послуги». Замість «клієнт розглядає» кажи «минуло 3 дні після відправки кошторису, і клієнт не відповів». Замість «клієнт хоче» кажи «клієнт вніс аванс». Кожен із цих критеріїв можна перевірити в системі. Кожен однаковий для всіх працівників.
Причини програшу — закритий список
Коли запит потрапляє на етап «Програно», система має вимагати вказання причини. Без причини не можна закрити запит. Ця причина має бути із закритого списку, який ти встановлюєш один раз і застосовуєш послідовно. Типові причини у фірмі послуг:
- Ціна — клієнт вважав, що пропозиція задорога.
- Термін — клієнту потрібно було швидше, ніж ти міг запропонувати.
- Немає відповіді — клієнт перестав відповідати після відправки кошторису.
- Не наш профіль — запит виходить за межі послуг фірми.
- Дубль — запит від того самого клієнта, який вже в базі.
- Обрав конкурента — клієнт обрав іншу фірму, але вказав причину.
- Клієнт відмовився — проект не відбувся з причин, не пов'язаних з ціною.
Закритий список переслідує дві мети. По-перше, він змушує продавця думати про те, чому він втратив запит. Саме «програно» тебе нічому не навчить. «Ціна — задорого порівняно з трьома іншими кошторисами, які клієнт отримав» — навчить. По-друге, закритий список дозволяє агрегувати дані.
Без закритого списку кожне «інше» і «не знаю» розмиває картину. Через рік у тебе звіт, який ні на що не годиться.
Варіанти воронки за галузями
Фірма послуг — широке поняття. Воронка виглядає по-різному в кабінеті лікаря, по-різному в салоні краси, по-різному в автосервісі і по-іншому у монтажної бригади. Таблиця нижче показує, як адаптувати етапи до специфіки галузі.
| Галузь | Етап 1 | Етап 2 | Етап 3 | Етап 4 | Етап 5 | Етап 6 |
|---|---|---|---|---|---|---|
| Кабінет (консультація) | Новий | Консультація призначена | Візит відбувся | План лікування / послуги представлений | Перший лікувальний візит | Договір підписаний |
| Салон (краса, фітнес) | Новий | Запис на візит | Візит відбувся | Послуга виконана | Повторний запис | Подарункова карта / абонемент |
| Автосервіс | Новий | Діагностика призначена | Діагностика виконана | Кошторис відправлено | Акцепт кошторису | Ремонт виконано |
| Монтажна бригада | Новий | Запит на кошторис | Замір / виїзд на об'єкт | Кошторис відправлено | Акцепт пропозиції | Монтаж виконано |
Ключовий принцип однаковий незалежно від галузі: кожен етап має мати визначення, основане на події, не на відчутті. В кабінеті ти не переходиш на «план лікування представлений», бо «здається, клієнт розуміє». Переходиш, коли дійсно представляєш план — а система це фіксує.
Конверсія між етапами — як рахувати чесно
Конверсія між етапами — це відсоток запитів, які переходять з одного етапу на наступний.
Це правда, але не показує, де йдуть гроші.
Приклад на умовних числах — підстав свої: у тебе 100 запитів. З етапу Новий на Контакт відбувся переходить 60 запитів. З Контакт на Потреба підтверджена — 30. З Потреба на Кошторис відправлено — 20. З Кошторис на Рішення — 12. З Рішення на Виграно — 6.
Тепер видно, що найбільше запитів відсіюється на самому початку: 40 зі 100 втрачаються між Новий і Контакт. Це не проблема з ціною — клієнт ще не бачив ціну. Це проблема з першою відповіддю. Хтось не передзвонив вчасно, не відповів на дзвінок, не написав на повідомлення.
Коли дивишся на конверсію, завжди починай з найбільшого провалу, не з кінця. Виправлення першого етапу дає найбільший дохід. Виправлення останнього етапу дає маргинальний ефект.
Як чесно рахувати конверсію
Рахуєш тільки ті запити, які мали шанс перейти на наступний етап. Якщо запит потрапив у Програно з причиною «не наш профіль», не включаєш його в конверсію — у нього не було шансу пройти далі, бо він був не для тебе. Якщо клієнт обрав конкурента через термін, теж не включаєш — термін це зовнішній фактор, не твоя помилка.
Рахуєш тільки ті запити, які відповідали критеріям твоєї пропозиції і отримали відповідь. Це складніше порахувати, але дає реальну картину твоєї ефективності, не зовнішнього випадку.
Час на етапі — що робити з висячими запитами
У кожного етапу є максимальний час з таблиці вище. Коли цей час минає, а запит не перейшов на наступний етап, створюється задача для власника цього етапу. Це не опція — це обов'язок. Хтось має щось зробити: передзвонити, написати, перевірити, чи клієнт ще живий.
Схема дії:
- 01немає контакту 4год
- →02задача оператору
- →03немає підтвердження 24год
- →04задача продавцю
- →05немає відповіді 72год
- →06задача follow-up
Коли застосовуєш це послідовно, бачиш два ефекти. По-перше, запити не висять місяцями без руху. По-друге, бачиш, хто не виконує терміни — бо задачі накопичуються. Це не стеження. Це управління процесом.
Дані програних запитів — скільки їх зберігати
Коли запит потрапляє в «Програно», потрібно вирішити, що робити з даними. RODO накладає принцип обмеження зберігання: персональні дані зберігаються не довше, ніж це необхідно для цілей, для яких вони були зібрані (ст. 5 RODO, джерело: UODO посібник RODO). Коли мета — тобто обробка конкретного запиту — перестає існувати, дані мають бути видані або анонімовані, якщо немає іншої правової основи (наприклад, податкове зобов'язання).
Практичний підхід: дані програних запитів зберігаються протягом періоду, що дозволяє проаналізувати причини втрат — зазвичай 6–12 місяців. Після цього періоду, якщо немає правової основи для подальшого зберігання, видаляєш персональні дані. Залишаєш тільки агреговану статистику: скільки запитів, яка причина програшу, який ціновий поріг. Ці дані не дозволяють ідентифікувати конкретну людину, тому RODO їх не стосується.
Важливо: рішення про період зберігання — твоє, потрібно його прийняти і задокументувати. Принцип: якщо дані вже не служать жодній бізнес-меті, потрібно їх видалити (ст. 17 RODO, джерело: UODO Право на видалення даних). сумніви — консультуй з IOD.
Контекст — CRM це не норма, це виняток
Це означає, що приблизно три чверті таких підприємств не використовують систему CRM. Багато з них ведуть воронку в таблиці Excel, на пробковій дошці або в голові.
Для тебе це одночасно виклик і шанс. Виклик: потрібно побудувати систему самому, без готових інструментів. Шанс: коли зробиш це, отримаєш перевагу над конкурентами, які діють на око. Тобі не потрібна дорога система, щоб почати. Потрібні визначення, критерії та послідовність.
Зроби це сам за 2 години
Візьми таблицю Excel або аркуш паперу. Витягни з системи або пошти останні 20 запитів, які обробляв цього року. Для кожного запиши: дата надходження, дата першого контакту, дата відправки кошторису, дата рішення, результат (виграно/програно), причина програшу.
Тепер розклади ці 20 запитів по шести етапах з таблиці вище. Використовуй визначення, не свої відчуття. Який етап мав найбільший відтік? Де втрачалися запити? Скільки часу минуло від першого контакту до відправки кошторису? Від кошторису до рішення?
Після такої вправи знатимеш про свій бізнес більше, ніж за місяць перегляду загальних звітів. Ця вправа не потребує жодної системи — тільки твого часу і чесності.
Як це виглядає в системі
В системі все відбувається автоматично. Дзвінок зареєстрований → етап змінюється на «Контакт». Кошторис відправлено → етап змінюється на «Кошторис». Немає відповіді 72год → система створює задачу follow-up.
Коли закриваєш запит як програний, система вимагає вказати причину із закритого списку. Без причини не можна закрити. Це вимагає дисципліни і дає дані для аналізу.
Раз на тиждень отримуєш звіт конверсії між етапами. Бачиш, скільки запитів увійшло на кожен етап, скільки вийшло і куди. Бачиш, який етап — вузьке місце. Бачиш, скільки часу в середньому займає перехід від етапу до етапу. Бачиш, які причини програшу домінують.
Це повна картина твоєї воронки — і тому визначення мають значення.
Щоб побудувати таку систему у своїй фірмі, потрібні три шари: CRM для реєстрації запитів і контактів, воронки для управління етапами і подіями, та AI follow-up для автоматичних нагадувань клієнтам, які не відповіли. Разом вони створюють замкнений цикл: подія змінює етап, відсутність події створює задачу, закриття вимагає причини, звіт показує результат.
Подивись, як це працює на практиці — автоматизація follow-up показує, що відбувається з запитом після першої розмови, а автоматизація звітності показує, які цифри реально бачить власник. Також переглянь автоматизацію обробки запитів, щоб побачити, як одна черга замінює п'ять скриньок, та автоматизацію оферування, щоб зрозуміти, чому кошторис займає три дні, а може годину.
Також тобі знадобиться система завдань, щоб відстежувати, хто що має зробити, та дашборди, щоб бачити всі цифри на одному екрані.
Часті питання
Чи має воронка мати рівно шість етапів?
Ні. Шість — це базова модель для фірми послуг, але можна спростити до п'яти (пропустивши «потреба підтверджена») або розширити додатковими, специфічними для твоєї галузі. Важливо не скільки етапів, а те, щоб кожен мав визначення, основане на події, не на відчутті.
Як часто потрібно перевіряти конверсію між етапами?
Раз на тиждень — мінімум, який дозволяє ловити проблеми, поки вони не розрослися. Щоденний огляд має сенс тільки у фірмах з дуже великим обсягом запитів — понад 50 на тиждень. Для більшості фірм послуг щотижневого звіту достатньо.
Що робити, якщо продавець не вписує причину програшу?
Якщо система вимагає причину для закриття запиту, обійти це неможливо. Якщо ведеш воронку в таблиці, потрібно послідовно цього вимагати — без причини не приймаєш закриття. Без даних немає звіту. Без звіту немає покращення.
Чи потрібно купувати CRM для впровадження воронки?
Ні. Можна почати з таблиці Excel або пробкової дошки. Система потрібна тоді, коли ручне управління починає забирати більше часу, ніж обслуговування клієнта. Для більшості фірм поріг — близько 20–30 активних запитів на місяць.
Як виміряти час на етапі, якщо немає системи?
Встанови в календарі повторювальне нагадування — раз на день, вранці. Перевіряй активні запити і дивись, чи не перевищив якийсь максимальний час з таблиці. В таблиці записуй дату входу на кожен етап. Система автоматично рахує дні між етапами, якщо її налаштувати.
Чи може воронка змінюватися залежно від джерела запиту?
Так. По-різному обробляєш запит з Google Maps, по-різному з рекомендації, по-різному з рекламної кампанії. Можна додати поле «джерело» і диференціювати максимальний час на етапі або критерії переходу. Але базова структура з шести етапів залишається такою ж — змінюється тільки спосіб обробки.