Звіти в CRM і SaaS гальмують: черги й індекси без переписування платформи

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

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

1. Назвіть звіт, через який уже чекають

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

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

Біля звіту вистачить однієї сторінки:

• Назва звіту, хто його запускає і як часто. «Продажі», «керівник філії», «фінанси щопонеділка» — уже досить.
• Один справжній запуск на справжньому діапазоні дат, до будь-яких правок. Скільки секунд і чи був таймаут.
• Чекають на екрані чи лише на файл. Лагодити це треба в різних місцях.
• Яке рішення на цьому звіті ухвалюють. Цифра, якою ніхто не користується, — інша історія, ніж цифра, без якої не можна дзвонити клієнту.

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

2. Свіжий продукт гальмує з тих самих причин

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

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

Запитайте того, хто може відкрити запит:

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

3. Коли звіт уже не варто рахувати у відкритій вкладці

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

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

Рахуйте у фоні, коли сходиться ось це:

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

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

4. Спершу перевірте, чи клієнт не бачить чужі рядки

Швидкий звіт із чужими рядками гірший за повільний. Коли він відкривається одразу, витік помічають швидше. У CRM або SaaS філії й акаунти живуть в одному застосунку і не повинні бачити записи одне одного.

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

Перш ніж тішитися швидким вивантаженням:

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

5. Короткий план, і це не нова платформа

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

План краще тримати таким, щоб його закінчити:

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

Коли звати спеціаліста

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

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