Зустріч закінчилась — і почалась друга робота. Як ми прибрали ручний конспект із процесу

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Мене звати Максим Ткаченко, десять років я впроваджую CRM для українського бізнесу. Останній рік ми з командою будували власний сервіс для зустрічей: відеозустріч у браузері, автоматичний транскрипт, AI-підсумок і задачі, які повертаються назад у картку клієнта. Я не розробник — я той, хто бачить, як бізнес втрачає домовленості між дзвінком і CRM.

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

«Який звіт?»

Через тиждень після дзвінка я пишу в чат: «Звіт готовий?» — і отримую: «Який звіт?»

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

Стандартний ланцюжок виглядає так: запис → транскрипт → summary → задача → трекер. П’ять переходів, і на кожному щось губиться. Не тому, що інструменти погані, а тому що людина в цьому ланцюжку — єдиний клей. А клей закінчується після третього дзвінка за день.

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

Чотири рішення, які визначили продукт

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

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

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

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

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

Що відбувається після дзвінка

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

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

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

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

Головне: зустріч, яка сама пишеться в картку угоди/проекту

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

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

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

В нашому тестовому Планфікс можна налаштувати створення задач чеклістом в угоді. Можна створювати підзадачі на конкретних співробітників. Усе залежить від можливостей вашої системи.

Куди все це їде: про інтеграції

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

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

Універсальний конектор. Механіка не прив’язана до PlanFix: будь-яка система з вхідними вебхуками підключається так само, а мапінг полів налаштовується на нашому боці. Тобто якщо у вашій CRM підсумок має лягти в одне поле, а задачі в інше з іншими назвами, переписувати нічого не треба — просто вказуєте відповідність.

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

Задачники й месенджери. Задачі їдуть у Notion і Trello, підсумок — у Slack, у Telegram або на пошту. Плюс універсальний вебхук із підписом, тобто будь-який сценарій у Make чи n8n.

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

Де ми боляче помилились

Тепер про граблі, бо без них картина буде нечесною.

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

Урок, який я забрав як не-технар: «процес завершився без помилок» і «процес зробив те, що треба» — різні речі. Перевіряти треба результат, а не статус.

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

А далі почалось найцікавіше.

Як AI вигадав зустріч, якої не було

Whisper отримав майже порожнє аудіо — і дописав за нього. У транскрипті з’явилось «Продолжение следует». Іншого разу — «Дякую за перегляд». Це відома поведінка: модель натренована на величезному масиві відео, і на тиші впевнено генерує те, чим такі відео закінчуються.

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

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

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

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

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

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

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

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

Універсальний AI-підсумок обидві ці зустрічі перемелює в однакову кашу: «обговорили, домовились, вирішили». Тому ми зробили промт налаштовуваним — і тут з’явився вибір із двох підходів.

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

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

КРОК 1. САМ ВИЗНАЧ ТИП ЗУСТРІЧІ з контексту розмови.

ТИП A — ПЕРША ЗУСТРІЧ З КЛІЄНТОМ. Ознаки: знайомство, клієнт
розповідає про свій бізнес і процеси, звучать питання про терміни
й вартість. Немає посилань на раніше поставлені задачі.

ТИП B — РОБОЧА ЗУСТРІЧ ПО ПОТОЧНИХ ЗАДАЧАХ. Ознаки: статуси,
«зробив», «не встиг», посилання на попередні домовленості.

КРОК 2. ЗМІНИ РОЛЬ.

ЯКЩО ТИП A — ти БІЗНЕС-АНАЛІТИК. Не переказуй розмову, а зафіксуй
задачу так, щоб її можна було оцінити: що хоче клієнт його словами,
чернетка технічного завдання, відкриті питання.

ЯКЩО ТИП B — ти ПРОДЖЕКТ-МЕНЕДЖЕР. Створи задачі присутнім,
з відповідальними й термінами. Окремо — що не зроблено і чому.

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

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

Два спостереження з практики, які зекономлять вам час.

Обов’язково потрібна третя гілка — «інше». Без неї на нетиповій зустрічі модель силою натягує одну з двох ролей і вигадує або технічне завдання, або задачі, яких не було.

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

Кому це підходить, а кому поки ні

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

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

Поки не підходить компаніям, яким для роботи з підрядником потрібні формальні сертифікації відповідності — ми їх не проходили. Тим, кому потрібен саме відеозапис зустрічі, а не звук із транскриптом. І тим, хто принципово не готовий переносити зустрічі зі звичного Zoom: ми не бот до чужого дзвінка, ми окрема платформа, і це свідомий вибір.

Що я з цього виніс

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

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

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

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

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