Як припинити витрачати час на фіксацію підсумків після дзвінків і зробити так, щоб протокол та завдання з’являлися в ПланФіксі самі?

Про це детально розповідає Максим Ткаченко — засновник CRMCUSTOMS, який уже 10 років займається впровадженням ПланФікса. У статті він ділиться готовою зв’язкою системи із сервісом MeetLogNet. Головна фішка рішення — ШІ сам розуміє контекст розмови, обирає потрібну роль (бізнес-аналітика чи проджект-менеджера), збирає резюме та одразу формує завдання в картці.

Передаю слово Максиму!

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

Розкажу, як ми зробили так, щоб після кожної зустрічі з клієнтом підсумок і задачі з’являлися в ПланФіксі самі. І головне — покажу, як це налаштувати в себе.

Завдання

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

І зустрічі ці різнопланові.

Є кваліфікаційні — перша розмова з клієнтом, де ми з’ясовуємо, чи допоможемо одне одному взагалі.

Є зустрічі проєктування — коли вже домовилися і треба спроєктувати майбутній застосунок або скласти план впровадження.

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

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

Як ми це вирішували

Спершу робили як усі — руками. Після зустрічі хтось сідав і переносив домовленості в ПланФікс: підсумок коментарем, задачі в чекліст. На папері хвилин двадцять, на практиці — або ввечері, коли половина деталей вивітрилась, або ніколи.

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

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

Тому пішли іншим шляхом: один промт, а розгалуження прописане всередині нього звичайними словами.

Спочатку сам визнач тип зустрічі з контексту розмови.

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

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

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

Так з’явився MeetLogNet — сервіс, який проводить зустріч і сам віддає результат у ПланФікс. Далі — як це налаштувати.

Як налаштувати в себе

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

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

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

Крок 1. Щоб посилання на зустріч створювалось саме

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

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

Цікаве починається в дії сценарію: ми звертаємось до MeetLogNet і передаємо йому дані про зустріч.

Передати треба три речі:

• номер задачі — щоб результат зустрічі знав, у яку картку повертатися;
• систему — вказуємо planfix;
• назву зустрічі — сюди ми кладемо тип: «Кваліфікаційна», «Проєктування», «Поточна». Потім по назві одразу видно, що це була за розмова.

Окремо — авторизація. У заголовках запиту передаємо токен: Authorization: Bearer <ваш токен>. Сам токен і готовий приклад запиту лежать у кабінеті MeetLogNet, у секції «CRM-цикл».

Крок 2. Розібрати відповідь

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

Відповідь від MeetLogNet проста: у ній приходить готове посилання на зустріч. Лишається вказати, у яке поле картки його покласти.

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

Крок 3. Вебхук, який дописує результат у задачу

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

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

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

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

І одразу застереження

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

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

Що вийшло

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

Що це дало на практиці:

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

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

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

Про що варто знати заздалегідь

Щоб не було завищених очікувань, три чесні речі.

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

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

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

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

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

---

Залишилися питання? Пишіть нам у Службу підтримки. Ми з радістю відповімо на всі ваші запитання. Покращуйте свої робочі процеси за допомогою Planfix.