Клієнт втрачений: як зв’язати лід, можливість, контракт і повернення платежів у єдину ланцюжок

Найпоширеніше розчарування продавців — це не «замало клієнтів», а те, що лід, який уже приходив, зникає посеред процесу. Візитка з виставки опиняється у шухляді, після кількох повідомлень у WeChat зв’язок обривається, пропозицію надсилають — і через тиждень ніхто не відповідає, підписують договір — але гроші так і не надходять. Кожен каже, що вів справу, але коли справу перебирає інша людина, доводиться починати з нуля: «До чого ви дійшли раніше?»

Суть проблеми: життєвий цикл клієнта розрізаний на фрагменти

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

• Ліди не класифіковані: всі візитки звалені в одну купу, клієнти з високим рівнем зацікавленості загублені серед низькоякісних лідів.
• Немає чіткого графіку відстеження: немає «наступної дати зв’язку», забувають у зайнятості, а клієнти вважають, що до них не ставляться серйозно.
• Пропозиція і договір не пов’язані: усні обіцянки не співпадають з остаточними умовами договору, під час суперечок немає документальних підтверджень.
• Повернення коштів не синхронізоване з доставкою: бухгалтерія знає лише дату виставлення рахунку, продавець не знає моменту приймання, клієнти вважають, що «гроші сплатили, а послуги не отримали».

Згідно зі звітом Salesforce «State of Sales», продавці проводять у середньому лише близько 28% свого часу у справжньому спілкуванні з клієнтами, решта значної частини йде на пошук матеріалів, узгодження позицій та написання повторюваних звітів. Фрагментарне управління — одна з основних причин.

Бізнес-логіка: розбивати не за людьми, а за етапами

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

1. Лід (Lead): джерело, галузь, бюджетний діапазон, заплановані продукти. Перший контакт має відбутися протягом 48 годин, інакше автоматично надходить нагадування або лід переводиться у вільний простір.
2. Можливість (Opportunity): підтвердження потреби, версія рішення, конкуренти, очікувана сума угоди, плановий день підписання. Після кожного контакту обов’язково складається запис про відстеження.
3. Договір (Contract): зразок умов, додатки, процедура затвердження, історія змін. Сума договору автоматично порівнюється з прогнозом можливостей; при відхиленні понад допустимий поріг необхідно пояснити причину.
4. Повернення коштів (Payment): контрольні пункти, заявка на виставлення рахунку, підтвердження отримання платежу, попередження про прострочення. Синхронізація зі станом проекту чи відвантаженням, щоб уникнути ситуації, коли «гроші прийшли, а товар не відправлений», або «товар відправлений, а гроші не надійшли».

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

Логіка дизайну: ролі, права та межі інтерфейсу

Різні ролі бачать різний обсяг даних, але спільний базовий набір фактів:

• Продавець: свої ліди та можливості, спільні клієнти для командної роботи, швидке ведення записів з мобільного пристрою.
• Начальник відділу продажів: воронка команди, коефіцієнт перетворення етапів, список невідстежених завдань, порівняння прогнозів і реальних результатів.
• Бізнес/Юридичний відділ: шаблони договорів, затвердження умов, стан підключення до електронного підпису.
• Фінансовий відділ: план повернення коштів, стан виставлення рахунків, вік заборгованості; без змін у продажах, лише позначка про фінансові аномалії.

У дизайні інтерфейсу сторінка списку вирішує питання «З ким слід спілкуватися сьогодні?», а сторінка деталей — «Яка повна історія цього клієнта?». Записи про відстеження підтримують переклад голосу в текст, згадування колег, прикріплення файлів, що знижує витрати на введення даних. Правила вільного простору мають бути налаштованими: скільки днів без відстеження — автоматичний повернення, чи залишати після цього у власника лише право на читання.

Розробка та впровадження: моделі даних та ключові моменти інтеграції

На рівні даних рекомендується взяти за основу клієнта (Account), а ліди, можливості, договори та повернення коштів — як пов’язані сущності, замість чотирьох окремих таблиць:

• Основні дані клієнта: уніфікований код суспільного кредиту або податковий номер для уникнення дублювання одного й того самого клієнта.
• Хронологія відстеження: всі контакти (дзвінки, електронні листи, візити, зведення у WeChat) сортується за часом, підтримується пошук по повному тексту.
• Зразок версії: кожна зміна в пропозиції чи договорі зберігає номер версії, порівнюючи відмінні поля.
• Зовнішня інтеграція: зведення повідомлень з Enterprise WeChat/DingTalk заноситься до хронології; платформа електронного підпису повертає оновлення стану договору; фінансова система записує суму отриманого платежу.

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

Критерії приймання та порядок запуску

Рекомендується запускати в три етапи, кожен з яких має чіткі вимірювані критерії приймання:

1. Перший етап (2–3 тижні): введення лідів, нагадування про відстеження, правила вільного простору. Приймання: зменшення відсотка невідстежених завдань до 30%, скорочення часу першого відгуку на лід до 24 годин.
2. Другий етап (3–4 тижні): етап можливостей, версія пропозиції, звіт про воронку. Приймання: можна підрахувати коефіцієнт перетворення етапів, відстежити відхилення від прогнозу.
3. Третій етап (4–6 тижнів): затвердження договору, план повернення коштів, фінансова синхронізація. Приймання: успішне збіг з перерахуванням коштів із договором — показник ≥90%.

Найбільший ризик — небажання продавців вносити дані. Рішення: зробити «наступну дату зв’язку» та «одним натиском вести відстеження» максимально простими, а на щотижневих зборах начальник дивиться лише на системну воронку, а не на усні звіти — тоді внесення даних закріпиться.

Поширені помилки та способи їх уникнення

Часто компанії при виборі CRM роблять з неї «супер-контактну книгу», з десятками полів, які продавець не встигає переглянути, тож просто не заповнює. Більш стабільний підхід — спочатку запустити менш ніж 12 обов’язкових полів, протестувати протягом місяця, а потім додавати нові за результатами аналізу. Інша проблема — занадто радикальні правила вільного простору: продавця, який щойно перейшов на нову посаду, вже відправляють назад, коли він ще не встиг познайомитися з клієнтами, що викликає сильне незадоволення в команді. Рекомендується встановити «період захисту»: нові ліди, виділені за 7 днів, не відправляються назад через невдалу угоду, але обов’язково мають залишитися у системі щонайменше два записи про відстеження.

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