«У нас немає даних для AI»: чому це проблема архітектури, а не бази

Чому заперечення звучить розумно — і де в ньому підміна?

Занепокоєння справедливе по суті. Автоматизація, побудована на брудних даних, справді розганяє безлад: правило розподілу лідів працює бездоганно й розподіляє дублі, звіт будується миттєво й рахує одного клієнта за трьох. Це не гіпотетичний ризик, і саме тому «спочатку дані» — правильний інстинкт.

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

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

Які три різні речі називають «немає даних»?

За однією фразою ховаються три різні діагнози, і лікуються вони по-різному:

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

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

Який діагноз найчастіший?

Показовий приклад є у самого Auspex, у власній CRM. У червні 2026 року компанія реорганізувала воронку лідів на своєму порталі Bitrix24: 31 450 лідів, 23 стадії.

Причина, з якої воронка стала непридатною, полягала не в кількості записів і не в їх забрудненості. В одну вісь «стадія ліда» були звалені три незалежні виміри: стадія процесу, тип ліда і причина закриття. Тому стадій виявилося 23 — вони перемножувалися. Реально активними при цьому були близько 330 лідів, тобто один відсоток.

Жодного біта інформації не бракувало. Було відомо, на якому етапі лід, що це за лід і чому його закрили. Дістати ці три відповіді окремо було неможливо, бо вони жили в одному полі.

Виправлення полягало не в тому, щоб зібрати більше даних, а в тому, щоб розчепити осі: стадія відповідає тільки за процес, тип ліда і причина закриття переїхали в окремі поля. Стадій стало 9 замість 23. У міграції перемістили 18 799 лідів без помилок, згодом видалили 453 дублі.

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

Чому дані псуються вище за течією?

Найбільш досліджений опис цього механізму — робота Sambasivan та співавторів «Everyone wants to do the model work, not the data work», представлена на конференції CHI 2021 (Google Research). Автори взяли інтервʼю у 53 практиків AI в Індії, країнах Східної і Західної Африки та США й описали явище, яке назвали data cascades: компаундні події, що спричиняють негативні наслідки нижче за течією через проблеми з даними. За їхніми даними, поширеність таких каскадів становить 92%, а характеризують вони їх чотирма словами — pervasive, invisible, delayed, but often avoidable.

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

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

Скільки даних насправді потрібно першому сценарію?

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

• Миттєва відповідь на вхідний лід: канал звернення, контакт, час створення, відповідальний. Чотири поля.
• Автонагадування про зустріч: дата й час, контакт, статус підтвердження. Три поля.
• Контроль завислих угод: стадія, дата останньої зміни стадії, сума, відповідальний. Чотири поля.
• Звіт про причини втрати: причина закриття як окреме поле із закритим переліком значень. Одне поле, якого зазвичай і бракує.

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

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

Чому точка захоплення дешевша за ретроспективне прибирання?

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

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

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

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

Жоден із цих пунктів не виглядає як AI-проєкт. Вони визначають, чи буде через півроку на чому його будувати.

Як виглядає перший місяць, поки дані ще брудні?

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

Міряти варто вузько, у межах того самого зрізу:

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

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

Коли заперечення справедливе?

Є випадки, коли «спочатку дані» — правильна відповідь, і чесно назвати їх важливіше, ніж продати пілот:

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

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

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

Який наступний крок?

Auspex — компанія з впровадження CRM та автоматизації бізнес-процесів для SMB. Розмова про автоматизацію починається не з вибору інструмента й не з обсягу вашої бази, а з двох питань: який сценарій ви хочете запустити першим і які пʼять полів він читає. Відповідь на них зазвичай показує, що даних для старту більше, ніж здавалося, а роботи — менше. Надбудова у вигляді AI-агентів для підтримки чи кваліфікації лідів має сенс тоді, коли цей шар закритий; цим напрямом займається партнерський бренд Grow2.ai.