Контроль обліку часу для агенцій

Контроль обліку часу перетворює непомітний відтік виручки на видимий управлінський сигнал.

Агентський бізнес залежить від оплачуваних годин: якщо консультант відпрацював 7 годин, а в таймшиті залишилося 4 — три години розчинилися. AI-агент Grow2.ai читає активність співробітника в робочих системах і щодня показує, де лог часу розходиться з фактом.

Що конкретно робить агент

1. Підключається до трекера задач (Jira, Linear, ClickUp) і збирає події за добу: створення завдань, зміну статусів, коментарі, коміти.
2. Збирає події з календаря (Google Calendar, Outlook): зустрічі з клієнтом, внутрішні сесії, мітинги з рев'ю.
3. Відстежує метадані повідомлень у каналах комунікації (Slack, Teams): автор, час, канал, згадки — без змісту.
4. Зіставляє ці сигнали із записами в інструменті обліку часу (Toggl, Harvest, Clockify).
5. Визначає розбіжність: «З 10:00 до 12:00 ви були на Zoom-зустрічі з клієнтом X і закрили 4 тікети в Jira того ж клієнта, але в таймшиті 0 годин на клієнта X».
6. Надсилає персональний звіт співробітнику наприкінці дня і агрегований тижневий зведений звіт менеджеру наприкінці тижня.

Що агент НЕ робить

• Не пише таймшити за співробітників — рішення про логування залишається за людиною.
• Не замінює інструмент обліку часу — працює поверх наявного (Toggl, Harvest, Clockify).
• Не приймає рішення щодо білінгу клієнта — лише формує сигнали для менеджера.
• Не працює як стеження за клавіатурою/мишею — спирається на бізнес-системи, а не на клік-трекери.
• Не вирішує проблему низької дисципліни культурно — це завдання керівника і процесу.

Типові варіанти налаштування

Solo / 1–5 осіб. Підключення одного трекера задач, одного календаря і одного Slack workspace. AI-агент надсилає повідомлення в особистий Slack DM раз на день: список закритих завдань, проведених зустрічей і нагадування про незалоговані години. Менеджерської звітності немає — співробітник сам бачить свій розрив і закриває його. Підходить фрілансерам, соло-консультантам і мікро-агентствам, де власник суміщає роль керівника проєкту і операційника. Налаштування займає 2–3 дні, підтримка мінімальна.

SMB / 6–30 осіб. Додаються менеджерські інформаційні панелі: тижневий звіт по команді, теплова карта незалогованих годин по клієнтах, алерти при перевищенні порогу (наприклад, розрив більше 4 годин за тиждень). Інтеграція з двома-трьома системами-першоджерелами одночасно: Jira + Google Calendar + Slack. Зазвичай починає окупатися в перший місяць за рахунок відновленого оплачуваного часу. Типовий кейс для маркетингових, дизайн- і розробницьких агентств.

Корпоративний / 30+ осіб. Мультипрофільне налаштування: окремі правила для різних команд, ролей і клієнтських пулів. Інтеграція з SSO, RBAC для менеджерів, журналювання, сумісне з вимогами відповідності, зі зберіганням лише метаданих. Дашборди для операційного відділу, фінансів і офісу керівника проектів. Обов'язкова фаза юридичного аналізу — у ряді юрисдикцій моніторинг активності співробітників регулюється і вимагає повідомлення або згоди.

Як це працює

Архітектура спирається на три шари: збір сигналів → нормалізація та атрибуція → розпізнавання розривів. Кожен шар ізольований і може бути замінений без переписування інших.

Крок 1. Конектори до вихідних систем

Grow2.ai підключає агент до API джерел. Для кожної системи — окремий конектор лише для читання:

1. Трекер задач — Jira REST API, Linear GraphQL, ClickUp API. Забирає події за останні 24 години: створення задач, призначення виконавця, зміну статусу, коментарі, зареєстрований залогований час.
2. Calendar — Google Calendar API, Microsoft Graph для Outlook. Читає події співробітника: початок, кінець, учасники, заголовок, домени запрошених.
3. Комунікації — Slack Events API, Microsoft Teams Graph API. Забирає метадані повідомлень (канал, час, автор, згадки) без вмісту — для відповідності вимогам.
4. Облік часу — Toggl API, Harvest API, Clockify API, Everhour. Основне першоджерело: що вже залоговано.

Крок 2. Нормалізація та атрибуція

Агент приводить події до єдиної часової шкали. Для кожного 15-хвилинного інтервалу формується вектор сигналів: чи була подія в Jira, чи був мітинг, чи була активність у клієнтському Slack-каналі. Потім кожна подія пов'язується з клієнтом або проектом через наявну прив'язку — мітки і компоненти у Jira, теги клієнтів у Linear, домени учасників у Calendar, прив'язку каналів до клієнтів у Slack.

Крок 3. Розпізнавання розривів

LLM аналізує розрив між вектором сигналів і записами обліку часу. Приклади правил:

