Автоматизація проєктного менеджменту: AI-аналітика в Planfix

Штучний інтелект

24.7.26

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

1. Межі масштабування Planfix: чому впорядкована система втрачає керованість при зростанні проєктів

Після того як вся комунікація опинилась у Planfix, з’явилось відчуття, що проблема вирішена. Дійсно, хаос зник. Повідомлення більше не губляться, є відповідальні, працюють ескалації, вся історія зберігається і доступна. Команда працює не в месенджері, а в системі, де є логіка і контроль. Зʼявились усілякі "зручності" та "допоміжний функціонал" для РМ та для команди. І на цьому етапі здається, що цього достатньо, як то кажуть "діло пішло"! І це правда — але тільки до певного масштабу.

Поки у вас 3–5 проєктів, ви все ще тримаєте картину в голові. Ви пам’ятаєте, де зараз є ризики, де клієнт чекає відповіді, а де все рухається нормально. Ви можете зайти в кілька комунікаційних задач і швидко зрозуміти контекст. Але коли проєктів стає десятки, відбувається зсув. Проблема вже не в тому, що даних немає. Проблема в тому, що їх стає занадто багато.

У вас є вся історія комунікації. Є задачі. Є статуси. Є коментарі. Є дзвінки і їх транскрибація у текст. Є зміни в процесах. Формально — у вас є відповіді на всі питання.

Але щоб їх отримати, потрібно вручну:

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

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

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

З’являється дуже конкретний запит: мати можливість у будь-який момент відкрити один екран і побачити коротку, але змістовну картину по кожному проєкту. Без перегляду десятків задач і чатів.

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

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

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

Саме в цей момент з’являється логічне питання: а що, якщо не людина буде збирати цю картину вручну, а АІ інтегрований в систему буде робити це автоматично?

2. Автоматизація AI-звітів у Planfix: від бізнес-питань до інтеграції Хроніки проєкту

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

Перші три питання були максимально базові:

чи була активність клієнта за минулу добу
чи була активність з нашого боку
якщо була комунікація — про що вона була (коротке резюме)

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

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

Тому важливо було не просто зафіксувати факт «була активність», а розділяти:

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

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

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

У нас вся розробка побудована через задачі в акаунті клієнта:

кожен запит декомпозується
кожна задача проходить статуси: нова → узгодження → в роботі → тестування → завершено
у випадку правок — повернення на доопрацювання

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

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

Третій важливий блок — дзвінки. Для нас це найнасиченіший канал комунікації. За одну годину дзвінка ми отримуємо більше контексту, ніж за день переписки.На дзвінку ми бачимо екран клієнта, уточнюємо деталі, отримуємо розгорнуті відповіді та формуємо задачі і домовленості. Але історично це була проблема. Запис дзвінка - це просто файл. Щоб витягнути з нього користь, його потрібно передивлятись або робити нотатки вручну. Це займає час і з’їдає ресурс як проєктного менеджера так і розробника. Рішення з’явилось тоді, коли стали доступними нормальні сервіси транскрибації. Ми почали обовʼязково записувати всі дзвінки, далі автоматично їх транскрибувати за певним промптом і також передавати усю транскрипцію у «домашній» акаунт.

І далі штучний інтелект сервіса транскрибації робить те, що раніше робив проектний менеджер:

формує резюме дзвінка
витягує домовленості
виділяє задачі
формує список наступних кроків

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

Наступні кроки

• Галина:

Надіслати Світлані інструкції з реалізації UTM-міток для розробника вебсайту.
Дослідити та надіслати інструкції з налаштування Unitalk ATS для передачі UTM-міток.
Створити шаблон контакту Партнер та розробити процес управління партнерами.
Побудувати індивідуальний маркетинговий планувальник для Світлани.
Завершити всі конфігурації до наступної середи.

• Світлана:

