Месенджер у компанії зазвичай зʼявляється як місце для спілкування, а за рік перетворюється на місце для всього: туди кидають рахунки, скриншоти помилок, голосові, меми, договори та фразу «подивися, будь ласка, терміново». Інформація в ньому тече, але тече як вода в підвалі після потопу: всюди й нікуди. І тут виникає цікаве питання. Якщо люди однаково живуть у чаті, чому б не зробити чат не болотом, а нервовою системою компанії?
Цей підхід називається ChatOps, і за модним словом стоїть дуже проста ідея. Важливі події з усіх систем компанії надходять туди, де люди й так перебувають, у зрозумілому вигляді й у потрібний канал. А частину дій можна виконати просто звідти, не відкриваючи пʼять різних вкладок.
Компанія як організм
Уявіть організм, у якого є руки, ноги, очі й вуха, але немає нервів. Рука обпеклася, а мозок дізнається про це з щотижневого звіту. Звучить абсурдно, але саме так працює багато компаній. Клієнт оплатив замовлення, а менеджер дізнається про це, коли випадково заходить у банк-клієнт. Сервер упав о третій ночі, а дізнаються про це вранці від злого клієнта. Новий лід прийшов із сайту в пʼятницю ввечері й пролежав до понеділка, охолонувши, як учорашній чай.
Інтеграція сервісів у спільний чат це і є нерви. CRM, платіжна система, сайт, трекер задач, репозиторій коду, моніторинг серверів: кожен із них уміє надсилати події. Завдання в тому, щоб ці сигнали надходили туди, де їх побачать і де на них відреагують, а не складалися в окремі поштові скриньки, які ніхто не відкриває.
Що саме варто надсилати в чат
Найчастіша помилка, яку я бачу: компанія підключає інтеграції й надсилає в чат геть усе. За тиждень канал перетворюється на водоспад сповіщень, люди його вимикають, і ми повертаємося до вихідної точки, тільки з відчуттям, що «автоматизація не працює». Нервова система, яка постійно кричить від болю, так само марна, як і її відсутність.
Тому правило просте: у чат ідуть лише події, на які хтось має відреагувати або які комусь важливо знати просто зараз. З моєї практики добре працюють такі:
- нова заявка чи лід із сайту, одразу в канал відділу продажів, із контактами та джерелом;
- надходження оплати, у канал фінансів і відповідальному менеджерові;
- падіння сайту чи помилка на сервері, у технічний канал, із посиланням на лог;
- задача, яка прострочена або застрягла в одному статусі довше, ніж зазвичай;
- новий відгук клієнта, особливо негативний;
- щоденне зведення: скільки лідів, скільки оплат, що зроблено командою, зібране ботом в одне повідомлення.
А от що в чат краще не надсилати: кожен коміт, кожну зміну статусу задачі, кожен вхід користувача в систему. Це шум. Для шуму є журнали й дашборди, куди дивляться за потреби.
Від сповіщень до дій
Перший рівень ChatOps це сповіщення. Другий, значно цікавіший, це дії просто з чату. Бот надсилає повідомлення «нова заявка від клієнта», а під ним кнопки «взяти в роботу» і «передати колезі». Менеджер натискає кнопку, у CRM автоматично призначається відповідальний, клієнтові йде лист, а в каналі видно, хто взяв заявку. Ніхто не відкривав CRM, а процес пройшов повністю.
Те саме з погодженнями. Рахунок на оплату підрядникові надходить у канал керівника, він натискає «погодити», і бухгалтерія отримує задачу на оплату. Відпустка співробітника, закупівля, публікація статті: безліч дрібних процесів, які раніше вимагали листа, дзвінка й нагадування за три дні, вкладаються в одну кнопку.
Тут важливо не перегнути. Чат добрий для коротких рішень «так чи ні», але поганий для складної роботи з даними. Якщо для дії треба заповнити десять полів і переглянути історію, це робиться в системі, а чат дає на неї посилання. Чат це нерви й рефлекси, а не мозок. Мозок компанії живе в її обліковій системі.
Як це влаштовано технічно і скільки коштує
Добра новина: здебільшого нічого складного. Майже всі сучасні сервіси вміють надсилати вебхуки, тобто сповіщення про події на задану адресу. Telegram, Slack і більшість корпоративних месенджерів дозволяють створити бота за кілька хвилин. Між ними потрібен прошарок: невеликий сервіс, який приймає події, вирішує, кому й у якому вигляді їх надіслати, і за потреби виконує дії в інших системах.
Для простих звʼязок вистачає конструкторів на кшталт Make чи n8n. Для серйозних процесів, де важливі надійність, права доступу й бізнес-логіка, краще писати власний невеликий сервіс інтеграцій. Він дорожчий на старті, але не ламається, коли конструктор змінив тарифи, і не розсипається, коли кількість подій зросла вдесятеро.
У нас в Ingello значна частина внутрішніх процесів живе саме так. Бот повідомляє про нові заявки із сайтів, публікує звіти про роботу автоматизацій, попереджає, якщо щось зламалося вночі. Я дізнаюся про проблеми раніше, ніж клієнт устигає їх помітити. Це не магія, це просто нерви, проведені до потрібних органів.
Підводні камені
Перший: безпека. У чат не мають потрапляти паролі, повні дані карток і персональні дані клієнтів понад необхідне. Месенджер не сейф, і доступ до нього буває в ширшого кола людей, ніж Ви думаєте.
Другий: залежність від одного каналу. Якщо вся компанія реагує тільки через чат, падіння месенджера паралізує роботу. Критичні сповіщення варто дублювати, наприклад, поштою чи SMS.
Третій: розмита відповідальність. Повідомлення в спільному каналі бачать усі, і тому часто не реагує ніхто. Кожна подія має мати конкретного адресата або правило, хто її бере. Інакше вийде відомий ефект свідка: тридцять людей бачили, що сервер упав, і кожен був певен, що ним уже хтось займається.
З чого почати
Випишіть три події у Вашій компанії, про які Ви дізнаєтеся надто пізно. Зазвичай це нові заявки, оплати й аварії. Підключіть саме їх, кожну у свій канал і з конкретним відповідальним. Поживіть так місяць, подивіться, що справді допомагає, а що перетворилося на шум, і лише потім додавайте наступне.
Якщо Ваші процеси вже живуть в обліковій системі на кшталт Forma, інтеграції з чатом підключаються поверх неї, і бот стає голосом системи, а не окремою самодіяльністю. Якщо ж облікової системи немає, чат-бот не врятує: нервам треба кудись вести. Але почати з них можна вже завтра, і ефект буде помітний із першої ж заявки, яка не пролежала вихідні.
