Заявки живуть у чатах. Тобі вже потрібна CRM чи поки вистачить таблиці?

Клієнт написав в Instagram. Ти відповів з телефона між двома зустрічами. Потім він надіслав розміри у Viber, уточнив ціну в Telegram і попросив рахунок на пошту.

Замовлення ще немає. А маленький цифровий квест уже є.

Увечері ти впевнений, що всім відповів. Зранку з’ясовується, що одному обіцяв передзвонити, другому - перерахувати вартість, а третього начебто взяла колега. Колега впевнена, що його взяв ти. Клієнт тим часом узяв когось іншого.

Десь у цей момент у бізнесі звучить сакральне: «Нам потрібна CRM».

Можливо, потрібна. Але перед тим, як обирати систему з красивими графіками, варто зрозуміти, що саме вона має виправити. Бо перенести плутанину з месенджерів у дорожчу програму - теж цифровізація. Просто досить сумна.

Давай розберемося, коли таблиця ще справляється, коли вже заважає, і як перевірити CRM на твоїй роботі, а не на презентації продавця.

Продуктові приклади перевірено 6 жовтня 2026 року. Це не рейтинг CRM і не рекомендація конкретного тарифу. Поради щодо організації процесу - редакційні рекомендації; приклад майстерні умовний.

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

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

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

Відокрем розмову від обліку домовленостей. У чаті можна спілкуватися. Але відповідальний, поточний стан і наступний крок мають бути в одному визначеному місці.

Не обов’язково копіювати кожне «дякую» та емодзі. Потрібно зберегти те, що впливає на дію:

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

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

Базовий рух від звернення до роботи й оплати ми вже розбирали у статті «Як навести порядок у заявках, роботі й оплатах». Тут підемо далі: оберемо, де цей порядок зручно підтримувати.

Уявімо умовну майстерню. Людина звернулася щодо ремонту столу, уточнила доставку, а через місяць замовила ще й полиці.

Це один клієнт. Але різні замовлення.

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

Корисно розрізняти три речі:

Контакт - людина або представник компанії, з яким ти спілкуєшся.

Звернення чи угода - окрема потреба, яку ви зараз обговорюєте: від запиту до погодження або відмови.

Замовлення в роботі - погоджена робота зі своїми умовами, строками й оплатою.

Для простого обліку частину цього можна поєднати. Головне - щоб команда однаково розуміла, що означає один запис. У таблиці на старті ним часто буде окреме звернення чи замовлення, а контактні дані повторюватимуться. Це практичне спрощення, яке потрібно свідомо обрати.

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

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

Таблиця - нормальний робочий інструмент. Їй не потрібно вибачатися за те, що вона не має відділу продажів та стенда на конференції.

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

Почни з такого набору полів:

Номер звернення. Простий унікальний номер, щоб не говорити «той Сергій, який про двері, тільки не той, що минулого тижня».

Дата і джерело. Коли звернулися й звідки: форма на сайті, рекомендація, реклама, конкретний месенджер. Якщо джерело невідоме, так і запиши.

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

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

Стан. Наприклад: нове звернення, уточнюємо завдання, пропозицію надіслано, погоджено, відмовлено. Це приклад, а не універсальна схема для будь-якого бізнесу.

Наступна дія і дата. «Надіслати два варіанти комплектації в середу», а не «в роботі». Друге не пояснює наступної дії.

Домовлена сума та оплата. Якщо ви вже обговорюєте конкретне замовлення. Суму пропозиції, погоджену вартість і фактично отриману оплату краще розрізняти, щоб очікувані гроші не маскувалися під наявні.

Результат або причина зупинки. Погодили, відмовилися, перенесли рішення, не вдалося зв’язатися. Причину записуй зі слів клієнта або позначай як припущення.

Посилання на деталі. Листування, файл пропозиції, технічне завдання - з доступом для тих, кому ці матеріали потрібні.

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

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

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

Дивись на повторювані труднощі.

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

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

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

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

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

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

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

Не визначить, яка заявка хороша, якщо ви самі цього не домовилися.

Не створить реалістичний строк виконання, якщо команда не знає своєї завантаженості.

