Від хаосу в Telegram до AI-асистентів у CRM: як ми повернули операційний контроль над десятками проєктів

Чому Telegram-чати вбивають контроль у сервісному бізнесі

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

Клієнт створює Telegram-групу, додає туди своїх співробітників, ви додаєте своїх — і здається, що питання комунікації закрите. Є один чат, де обговорюється все: задачі, правки, питання, уточнення. На старті це виглядає як максимально просте і зручне рішення.

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

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

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

Але ключова проблема навіть не в цьому. Проблема в тому, що така модель повністю позбавлена керованості.

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

І чим більше у вас проєктів, тим швидше ця система перестає працювати.

Як ми перенесли всю комунікацію в Planfix (і що це реально дало)

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

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

Фактично, клієнт як писав у чат, так і продовжує писати. Але для нас це вже не просто повідомлення — це структурована задача в системі. І саме тут починається різниця:

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

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

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

Чому навіть впорядкована система перестає давати контроль

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

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

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

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

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

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

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

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

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

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

Як ми почали будувати AI-звіт: від питань до системи

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

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

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

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

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

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

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

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

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

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

Але історично це була проблема. Запис дзвінка — це просто файл. Щоб витягнути з нього користь, його потрібно передивлятись або робити нотатки вручну. Це займає час і з’їдає ресурс як проєктного менеджера, так і розробника.

Рішення з’явилось тоді, коли стали доступними нормальні сервіси транскрибації. Ми почали обовʼязково записувати всі дзвінки, далі автоматично їх транскрибувати за певним промптом і також передавати усю транскрипцію у «домашній» акаунт.

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

Підписуйтеся на наші соцмережі

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

Приклад структурованого результату дзвінка:

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

Галина:

Світлана:

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

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

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

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

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

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

Як звіт про «вчора» перетворився на систему управління «сьогодні»

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

І тут стало зрозуміло, що звіт, який дивиться тільки в минуле — обмежений. Він дає розуміння, але не дає управління.

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

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

Після кількох експериментів із формою та змістом блоку наступних кроків картина сильно змінилась. З’явилась можливість бачити:

Окремим етапом став сам процес передачі цієї акумульованої інформації до AI. І тут не було «одного правильного рішення» з першого разу.

Маємо власнонаписані інтеграції з агентами основних гравців ринку AI — OpenAI, Google Gemini, Claude.

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

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

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

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

І тільки після цього система почала реально масштабувати роботу. Один проєктний менеджер отримав можливість вести не 2–3 проєкти, що є фізичною нормою, а 20–30, не втрачаючи контроль над ситуацією.

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

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

Ось один із реальних прикладів таких щоденних звітів:

Plaintext

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 днів: комунікацію, дзвінки, статуси задач, логи часу — всі точки дотику, розкладені по днях. Це дозволило отримувати значно більш релевантний звіт, який показує не просто факт подій, а їх динаміку, і який повністю закриває мою потребу як операційного менеджера.

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

PMP як інструмент швидкого управління: теги та світлофор

Коли в системі з’являється багато даних — це ще не означає, що з’являється контроль. Навпаки, є ризик потонути в деталях.

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

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

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

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

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

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

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

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

Хроніка розробника: як ми перезібрали стендапи і отримали контроль

Стендапи в нас проходять три рази на тиждень: понеділок, середа, п’ятниця. В середньому 20–30 хвилин. І формально це мав бути класичний стендап: Що робив? Що буду робити? Які є проблеми чи блокери?

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

Як би ми не крутили формати, стендап — це не про проєкти. Це про людей.

А ми намагались керувати стендапом через «хроніки проєктів». І тут виникало одразу кілька проблем: у кожного розробника було по кілька проєктів (від 2 до 5), на виступ відводилось лише 2–3 хвилини, і за цей час потрібно було встигнути буквально все — паралельно відкривати різні звіти по різних проєктах, швидко пробігатися по них очима, слухати, що саме говорить розробник, співставляти це з фактичними даними і ще формулювати уточнюючі питання.

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

І це не масштабувалося.

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

Я сформулював для себе чіткий список того, що хочу бачити ДО чи ПІД ЧАС стендапу:

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

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

І тут важливо не описувати, а показати, як це виглядає на практиці:

Аналіз діяльності розробника ХХХХ ХХХХХ на 15-04-2026 05:56.

0. Аналіз залогованого часу:

- Сумарний час:

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

- Погодинний розподіл (Поточний Період):

1. Що було зроблено розробником у звітний період (13.04 — 14.04)

У Попередній Звітний Період (10.04) було завершено 2 задачі по проєкту ХХХХХ та передано на Тестування ключову задачу по ХХХХХ. У Поточний Звітний Період (13.04 — 14.04) активність була переважно реактивною. Основною дією стало оперативне вирішення блокуючої проблеми з доступом до довідника по проєкту ХХХХХ вранці 14.04, що дозволило клієнту продовжити роботу. Також було взято на Оцінку нову задачу щодо спам-заявок (№70557) у цьому ж проєкті. Інша активність була пов'язана з комунікацією та переплануванням дзвінків (ХХХХХ, ХХХХХ). Загалом, зафіксовано зміну статусу по 1 задачі та вирішення 1 критичної проблеми.

 У Поточний Звітний Період (13.04 — 14.04) активність була переважно реактивною. Основною дією стало оперативне вирішення блокуючої проблеми з доступом до довідника по проєкту ХХХХХ вранці 14.04, що дозволило клієнту продовжити роботу. Також було взято на Оцінку нову задачу щодо спам-заявок (№70557) у цьому ж проєкті. Інша активність була пов'язана з комунікацією та переплануванням дзвінків (ХХХХХ, ХХХХХ). Загалом, зафіксовано зміну статусу по 1 задачі та вирішення 1 критичної проблеми.

