Три типи зустрічей — один процес: як ми налаштували Planfix, щоб протоколи писались самі
Як припинити витрачати час на фіксацію підсумків після дзвінків і зробити так, щоб протокол та завдання з’являлися в Planfix самі?
Про це детально розповідає Максим Ткаченко — засновник CRMCUSTOMS, який уже 10 років займається впровадженням Planfix. У статті він ділиться готовою зв’язкою системи із сервісом MeetLogNet. Головна фішка рішення — ШІ сам розуміє контекст розмови, обирає потрібну роль (бізнес-аналітика чи проджект-менеджера), збирає резюме та одразу формує завдання в картці.
Передаю слово Максиму!
CRMCUSTOMS — впроваджуємо Planfix українському бізнесу. Не тільки налаштовуємо клієнтам, а й самі в ньому живемо: угоди, проєкти, завдання, документи. Мене звати Максим Ткаченко, десять років у впровадженнях.
Розкажу, як ми зробили так, щоб після кожної зустрічі з клієнтом підсумок і завдання з’являлися в Planfix самі. І головне — покажу, як це налаштувати в себе.
Завдання
В роботі інтегратора, як і в будь-якій проєктній роботі, доводиться багато говорити. Дуже багато. Зустріч — це основний робочий інструмент: поки не поговориш із людиною кілька разів, нічого їй не впровадиш.
І зустрічі ці різнопланові.
- Є кваліфікаційні — перша розмова з клієнтом, де ми з’ясовуємо, чи допоможемо одне одному взагалі.
- Є зустрічі проєктування — коли вже домовилися і треба спроєктувати майбутній застосунок або скласти план впровадження.
- І є поточні — де обговорюємо проблеми, що виникли по ходу, й окреслюємо завдання.
Тому просто сервіс для запису зустрічей нам не підходив. Потрібне було рішення, яке не просто запише розмову й наріже завдання, а спершу визначить, що це була за зустріч — і залежно від типу зробить різне. З кваліфікаційної — виписати бізнес-вимоги замовника. З поточної — нарізати завдання й поставити нагадування.
Як ми це вирішували
Спершу робили як усі — руками. Після зустрічі хтось сідав і переносив домовленості в Planfix: підсумок коментарем, завдання в чекліст. На папері хвилин двадцять, на практиці — або ввечері, коли половина деталей вивітрилась, або ніколи.
Технічна частина виявилася простішою за смислову. Доставити текст у Planfix — не проблема. Проблема в тому, щоб з кваліфікаційної зустрічі приходило одне, а з поточної зовсім інше.
Перше рішення напрошувалося саме: зробити кілька шаблонів підсумку й перемикати активний перед дзвінком. Ми так і зробили — і майже одразу перестали цим користуватися. Перемикати щось руками перед кожною зустріччю — та сама рутина, від якої ми тікали.
Тому пішли іншим шляхом: один промт, а розгалуження прописане всередині нього звичайними словами.
Спочатку сам визнач тип зустрічі з контексту розмови.
Якщо це перша зустріч із клієнтом — дій як бізнес-аналітик. Не переказуй розмову, а зафіксуй бізнес-вимоги: що хоче клієнт його словами, чернетка технічного завдання, відкриті питання.
Якщо це робоча зустріч по поточних завданнях — дій як проджект-менеджер. Створи завдання присутнім, з відповідальними й термінами, і постав нагадування на дати, що прозвучали.
Модель сама визначає тип із контексту й перемикає роль. Ніхто нічого не обирає руками. Порада з практики: обов’язково пропишіть третю гілку — «інше». Без неї на нетиповій зустрічі модель силою натягує одну з двох ролей і вигадує або технічне завдання, або завдання, яких не було.
Так з’явився MeetLogNet — сервіс, який проводить зустріч і сам віддає результат у Planfix. Далі — як це налаштувати.
Як налаштувати в себе
Важливий момент. Далі я показую, як налаштовано в мене. Але бізнес-процес у вас майже напевно інший, тому все, що не стосується інтеграції напряму, я свідомо опускаю — інакше це перетвориться на опис мого впровадження, а не на інструкцію.
Один приклад такого «свого» все ж згадаю, бо він впливає на схему. Перед тим як створювати посилання, я створюю підзавдання з типом об’єкта «Зустріч». Тобто на кожну зустріч заводиться окреме завдання — і саме в нього потім падають саммарі та завдання з розмови.
Навіщо: зустрічей у межах одного проєкту в мене багато. Якби все злітало в одну картку проєкту, вона за місяць перетворилася б на нечитабельну стрічку. А так кожна розмова має своє завдання, і видно, що саме на ній вирішили. Саме номер цього підзавдання я і передаю в MeetLogNet.
Крок 1. Щоб посилання на зустріч створювалось саме
Перше, що налаштовуємо, — генерацію посилання на зустріч із боку Planfix. Це може бути кнопка в картці, а може бути сценарій.
У мене сценарій: він реагує на заповнення дати й часу зустрічі й спрацьовує щоразу, коли це поле змінюється. Як зробити елементарний тригер, розписувати не буду — умова там проста.
Цікаве починається в дії сценарію: ми звертаємось до MeetLogNet і передаємо йому дані про зустріч.
Передати треба три речі:
- номер завдання — щоб результат зустрічі знав, у яку картку повертатися;
- систему — вказуємо planfix;
- назву зустрічі — сюди ми кладемо тип: «Кваліфікаційна», «Проєктування», «Поточна». Потім по назві одразу видно, що це була за розмова.
Окремо — авторизація. У заголовках запиту передаємо токен: Authorization: Bearer <ваш токен>. Сам токен і готовий приклад запиту лежать у кабінеті MeetLogNet, у секції «CRM-цикл».
Крок 2. Розібрати відповідь
І тут головне — не забути поставити галочку «Налаштувати розбір відповіді». Без неї сценарій просто відправить запит і викине відповідь, а посилання на зустріч так і не з’явиться в картці. Виглядатиме так, ніби нічого не працює, хоча запит пішов і сервіс чесно відповів.
Відповідь від MeetLogNet проста: у ній приходить готове посилання на зустріч. Лишається вказати, у яке поле картки його покласти.
Після цього кроку схема вже жива: заповнили дату й час зустрічі — у картці з’явилось посилання, яке можна надсилати клієнту.
Крок 3. Вебхук, який дописує результат у завдання
Тепер другий бік — щоб результат зустрічі повертався в Planfix. Для цього заводимо вхідний вебхук, який змінює завдання, а не створює нове.
Налаштовується так: передаємо всі поля в інфоблоки, вмикаємо режим «Змінити існуюче завдання» і зіставляємо по номеру завдання. Той самий номер, який ми передали на першому кроці, повертається назад — по ньому Planfix і знаходить потрібну картку.
Окремо про завдання з розмови. У запиті вони приходять одразу в кількох форматах — масивом і кількома готовими варіантами рядка. Зроблено це навмисно: у сценарії Planfix зручніше взяти готовий рядок, ніж розбирати масив, а розкладати на чекбокси кожен любить по-своєму. Комусь треба з переносами, комусь через крапку з комою, комусь із виконавцем у дужках. Беріть той, який лягає у ваше поле.
І останнім кроком у цьому ж вебхуку я виставляю статус угоди — «Консультацію проведено». Тобто після зустрічі картка не просто наповнюється змістом, а й сама рушає далі по воронці.
І одразу застереження
Складність моєї інтеграції доволі проста. Ваша може бути настільки складною, наскільки дозволяє фантазія — благо Planfix це дозволяє.
Можна вмикати потрібний промт залежно від типу зустрічі. Можна з дат, що прозвучали в розмові, ставити нагадування прямо в зустріч. Можна створювати не чекбокси, а повноцінні підзавдання з виконавцями. Далі все впирається тільки в те, як у вас влаштований процес.
Що вийшло
Зустріч проходить за посиланням із картки. Клієнт відкриває його в браузері — без реєстрації, без встановлення застосунків. Пишеться звук, після завершення він перетворюється на розшифровку, з неї збирається підсумок і завдання. Через кілька хвилин після дзвінка все це вже в Planfix, у тому самому завданні-зустрічі.
Що це дало на практиці:
Домовленості фіксуються завжди, а не коли дійшли руки. Не «швидше» і не «зручніше», а саме завжди — бо з процесу зникла людина, яка могла забути.
Кваліфікаційна зустріч одразу дає бізнес-вимоги. Раніше після неї лишались нотатки, з яких я потім складав опис завдання. Тепер опис приходить сам, лишається вичитати й доповнити.
Картка проєкту перестала бути порожньою. Через два тижні відкриваю завдання-зустріч і бачу, що саме на ній вирішили, звідки взявся конкретний пункт у чеклісті й хто що обіцяв.
Про що варто знати заздалегідь
Щоб не було завищених очікувань, три чесні речі.
Пишеться тільки звук. Учасники бачать одне одного під час розмови, але в архів іде аудіо, розшифровка й підсумок — відеофайлу не буде.
Зустріч має проходити на платформі сервісу. Це не бот, який заходить сьомим учасником у ваш звичний Zoom. Звідси й вхід за посиланням без реєстрації, але переїжджати зі свого сервісу доведеться.
На тихому записі сервіс відмовиться писати підсумок. Якщо мікрофон не спрацював, замість гарного протоколу прийде чесне «запис майже порожній». Ми вважаємо це правильним: правдоподібна вигадка в картці клієнта небезпечніша за порожнє поле.
Зараз MeetLogNet у відкритій беті: перший місяць повного доступу безкоштовно, замість оплати просимо написати в підтримку, що зламалось і чого бракує.
Якщо у вас процес навколо зустрічей вибудуваний інакше — розкажіть у коментарях, мені щиро цікаво. Свою схему ми збирали під себе, і майже впевнений, що частину рішень варто було зробити інакше.
Залишилися питання? Пишіть нам у Службу підтримки. Ми з радістю відповімо на всі ваші запитання. Покращуйте свої робочі процеси за допомогою Planfix.