Додати всі поточні маркетингові джерела до довідника Джерело.
Надати Галині список стандартних партнерських активностей (наприклад, вебінари, статті).
Обговорити бюджет на базу знань з керівництвом.

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

У якийсь момент я зрозумів, що можу зібрати всі точки дотику з клієнтом в одну модель:

чат-комунікація
дзвінки
задачі і їх статуси
логування часу розробниками

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

Це місце, де акумулюється і консолідується вся інформація:

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

Далі процес виглядає так:

Дані автоматично накопичуються протягом дня
Зранку вся ця інформація передається на аналіз ШІ
Штучний інтелект формує звіт по проєкту за попередній день

На цьому етапі я фактично отримав те, що хотів - можливість за 5–20 секунд зрозуміти, що відбулося по конкретному проєкту. Але, як це завжди буває, одразу з’являється наступне бажання. Я почав бачити минуле і одразу захотів бачити майбутнє.

‍

Дізнайтеся більше про

можливості та функціонал сервісу,

замовивши безкоштовну демонстрацію

Залиште заявку і ми з вами зв'яжемось

Дякуємо, ваші дані успішно відправлені

Перевірте правильність заповнених даних

3. Трансформація аналітики: від щоденних звітів за «вчора» до Google Gemini та 7-денних ШІ-снапшотів

Коли я почав щоденно отримувати звіти по кожному проєкту, перше відчуття було дуже простим: нарешті з’явилась ясність. Я міг відкрити будь-який проєкт і за 5–20 секунд зрозуміти "що до чого" на проєкті. Це вже було кратно краще, ніж будь-який ручний перегляд чатів і задач. Але дуже швидко з’явилось наступне логічне питання: "Окей, я бачу, що було вчора, а що має відбутися сьогодні?"

І тут стало зрозуміло, що звіт, який дивиться тільки в минуле — обмежений. Він дає розуміння, але не дає управління. Я почав експериментувати з промптами, як додати в цей звіт ще один блок - Конкретні наступні кроки. Не просто список задач, як у минулій частині, а чітку відповідь: "Хто що має зробити? До якого дедлайну? З яким очікуваним результатом? Причому важливо було бачити не тільки свою команду а й клієнта.

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

З’явилась можливість бачити:

зону відповідальності команди
зону відповідальності клієнта
конкретні точки, де може зупинитись рух

Окремим етапом став сам процес передачі цієї акумульованої інформації до АІ. І тут не було «одного правильного рішення» з першого разу.Маємо власнонаписані інтеграції з агентами основних гравців ринку AI - Open AI, Google Gemini, Cloude. Біль детально про них ви можете почитати на сторінках цих продуктів.

Спочатку система була побудована на базі OpenAI, ми кілька разів змінювали моделі, пробували різні підходи до структурування і передачі даних. Але досить швидко вперлися в економіку: при приблизно 30+ активних проєктах щоденний аналіз коштував близько $5. Звучить не критично, але якщо дивитися на це як на постійну операційну витрату - воно перестає бути виправданим, особливо якщо додаткова цінність від цього аналізу не кратна витратам.

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

Зараз ми використовуємо Google Gemini як основну модель для аналізу, і з точки зору вартості це стало прийнятним рішенням при великому обсязі даних. Але важливіше навіть не це. Найбільше часу пішло не на інтеграцію, а на підбір правильного промпта. Перші результати були нестабільні: дані повертались у «сирому» вигляді, без чіткої структури, і не давали управлінської цінності. Довелось пройти через серію ітерацій, щоб отримати стабільний формат звіту, який щодня відповідає на ті самі питання і дає однакову якість. І тільки після цього система почала реально масштабувати роботу. Один проектний менеджер отримав можливість вести не 2–3 проєкти, що є фізичною нормою, а 20–30, не втрачаючи контроль над ситуацією.

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

Ці дані автоматично, кожного ранку, відправляються на аналіз до AI. Штучний інтелект видає структурований звіт по тому, що відбувалося на проєкті за вчора.

