Чек-лист інтеграції CRM з телефонією: що перевірити перед запуском дзвінків

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

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

Найчастіша помилка — інтеграція заради інтеграції. Хтось сказав «треба, щоб дзвінки були в CRM», підрядник підключив, галочку поставили. Через що саме це підключали — ніхто не сформулював.

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

Перед технічним налаштуванням дайте чесні відповіді на два питання. Навіщо CRM знати про дзвінки? Які рішення ви хочете приймати щотижня, дивлячись у звіт?

Типові цілі, які ми фіксуємо з клієнтами на старті:

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

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

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

Проблема: компанію вибирають за ціною чи звичкою, не перевіривши, чи є готова інтеграція з потрібною CRM. Потім виявляється, що записи не передаються, API закритий, а підміни номерів для call tracking немає взагалі.

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

Три варіанти, які ми бачимо в малому й середньому бізнесі найчастіше:

• Хмарна АТС (віртуальна телефонія). Найпоширеніший вибір. Готові конектори до популярних CRM, працює call tracking, записи зберігаються в хмарі. Закриває потреби більшості відділів продажів без програмування.
• SIP-телефонія через провайдера. Гнучкіша й дешевша на великих обсягах, але інтеграцію часто треба збирати руками через API. Має сенс, коли дзвінків тисячі на місяць і потрібна тонка кастомізація логіки.
• Мобільні менеджерів напряму. Найгірший для контролю варіант. Дзвінки йдуть повз CRM, записів немає, аналітики немає. Якщо у вас зараз так — інтеграція почнеться саме з відмови від цієї схеми, а не з налаштувань.

Рішення перед запуском просте: звірте, чи має ваша телефонія готовий конектор саме до вашої CRM, чи доведеться писати інтеграцію окремо. Якщо ви ще на етапі вибору системи, дивіться на цю сумісність одразу. У нас налаштована телефонія під Pipedrive, KeyCRM і Kommo — і під кожну з них логіка дзвінків збирається трохи по-різному.

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

Типовий фейл виглядає так: дзвінки є, вони видно в журналі телефонії, але CRM не реагує на них як на бізнес-подію. Лід не створюється, картка не відкривається, задача не ставиться. Менеджер поговорив, поклав трубку — і слід зник. Через тиждень ніхто не пам'ятає, що той клієнт узагалі телефонував.

Причина майже завжди одна: під час налаштування прописали маршрутизацію дзвінка, але не прописали, що CRM має з цим дзвінком зробити. Це різні речі. Телефонія вміє з'єднати абонента з менеджером — і на цьому її робота закінчена. Перетворити дзвінок на лід, контакт чи задачу має вже CRM, і це окреме правило, яке хтось мусить свідомо налаштувати.

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

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

Далі прогоніть кожен сценарій руками і перевірте чотири речі. Чи створюється лід із першого ж дзвінка. Чи не плодяться дублі контактів на той самий номер. Чи коректно працює пошук за номером у різних форматах (+380, 0, з пробілами). Чи фіксується статус — прийнятий, пропущений, недозвон.

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

Записи розмов — найцінніший актив, який дає інтеграція. І найчастіше зламаний.

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

Перевірте три речі до запуску.

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

Хто має доступ
Менеджер бачить тільки свої дзвінки чи чужі теж? Керівник — усі? Маркетинг — вибірку для аналізу скриптів? Якщо доступ не розмежований, ви або отримаєте витік (менеджер перед звільненням вивантажить базу розмов), або параліч (ніхто не наважується нічого чіпати).

Чи запис прикріплюється до угоди автоматично
Це ключовий пункт. Запис, який лежить окремо в журналі телефонії, для роботи марний. Запис, який висить у картці угоди поруч із сумою, статусом і коментарями, — це інструмент. Менеджер відкрив картку перед повторним дзвінком, за 30 секунд послухав, про що домовлялися минулого разу, і заходить у розмову підготовленим.

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

Покажемо, чого це коштує. В одного нашого клієнта в ніші B2B-послуг угоди йшли по 6–10 тижнів, а телефонія стирала записи через 14 днів. Коли керівник захотів розібрати, чому зірвалася угода на $5 000, ключових переговорів місячної давнини в системі вже не було. Тариф із продовженим зберіганням коштував кілька сотень гривень на місяць — у сотні разів дешевше за одну таку угоду.

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

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

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

Причина — розподіл ніхто не описав як бізнес-правило. Телефонія за замовчуванням просто шукає вільну лінію. Логіку «гарячі ліди — досвідченим, регіон Х — менеджеру Y, повторні звернення — тому, хто вів клієнта» треба прописати окремо, і це робота не телефонії, а зв'язки CRM + телефонія.

Перед запуском перевірте чотири речі:

1. Принцип черги — round-robin порівну, за пріоритетом менеджера, за напрямком чи регіоном.
2. Прив'язку до відповідального — повторний дзвінок наявного клієнта йде на того, хто його вже веде, а не випадковому.
3. Сценарій недозвону — що відбувається, якщо менеджер не взяв трубку за N гудків. Перекидається на наступного? На керівника?
4. Повторні дзвінки й переадресацію — клієнт, який не додзвонився, отримує зворотний дзвінок чи лишається загубленим.