• О 10:00–11:00 був мітинг із клієнтом X плюс закриті тікети Jira клієнта X, але в Toggl 0 годин на клієнта X — можливий розрив 1 година.
• О 14:00–17:00 кожні 15 хвилин з'являлися коментарі в Jira клієнта Y, але в Toggl 0 годин — потенційний розрив до 3 годин.
• О 9:00–10:00 була зустріч із клієнтським доменом, але в Toggl вона залогована як внутрішня — можлива помилка категоризації.

Крок 4. Зведення та алерти

Щовечора о 18:00 локального часу співробітника агент надсилає персональний звіт у Slack:

Сьогодні зафіксовано активність, не знайдену в таймшиті:- 10:00–11:00 мітинг із клієнтом Acme + 4 тікети Acme в Jira — у Toggl 0 год.- 14:00–16:30 коментарі в каналі #acme-dev — у Toggl 0 год.Оцінка: 3.5 оплачуваних години. Відкрити Toggl: [посилання]

Менеджер отримує тижневий зведений звіт: теплову карту розривів по команді, топ-5 проектів із найбільшим недологуванням, тижневий тренд.

Альтернативні підходи

No-code інструменти (рушій робочих процесів, Zapier) вирішують задачу відсотків на 60: вони вміють «якщо X — надіслати сповіщення», але не вміють «зрозуміти, що згадування клієнта в Slack + тікет у Jira + мітинг у календарі = оплачувана робота». Вендорські таймтрекери закривають частину ланцюга — вони бачать свої логи, але не бачать реальність за їхніми межами. AI-агент покриває розрив між першоджерелом у таймтрекері та реальним станом справ в інших системах.

Безпека та відповідність вимогам

Grow2.ai за замовчуванням зберігає лише метадані подій: timestamps, actors, project IDs. Вміст повідомлень Slack і Teams не потрапляє до пошукового індексу або навчання моделі — агент працює з патернами активності, а не з текстом переписки. Для юрисдикцій із GDPR-режимом (EU, UK) налаштовується зберігання даних в ЄС і термін зберігання 30 днів. Всі API-виклики read-only. Для клієнтів з критичними вимогами відповідності підтримується розгортання мовної моделі через enterprise tier Anthropic з ізольованим контуром даних. Повідомлення співробітників про запуск моніторингу — вимога в багатьох юрисдикціях; Grow2.ai допомагає скласти коректний текст для ознайомлення персоналу, але фінальне рішення щодо відповідності вимогам залишається за юристами клієнта.

Що потрібно для запуску

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

Технічні вимоги

1. Наявний інструмент обліку часу з API. Підтримуються Toggl, Harvest, Clockify, Everhour. Без базової системи логування агенту нема з чим порівнювати.
2. Структурований облік задач. Jira, Linear, ClickUp або GitHub Issues. Задачі мають бути прив'язані до клієнта або проекту через мітки, компоненти або батьківський епік — без цього прив'язування виявлення розривів марне.
3. Робочий календар (Google Calendar або Microsoft Outlook) з послідовною практикою відзначати клієнтські зустрічі: клієнт у списку учасників або префікс у заголовку події.
4. Доступ до Slack або Teams workspace лише для читання. Для Slack потрібен Business+ або Enterprise Grid для Events API.
5. Роль Admin хоча б в одній із систем для налаштування OAuth. Цю роль відіграє CTO, COO або технічний керівник.

Процесні вимоги

1. Бізнес-модель оплачуваних годин. Якщо агентство працює у проектах із фіксованою вартістю без погодинної фіксації — ефект не відчувається. Інструмент оптимізований для T&M та ретейнер-моделей.
2. Згода команди на моніторинг. Без прозорої комунікації — «ми впроваджуємо виявлення розривів у таймшитах, щоб менше втрачати виручку, а не щоб вас контролювати» — автоматизація сприймається як стеження і саботується.
3. Відповідальний за процес. Одна людина (зазвичай керівник операційного відділу або COO), яка переглядає тижневий зведений звіт і вирішує, що робити з повторюваними розривами.

Можливі підводні камені

• Неправильна прив'язка клієнт↔проект у Jira/Linear. Якщо завдання позначені як Внутрішні, хоча робота йде по клієнтському контракту — агент класифікує їх як неоплачувані і розрив не виявляється. Перед запуском потрібен аудит міток.
• Надто агресивні алерти. Звіт кожні 2 години — і команда вимикає сповіщення. Робоча частота — один раз на день увечері плюс тижневе зведення для менеджера.
• Ігнорування юридичного аналізу. У Німеччині, Франції, Іспанії, Польщі та ряді штатів США моніторинг співробітників вимагає письмової згоди або повідомлення працівників. Пропуск кроку — юридичний ризик.
• Впровадження без комунікації. Команда дізнається про агента з першого зведення — типове джерело конфлікту. Потрібен стартовий мітинг і письмова політика до увімкнення.
• Відсутність відповідального за процес. Агент генерує звіти, але ніхто їх не переглядає — через 2 місяці інструмент вимикають з формулюванням «не працює». Призначення відповідального — передумова, а не необов'язковий крок.