Іншими словами - я опинився з тим, що щоденно в мене є в активній фазі від 15 до 25 проєктів, і від 15 до 25 звітів в хроніках проєктів. Це багато даних, це дуже багато даних. Нижче наведу вам один з прикладів таких звітів:

Приклад щоденного AI-звіту по проєкту:

1. Кількість активних завдань: 1

2. Активність команди ProcessFather: Активність з боку PF присутня.

3. Активність клієнта: Активність з боку клієнта присутня. Клієнт проактивно реагував на запити, уточнював деталі та оперативно організував дзвінок з менеджерами для надання доступів.

4. Зміни статусів завдань: Створено нове завдання Дзвінок від 16.07 | TN: 70708 PSTN: 65828: Нове -> Оцінка -> Узгодження -> В роботі -> Виконане.

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

6. Наступні кроки:

• На 17.04.2026 до 18:00 — Наталія (Клієнт): Надати список менеджерів з особистими email для завершення налаштування користувачів.

• На 17.04.2026 до 18:00 — Наталія (Клієнт): Скоординувати сесію з Антоном для підключення Instagram-акаунту kaminin_odesa.

• На 18.04.2026 до 18:00 — Віталій: Завершити підключення соцмереж та поштових акаунтів після отримання необхідної інформації від клієнта.

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

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

Це дало зовсім іншу якість результату де АІ почав бачити не просто події, а тренд:

активність падає чи росте
є прогрес чи топтання на місці
клієнт включений чи випадає з процесу

Але навіть після цього залишалась одна проблема про розвʼязання якої я розкажу у наступній частині.

4. Панель приладів Project Manager: PMP-теги та автоматичний «Світлофор» контролю ризиків

Коли в системі з’являється багато даних — це ще не означає, що з’являється контроль. Навпаки, є ризик потонути в деталях. Саме тому паралельно з побудовою аналітики я прийшов до простого, але дуже важливого рішення: дати проєктному менеджеру можливість бачити стан проєктів буквально за кілька секунд у його робочому просторі. Так з’явились теги PMP (Project Management Process) процесу. Їхня задача — не аналізувати, а миттєво підсвічувати ситуацію. Це своего роду як "панель приладів водія" у автомобілі.

Ось набір тегів, який ми використовуємо:

Активна фаза
Пінгонyти
Чекаю на відповідь
Чекаємо певну інформацію від клієнта
Запланувати дзвінок
Активний без розробки
Без активності клієнта від 1 дня до 5 днів
Активність від 1 дня до 3 днів
Без нашої активності від 1 дня до більше тижня
БЛОКЕР

Ці теги призначаються проєктам автоматично через AI, на основі тих самих даних, які ми вже збираємо та щоденно аналізуємо: чатів, дзвінків, статусів задач, логів часу. І тут народився ще один рівень — світлофор для PM.

Ми не просто дивимось на окремі теги, а групуємо проєкти по категоріям, які критично важливі саме для нас:

Без активності клієнта в активній фазі
Ми не активні більше 2 днів
Втрачаємо активність клієнта

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

👉 де треба писати клієнту

👉 де треба підштовхнути команду

👉 де є ризик зупинки

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

‍

Що далі?

На цьому етапі у нас вже були:

щоденні звіти по проєктах
структурована історія за 7 днів
теги РМР і світлофор
повна аналітика по комунікації

Але залишалась проблема, яка не вирішувалась — Стендапи.

Здавалося б, коли вся операційка оцифрована, а ШІ щодня видає точні зрізи та світить ризики, щоденні синхронізації мали б проходити за 5 хвилин. Але в реальності стендапи продовжували зжирати ресурс команди і PM.

У наступній, фінальній статті нашого циклу ми детально розкажемо, як ми навчили ШІ повністю автоматизувати стендапи та чому ми остаточно відмовилися від звичних живих зідзвонів. Стежте за оновленнями!

‍

----------------

Микола Малий