2. Проблеми та ризики - Масове блокування з боку клієнтів: — ХХХХХ: Проєкт повністю заблоковано через несплату клієнтом акаунту Planfix, що унеможливлює продовження будь-яких робіт. — ХХХХХ: Проєкт повністю заблоковано з 17.02 через відсутність дій від клієнта. — ХХХХХ: Дві задачі (№69450, №69710) заблоковані через очікування уточнень від клієнта. - Внутрішні залежності: — ХХХХХ: Критична задача по кнопці «Закрити» заблокована з боку іншого члена команди (ХХХХХ ХХХХХ), що гальмує тестування та посилює незадоволення клієнта. - Технічний борг та протерміновані задачі: — ХХХХХ: Дві ключові задачі («Синхронізація товарів та цін» та «Налаштувати мультивалютність») є протермінованими (дедлайни 31.03 та 03.04 відповідно). Це створює значний технічний борг. - Накопичення роботи: На розробника заплановано величезний обсяг роботи на сьогодні та наступні дні по проєкту ХХХХХ (3 звіти, виправлення логіки, роз'яснення), що створює ризик перевантаження.

3. Аналіз завантаженості на сьогодні (15.04.2026) На поточний момент у ХХХХХ заплановано значний та різноплановий обсяг роботи: 1. ХХХХХ: Провести дзвінок з клієнткою (о 15:00). 2. ХХХХХ: — Надати клієнту роз'яснення щодо логіки заповнення ПІБ в ТТН (№69658). — Проаналізувати та виправити логіку синхронізації статусів з Prom (в рамках №69910). — Завершити роботу над звітом «Маркетинг — динаміка по місяцях». — Реалізувати звіт «Місячний оборот продажів (факт оформлення)» (№69696). 3. ХХХХХ: Проаналізувати та надати рішення по завданню «Чому тут статус лід?» (№70535). Оцінка: Навантаження є надзвичайно високим та нереалістичним. Проведення важливої зустрічі о 15:00 та одночасне виконання трьох великих технічних/аналітичних завдань і двох звітів по кризовому проєкту ХХХХХ протягом одного дня є неможливим і несе високий ризик зниження якості.

4. План роботи на сьогодні 1. Пріоритет 1 (до 15:00): ХХХХХ — Підготуватися та провести заплановану зустріч з клієнткою, оскільки це ключова подія для розблокування проєкту. 2. Пріоритет 2: ХХХХХ — Надати роз'яснення клієнту по логіці заповнення ПІБ (№69658), оскільки це комунікаційне завдання, що може швидко розблокувати питання. 3. Пріоритет 3: ХХХХХ — Розпочати аналіз та виправлення логіки синхронізації статусів з Prom, оскільки це впливає на операційну роботу клієнта. 4. Фонові задачі: Робота над великими звітами по ХХХХХ та аналіз задачі по ХХХХХ відкладені через вищу пріоритетність інших завдань.

5. Рекомендації PM 1. Пріоритезація та реалістичність: Негайно узгодити з ХХХХХ пріоритети на сьогодні. Оцінити, який мінімальний обсяг роботи по ХХХХХ має бути виконаний сьогодні, та офіційно перепланувати решту завдань (особливо звіти), щоб уникнути перевантаження. 2. Управління кризою: Сконцентрувати увагу на проєкті ХХХХХ. Великий потік нових завдань та повернення в роботу старих вимагає перегляду пріоритетів разом з клієнтом, щоб керувати його очікуваннями та стабілізувати ситуацію. 3. Розблокування (внутрішнє): Втрутитися та забезпечити надання рішення по критичній задачі (кнопка «Закрити») в ХХХХХ з боку іншого члена команди, оскільки це внутрішній блокер, що гальмує проєкт. 4. Розблокування (зовнішнє): Продовжувати моніторинг тривалих блокерів по проєктах ХХХХХ (простій з 17.02) та ХХХХХ (несплата акаунту), оскільки вони потребують ескалації. 5. Управління технічним боргом: Запланувати виконання протермінованих завдань по проєкту ХХХХХ на найближчий час, щоб уникнути їх подальшого накопичення.

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

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

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

Що далі?

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

Саме з цього моменту хочеться рухатися далі — у сторону автоматизації не тільки аналітики, а й дій. Зараз я працюю над наступним кроком — автоматизацією організації дзвінків: як тільки в чаті з’являється потреба узгодити зустріч, система сама перевіряє календарі всіх учасників, пропонує вільні слоти, бронює час, генерує Zoom-посилання і відправляє його клієнту, плюс нагадує про дзвінок — повністю без участі людини. І це не просто допоміжний інструмент, це перехід до системи, яка починає брати на себе частину операційного управління.

І, якщо чесно, саме тут стає по-справжньому цікаво — тому що межа між «інструментом» і «операційним менеджером» починає розмиватись.

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

Справжня цінність з’являється лише там, де є глибока інтеграція — в процеси, в дані, в CRM-ERP систему, в контекст і нюанси. Там, де агент не просто виконує команду, а глибоко інтегрований в ядро бізнес-процесів і дійсно допомагає співробітникам краще виконувати свою роботу, а компанії масштабуватись.

Саме там я бачу майбутнє моєї компанії і саме там я хотів би опинитись.