Чому CRM перестала працювати через два місяці після запуску — і хто мав це помітити

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

Чому «не працює» через два місяці — це розходження, а не поломка?

Дослідники process mining називають це concept drift і вважають базовою властивістю процесів, а не аварією. Формулювання з роботи Босе, ван дер Аалста, Жліобайте й Печеніжкіна (IEEE Transactions on Neural Networks and Learning Systems, 2014): більшість бізнес-процесів змінюються з часом, а методи аналізу трактують їх так, ніби вони перебувають у стійкому стані. Дрейф буває раптовим і поступовим, разовим і сезонним.

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

Контур процесу: через які стадії за рік не пройшла жодна угода?

Найпомітніший слід дрейфу — порожні стадії. У квітні 2026 Auspex прогнав власний аудит по своєму ж порталу. У всіх воронках 33 стадії з 60 не пропустили за рік жодної угоди. У головній воронці три стадії з дев'яти — «Відправили КП», «Погодили умови співпраці», «Підписання договору» — стояли порожніми: угоди року йшли скороченим шляхом, від заявки одразу до рахунка й оплати.

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

У квітневому аудиті CRM однієї сервісної компанії та сама картина в іншому масштабі: 37% стадій без жодної угоди за рік, а з тринадцяти налаштованих воронок реально живих вісім. Обидва числа — замір по конкретному порталу, а не галузева статистика; ми не знаємо, як виглядає ця частка в середньому по ринку, і не бачили дослідження, яке її рахує.

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

Контур даних: чому першими ламаються автоматизації, а не звіти?

Другий контур розходиться тихіше. Поля, які на впровадженні хтось замовив і захищав, поступово перестають заповнюватись — не рішенням, а без нього. На власному порталі Auspex у квітні 2026 налічувалося 112 користувацьких полів, з яких реально заповнювались два-три. В аудиті сервісної компанії на картці угоди виявився 121 користувацьке поле із заповненістю 0%, а вибіркова перевірка контактів дала близько 19% дублів і майже половину контактів без прив'язки до компанії.

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

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

Контур поведінки: чому обхід дешевший за систему?

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

Найточніше цей механізм задокументований не в продажах, а в лікарнях. Коппель, Веттернек, Теллес і Карш (Journal of the American Medical Informatics Association, 2008) розібрали, як медсестри обходять систему штрихкодового підтвердження ліків, і описали 15 типів обходів та 31 тип причин — від зім'ятих і затертих штрихкодів до розряджених батарей і нестабільного Wi-Fi. Сповіщення системи персонал перекривав для 4,2% пацієнтів і 10,3% препаратів. Висновок авторів: обхід породжують недоліки конструкції, впровадження і вбудованості в реальний робочий процес.

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

У CRM обхід має вимірюваний слід — задачі. На порталі Auspex у квітні 2026 жодна відкрита задача не була прив'язана до угоди чи контакту: нуль відсотків. В аудиті сервісної компанії таких було 8%. «Передзвонити клієнту» живе в задачнику, угода живе у воронці, зв'язку між ними немає. З погляду воронки цього дзвінка не існує.

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

Чому три контури не складаються в один сигнал?

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

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

Що насправді показують ваші звіти?

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

Далі з'ясувалося, що 44,6% лідів отримували першу «активність» у перші п'ять хвилин, і це не люди. Це бізнес-процеси оновлювали поле останньої активності. Коли автоматичні активності до п'яти хвилин виключили з розрахунку, медіана людської реакції склала 11,2 години, а середня — 55,7 години.

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

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

Чому власник процесу — це не адміністратор CRM?

Усі три контури мають спільну умову виявлення: хтось має регулярно дивитися і мати право змінювати. Майкл Хаммер описав цю роль у статті «The Process Audit» (Harvard Business Review, квітень 2007) як один із п'яти обов'язкових enabler'ів процесу, поряд із дизайном, виконавцями, інфраструктурою і метриками. Власник у його визначенні — керівник, який відповідає за процес і за його результат.

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

— Michael Hammer, The Process Audit, HBR, 2007

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

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

Як провести ревізію трьох контурів за 90 хвилин?

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

• Процес, 30 хвилин. Відкрийте звіт по стадіях за 12 місяців, випишіть стадії з нулем угод і воронки, у які за рік не зайшло нічого. По кожній — письмове рішення: прибрати або відновити. Окремо спитайте менеджера, який крок він робить у переписці замість системи. Цей крок і буде стадією, якої у вас немає.
• Дані, 30 хвилин. Візьміть три автоматизації, які запускали на впровадженні, і для кожної випишіть поля, від яких залежить умова. Подивіться заповненість саме цих полів за останній місяць. Паралельно порахуйте, скільки користувацьких полів на картці угоди заповнені менше ніж у 10% випадків — це список кандидатів на архів.
• Поведінка, 30 хвилин. Подивіться частку відкритих задач, прив'язаних до угод і контактів, і розподіл відкритих угод по менеджерах. Потім поставте команді одне питання: що ви робите повз CRM, бо так швидше. Відповідь ніколи не буває порожньою, і саме вона найкорисніша з усієї ревізії.

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

Що з цим робить Auspex?

Auspex — компанія з впровадження CRM і автоматизації бізнес-процесів. Аудит, з якого взяті числа в цій статті, у квітні 2026 Auspex прогнав насамперед по власному порталу. 33 порожні стадії з 60, 112 користувацьких полів із двома-трьома робочими, нуль задач, прив'язаних до угод, — це наші числа, а не клієнтські. Портал працює багато років, через нього пройшли сотні налаштувань і десятки людей, які давно не в компанії.

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

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

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