Окреме слово про сам принцип черги — універсально правильного тут немає. Round-robin порівну добре працює, коли менеджери приблизно рівні за досвідом, а напрямки однорідні. Щойно з'являються «дорогі» гарячі ліди й новачки в команді, рівний розподіл починає шкодити: половину найкращих звернень обробляє той, хто ще не вміє закривати. Тоді логічніше віддавати пріоритетні джерела сильним менеджерам, а простіші — решті. Правило має відображати вашу реальну структуру продажів, а не абстрактну «справедливість».

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

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

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

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

Причина — на старті ніхто не визначив набір метрик (див. перший розділ про мету), тому в CRM просто валиться сирий лог дзвінків без розрахунку конверсій.

Базовий набір, без якого запускатися не варто:

Просунутий рівень, коли база вже працює:

• наскрізна конверсія дзвінок → лід → продаж за кожним джерелом;
• результативність менеджерів за дзвінками, а не за відчуттями;
• віддача рекламних каналів саме у продажах, а не в лідах;
• аналіз «коротких дзвінків» — масові розмови до 20 секунд майже завжди означають кривий скрипт або нецільовий трафік.

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

Один приклад із практики, як це працює, коли налаштовано правильно. У клієнта з продажу обладнання % пропущених вхідних тримався на рівні 22% — майже кожен п'ятий лід не отримував відповіді. Коли ми вивели цей показник на дашборд керівника й завели автозадачі на передзвон, за два місяці пропущені впали до 6%, а кількість угод за той самий рекламний бюджет зросла приблизно на чверть.

Жодних нових витрат — просто перестали втрачати те, за що вже заплатили. Який мінімум показників власник має тримати перед очима щотижня, ми розклали в матеріалі про ключові CRM-метрики для контролю продажів. А щоб ці цифри не доводилося збирати руками, ми будуємо дашборди під відділ продажів.

CRM плюс телефонія без маркетингових даних — це половина системи. Ви бачите, що дзвінків багато, але не бачите, яка реклама їх привела.

Проблема стара як світ: маркетинг звітує про ліди, продажі скаржаться на «погану якість», а об'єктивної картини немає в жодного з відділів. Кожен оперує своїм зрізом даних, і суперечка триває вічно, бо немає спільного джерела правди.

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

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

• чи передається в CRM джерело дзвінка (utm-мітки, кампанія, ключове слово, номер);
• чи коректно працює підміна номерів на сайті й чи не плутає джерела;
• чи бачите ви в одному звіті, яка реклама принесла не просто дзвінки, а оплачені угоди.

Коли це працює, картина стає чесною. Ви бачите, що канал А дає дешеві дзвінки, які не конвертуються, а канал Б — дорогі, але кожен третій стає клієнтом. І ви перекидаєте бюджет туди, де гроші повертаються. Без цього зв'язку рекламний бюджет витрачається наосліп.

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

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

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

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

Закрийте це до запуску трьома правилами:

• Ролі за принципом мінімуму. Менеджер бачить свої угоди й свої дзвінки. Керівник напряму — свою команду. Власник і аналітик — усе. Ніхто не має зайвого доступу «про всяк випадок».
• Контроль експорту. Масове вивантаження бази має бути правом обмеженого кола людей, а краще — з логуванням, хто й коли експортував.
• Політика зберігання. Визначте, скільки тримаєте записи й коли видаляєте. Це і про порядок, і про відповідальне поводження з даними клієнтів.

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

Спокуса велика: усе ніби налаштовано, хочеться швидше вмикати й працювати. Саме на цьому економлять час — і саме за це платять потім найдорожче.

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

За нашою практикою, до 80% проблем дешевше знайти до старту. Тест займає кілька годин, виправлення на бойовому — кілька днів плюс втрачені ліди.

Перед повноцінним запуском обов'язково пройдіть мінімальний прогін:

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

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

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

Зведемо в один список те, з чим стикаємося в кожному другому проєкті. Якщо впізнаєте хоча б три пункти у себе — інтеграцію треба перевіряти, а не довіряти їй.

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

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

Сім блоків, які треба закрити галочками перед тим, як пускати реальні дзвінки:

1. Мета — записані конкретні рішення, які прийматимете на основі даних дзвінків.
2. Логіка дзвінка — для кожного типу виклику прописано, що робить CRM (лід, контакт, задача).
3. Записи — зберігаються достатньо довго, прикріплюються автоматично, доступ розмежований.
4. Розподіл — є правило черги й сценарій недозвону, пропущені стають задачами.
5. Аналітика — налаштовано базовий набір метрик і дашборд, на який дивляться щодня.
6. Call tracking — джерело дзвінка передається в CRM і видно у звіті продажів.
7. Тест — прогнали всі сценарії руками й перевірили аналітику через 24 години.

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

Як привчити команду працювати в системі без тотального контролю, ми розбирали в матеріалі про роботу менеджерів у CRM без мікроменеджменту. Для інтернет-магазинів є своя специфіка телефонії й розподілу — її ми описали в гайді про CRM для e-commerce.

Ми пройдемо цей чек-лист за вас: опишемо логіку дзвінків, підключимо call tracking, зберемо аналітику в дашборд і протестуємо все до запуску — щоб жоден оплачений лід не загубився між трубкою і карткою угоди.

Залиште заявку на впровадження CRM і налаштування телефонії — і ваш відділ продажів почне працювати з повною картиною по кожному дзвінку.