Не перетворить «зателефонувати колись» на конкретну дію, якщо такого правила немає.

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

Умовний приклад: менеджер закрив угоду як виграну, бо клієнт написав «ок». Виробництво прочитало це як дозвіл починати. Клієнт мав на увазі «ок, подумаю».

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

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

Не потрібно писати регламент на сто сторінок. Потрібно, щоб двоє людей однаково відповіли на запитання: що має відбутися, щоб ми перевели запис сюди?

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

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

Якщо починаєш із Google Sheets, налаштуй доступ до файлу для конкретних людей і відповідні ролі. Google описує можливості читача, коментатора й редактора. Перевір також доступ до папки, де лежить файл: права можуть успадковуватися від неї.

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

Під час перенесення в CRM спочатку перевір правила зіставлення записів. Інакше імпорт може створити двійників або змінити не той запис.

Наприклад, у HubSpot для зіставлення контактів використовують email, а під час імпорту також можуть використовувати Record ID чи інші унікальні значення. Конкретна поведінка залежить від об’єкта та способу додавання. Це не правило для всіх CRM і не гарантія, що будь-яка інтеграція автоматично прибере дублікати.

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

Окремо випробуй експорт. У документації HubSpot щодо експорту описано вивантаження властивостей і зв’язків записів. Але не варто вважати будь-який CSV повною копією всього: перевір, чи є в ньому потрібні поля, історія, примітки та посилання на файли. Для частини даних може знадобитися інший спосіб отримання.

Це продовження тієї самої логіки, про яку ми писали у матеріалі «Підрядник зник. Що залишилося від твого сайту?»: доступ і можливість продовжити роботу потрібно перевіряти заздалегідь.

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

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

1. Нове звернення. Людина заповнила форму. Де з’явився запис, які дані збереглися, хто його побачив? Факт доставки повідомлення ще не означає, що є відповідальний за дію.
2. Повторний контакт. Та сама людина написала ще раз. Як ви знаходите попередню історію? Що відбудеться, якщо вона використає інший email або номер?
3. Передача колезі. Відповідальний захворів. Хто бере звернення й чи бачить домовленості без пошуку в його особистому телефоні?
4. Зміна умов. Клієнт обрав інший варіант. Де зафіксована актуальна пропозиція і як не почати роботу за старою?
5. Наступний крок. Домовилися повернутися до розмови в п’ятницю. Кому й де з’явиться нагадування? Що ви робите, якщо строк пропущено?
6. Збій отримання заявки. Форма чи інтеграція не передала звернення. Як команда помічає проблему і де перевіряє первинне джерело? Не кожна система матиме потрібний контроль без додаткового налаштування.
7. Завершення і звіт. Угода виграна або втрачена. Чи можеш ти знайти причину, відповідального й підтверджений результат?
8. Вихід із системи. Потрібно вивантажити дані. Що реально отримуєш і чого в цьому файлі немає?

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

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

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

Обери один зрозумілий потік. Наприклад, нові запити на певну послугу. Визнач, з якого моменту їх ведете у вибраному обліку, хто відповідає і що саме перевіряєте.

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

Для оцінки дивись не тільки на кількість створених записів. Постав прості запитання:

• Чи є в кожного нового звернення відповідальний?
• Чи можна швидко знайти поточну домовленість?
• Чи видно прострочені наступні кроки?
• Чи може колега продовжити розмову без усного переказу?
• Чи стало менше ручного перенесення або пошуку?
• Чи зрозуміло, що трапилося з отриманими зверненнями?

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

Готовий текст для обговорення з командою - шаблон, а не цитата клієнта:

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

Це менш урочисто, ніж оголосити «ми тепер цифровий бізнес». Зате допомагає клієнту не загубитися між твоїми дуже цифровими співробітниками.

Якщо хочеш зібрати такий процес під свій бізнес, напиши GrandMa. Почнемо з того, як зараз проходить звернення і де зникає наступний крок. Іноді рішенням буде проста таблиця. Іноді - CRM та потрібні інтеграції. Вибір має випливати з роботи, яку треба зробити.