Подивімося на шлях одного звернення: звідки воно приходить, хто уточнює потребу, як продаж передає роботу команді виконання і де керівник перевіряє результат.
Рухайтеся зліва направо. Розкрийте блоки, щоб побачити, що в них відбувається. На телефоні карту можна прокручувати горизонтально.
Канали фіксують перший контакт і його контекст.
Запит потрапляє до CRM разом із джерелом, контактами та темою звернення.
Історія розмови зберігається поруч із клієнтом, щоб наступний працівник не починав спочатку.
Рекомендація пов’язується з компанією-партнером і відповідальним за цей канал.
Не кожне звернення одразу готове до продажу.
Напрям послуги, терміновість, мову спілкування та наявність потрібних даних.
Призначається відповідальна команда й наступна дія. Невизначений запит лишається на першій лінії, а не губиться у випадковій черзі.
Окремі типи робіт мають різні маршрути.
Менеджер уточнює склад робіт, умови й очікуваний результат.
Домовленості та потрібні документи додаються до наступного етапу, а не залишаються лише в листуванні.
Продаж ще не означає, що робота вже прийнята.
Координатор підтверджує, що відомі обсяг, обмеження, документи та відповідальний виконавець.
Якщо бракує даних, створюється задача на уточнення із причиною та строком.
Завершення послуги — не кінець історії клієнта.
Зауваження переходить до власника послуги, а клієнтський відгук — до відповідального за наступну дію.
Нова потреба чи рекомендація може започаткувати наступний погоджений контакт.
Стрілки показують принцип передачі. Вони не відображають реальний потік заявок і не підключені до порталу.
Цінність не в кількості полів. Система має допомагати побачити, де зупинилася робота, хто приймає наступний крок і що заважає його виконати.
Керівник бачить власника, причину очікування та наступну дію — не лише прострочений статус.
Зміна стадії не підміняє підтвердження: нова команда приймає повний комплект і знає, що робити.
Історія, документи та умови переходять разом із робочою задачею.
Зауваження або нова потреба запускають визначену дію, а не зникають після закриття угоди.
У цій моделі назва воронки пояснює, яку роботу команда має завершити. Натисніть на приклад, щоб побачити можливі етапи, власника та результат.
Зафіксувати потребу й визначити відповідальний напрям.
Власник: команда прийманняНове звернення → контакт встановлено → потребу уточнено → призначено відповідального. Для переходу далі мають бути відомі послуга, контакт і наступна дія.
Зрозуміти обсяг робіт і підготувати погоджену передачу.
Власник: менеджер напрямуКваліфікація → консультація → пропозиція → умови погоджено. До виконання передаються обіцянки клієнту, межі послуги та комплект документів.
Провести послугу через документи, очікування та результат.
Власник: координаторПриймання → перевірка даних → виконання → очікування відповіді → результат перевірено. Відсутній документ повертає задачу на уточнення.
Погодити період, виконати план і прийняти рішення про продовження.
Власник: сервісний координаторПідключення → обслуговування → підсумок періоду → продовження або завершення. Важливо зберігати умови та статус оплати.
Довести проблему до перевіреного рішення, а не лише закрити задачу.
Власник: контроль якостіЗвернення отримано → причину визначено → власника призначено → рішення виконано → результат перевірено з клієнтом.
Повернутися до клієнта за нової потреби чи погодженої нагоди.
Власник: менеджер клієнтаПотреба або відгук → контакт погоджено → новий запит або завершення контакту. Повторна дія має мати зрозумілу причину й відповідального.
Це вигадані навчальні приклади. Вони не повторюють вихідні воронки один до одного й не є експортом CRM.
Кілька механізмів можуть працювати в одному маршруті. Їх важливо розрізняти, щоб розуміти, що саме треба перевіряти й підтримувати.
Наприклад: призначити задачу, повідомити відповідального або оновити поле після зміни стадії.
Зібрати дані, запросити погодження, повернути задачу на доопрацювання й контролювати строк.
Передати подію між CRM, телефоном, поштою, сайтом чи системою звітності.
Система зберігає контекст → призначає відповідального → створює задачу на отримання файла → нагадує про строк → передає сигнал керівнику, якщо затримка не знята → продовжує маршрут після перевірки документа.
У цій сторінці показано навчальний сценарій. Жодні реальні повідомлення, угоди чи задачі не створюються.
У каталозі порталу було 126 облікових записів на дату перевірки. Серед них можуть бути службові, технічні чи неактивні профілі, тому число людей, що працюють у компанії, не підтверджене.
Демонстраційний показник, щоб пояснити керівний зріз.
Приклад для обговорення передач між командами.
Не дані порталу, а приклад винятків, які можуть потребувати уваги.
Ілюстрація наступного циклу роботи з клієнтом.
Точні налаштування, чисельність команди, обсяг звернень і фактичні результати компанії цією моделлю не стверджуються.
Щоб перетворити схему на робочий інструмент, керівнику варто поставити чотири прості запитання:
У кожної передачі є відправник, отримувач і строк.
Домовленості, документи та обмеження не повинні губитися.
Потрібно відрізняти обов’язкову перевірку від необов’язкового нагадування.
Сигнал має пояснити причину, відповідального та необхідну дію.
Почнемо з процесів, власників і місць передачі. Потім зіставимо їх із воронками, даними та автоматизацією — щоб визначити, де потрібен контроль і що змінювати спочатку.
Обговорити аудит CRMДалі можна почитати про запитання перед впровадженням CRM або план упровадження Bitrix24.
