Ми автоматизували власну обробку запитів. Окупність за шість тижнів
Перш ніж пропонувати цю послугу комусь, ми побудували її в себе. П’ять годин роботи, два дні тестів, дванадцять звернень за перші два тижні. Нижче: що саме постало, скільки це зайняло, що пішло не так і чесний розрахунок окупності.
Коротка відповідь
Ми автоматизували власний процес обробки запитів, перш ніж пропонувати таку послугу комусь. П’ять годин роботи плюс два дні тестів. Ручна обробка одного звернення забирала 6–10 хвилин.
За перші два тижні через систему пройшло дванадцять звернень. За такого темпу вкладене окупається приблизно за шість тижнів, а за перші два тижні ми вже повернули приблизно третину витраченого часу.
У масштабі року, за того самого потоку, це понад сорок годин — повний робочий тиждень, повернутий із дій, які нікого не розвивають.
Як було раніше
Форма на сайті надсилала повідомлення на пошту. Усе далі робила людина:
- Відсіювання спаму. Боти знаходять форму швидше за клієнтів. Значна частина повідомлень не була зверненнями.
- Перенесення контакту в таблицю. Ім’я, пошта, компанія, текст — вручну, з листа в таблицю.
- Відповідь клієнту. Щоразу написана заново.
- Внесення завдання. Нагадування про контакт, щоб звернення не застрягло.
Шість-десять хвилин на звернення, не рахуючи часу на видалення спаму.
Жоден із цих кроків не складний. Проблема не в складності, а в тому, що кожен із них залежить від того, чи хтось саме зараз зазирне в пошту. Це саме той тип процесу, про який ми пишемо клієнтам: повторюваний, із чіткими правилами, на цифрових даних, із виправною помилкою.
Що ми побудували
Увесь процес поєднує інструменти, якими ми вже користувалися. Нічого не купували.
Форма надсилає звернення у вебхук. Не на пошту — у сценарій, який вирішує, що далі.
Антиспам-фільтр відхиляє ботів. Три умови одночасно: приховане поле форми має бути порожнім, адреса пошти має бути правильно побудована, а текст має містити щось, крім випадкових символів. Приховане поле — це так званий honeypot: людина його не бачить, бот заповнює все, що знайде.
Звернення потрапляє в таблицю. Автоматично, у ті самі колонки, що й завжди, без ручного переписування.
Сповіщення йде на пошту. З повним текстом, щоб можна було оцінити звернення, не відкриваючи таблиці.
Маршрутизатор розпізнає мовну версію. Форма передає інформацію про те, з якої версії сайту прийшло звернення, а сценарій скеровує його до відповідної гілки. Сайт має три мовні версії, тож гілок теж три.
Клієнт отримує підтвердження своєю мовою. Не «дякуємо за повідомлення», а інформацію про те, коли ми відповімо і що станеться далі.
Завдання потрапляє у список. Автоматично, з терміном.
До цього окремий шлях: хто волів би одразу обрати час розмови, натискає календар і бронює тридцять хвилин без листування.
Скільки це зайняло
| Етап | Час |
|---|---|
| Проєкт, зокрема добір інструментів | бл. 2 годин |
| Побудова сценарію | 2–3 години |
| Тести й правки | 2 дні |
Тести зайняли в кілька разів більше, ніж побудова. Це не аномалія і не означає, що щось пішло не так. Так виглядає кожне чесне впровадження.
Побудова сценарію — це складання блоків, які роблять те, що мають робити в ідеальних умовах. Тести — це перевірка, що станеться, коли хтось введе адресу без равлика, надішле порожню форму, натисне двічі або заповнить її в іншій мовній версії.
Коли виконавець називає термін, варто запитати, скільки з нього — це тести. Якщо відповідь «протестуємо наживо», це означає, що тестуватиме клієнт.
Розрахунок: окупність за шість тижнів
Конкретні цифри, без округлення на свою користь.
| Позиція | Значення |
|---|---|
| Витрачена праця | бл. 5 годин |
| Звернень за перші 2 тижні | 12 |
| У перерахунку на місяць | бл. 26 |
| Час ручної обробки | 6–10 хв на звернення |
| Економія на місяць | бл. 3,5 години |
| Окупність | бл. 6 тижнів |
| У масштабі року | понад 40 годин |
За два тижні ми повернули приблизно третину витраченого часу. За нижньої межі оцінки, якби ручна обробка займала лише шість хвилин, окупність настала б за вісім тижнів. За верхньої — за п’ять. У кожному варіанті це менше ніж два місяці.
До цього додаються дві речі, які складніше порахувати, але вони цілком реальні.
Спам перестав існувати як проблема. Він не забирає часу, бо не доходить до пошти. Цього немає в таблиці, а до автоматизації це була помітна частина роботи.
Відповідь виходить миттєво, будь-якої пори. Звернення, надіслане в суботу ввечері, отримує підтвердження в суботу ввечері, а не в понеділок вранці. При виборі виконавця час першої відповіді часто буває вирішальним — і цієї різниці ручна обробка не надолужить жодними зусиллями.
П’ять годин ми вклали один раз. Процес працює щомісяця однаково, незалежно від відпусток, завалу роботи й того, чи хтось зазирнув у пошту. За рік баланс — понад сорок годин, за два — удвічі більше, за тих самих одноразових витрат.
Коли це не окупається
Не кожен процес окупається за шість тижнів. Умова проста і варта перевірки до впровадження, а не після.
Менш ніж кільканадцять повторень на місяць — і розрахунок розсипається. Той самий процес за трьох звернень на місяць окупався б понад рік. Тоді ми прямо кажемо клієнту, що ще не варто.
Процес без усталених правил спершу треба описати. Якщо троє людей обробляють звернення трьома способами, автоматизація закріпить один із них — не обов’язково найкращий.
Наш випадок відповідав обом умовам від початку, і саме тому результат такий, який є. Це не випадковість, а критерій добору.
Що пішло не так
Три речі. Усі виявилися на тестах, жодна не дійшла до клієнта, усі виправили за кільканадцять хвилин.
Фільтр honeypot порівнював текст замість довжини
Приховане поле мало бути порожнім. Умова перевіряла, чи його значення дорівнює порожньому тексту — і не працювала, бо порожнє поле форми не завжди приходить як порожній текст. Правильне рішення — перевірка довжини значення й числове порівняння з нулем. Різниця виглядає косметичною, а вирішує, чи фільтр узагалі працює.
Правило припускало чекбокс, якого вже не було
Форма мала обов’язковий чекбокс згоди на контакт. Ми замінили його на інформаційне застереження, бо при відповіді на запит згода не є правовою підставою обробки — нею є вжиття заходів на вимогу особи перед укладенням договору.
Зміна була слушною, але сценарій усе ще перевіряв, чи поле згоди має значення «on». Після видалення чекбокса ця умова вже не могла виконатися і відхиляла б усі звернення.
Це найцікавіша з трьох помилок, бо показує те, про що легко забути: зміна на сайті здатна зламати автоматизацію, яка сайт лише читає. Якщо хтось змінює форму, хтось має перевірити сценарій. Тому при впровадженнях ми залишаємо документацію процесу — щоб було зрозуміло, що від чого залежить.
Формат надсилання блокував запит
Форма надсилала дані у форматі, за якого браузер спершу виконує додатковий запит на перевірку, чи сервер погоджується прийняти дані з іншого домену — і на цьому етапі може зупинитися. Зміна формату на простіший усунула цей крок повністю.
Усі три виявилися під час тестів. Якби вони виявилися на продакшені, кожна означала б звернення, про які ми ніколи б не дізналися. Це саме та причина, чому тести зайняли два дні.
Чого ми свідомо не автоматизували
Змістовної відповіді. Клієнт отримує автоматичне підтвердження, але справжню відповідь пише людина. Автомат не вдає менеджера з продажу.
Кваліфікації звернення. Те, чи описаний у формі процес підходить для автоматизації, потребує оцінки. Ми надсилаємо запитання, а не вирок.
Персоналізації тексту мовною моделлю. Це наступний крок, і його відкладено свідомо: спершу версія на правилах має опрацювати реальні звернення, щоб стало зрозуміло, що модель мала б покращити. Автоматизувати те, чого ще не виміряв, — це вгадування.
Коли цей крок настане, з ним прийде обов’язок, про який варто знати заздалегідь: одержувача треба поінформувати, що текст підготував штучний інтелект. Це випливає зі ст. 50 AI Act ЄС і діє від 2 серпня 2026 року. Ми написали про це окремо в тексті про новий обов’язок інформування про ШІ.
Найчастіші запитання
Ні. Ми почали з таблиці. CRM полегшує роботу за більшої кількості звернень, але не є умовою. Можна почати без нього й додати пізніше.
Автоматизація одного кроку процесу — 3 600 PLN і п’ять робочих днів. Цілий процес обробки запитів, з інтеграціями та документацією — 6 900 PLN і десять днів. Повні ціни є на сторінці з цінами.
Бо в себе нам не треба було нікого питати, як процес має виглядати. У клієнта найбільша частина роботи — це узгодження правил і їх перевірка на справжніх даних, а не сама побудова.
Залежить від кількості повторень. За двадцяти з чимось звернень на місяць і восьми хвилин на кожне — кілька тижнів. За кількох звернень на місяць — понад рік, і тоді ми відмовляємо. Розрахунок робимо на консультації, перш ніж щось будувати.
Може, тому фільтр перевіряє умови, які людина зазвичай не порушує: приховане поле лишається порожнім, адреса пошти правильно побудована. За сумніву краще пропустити спам, ніж відхилити клієнта, і саме так ми налаштовуємо пороги.
Звернення не зникають — сценарій можна відновити, а дані з форми потрапляють у таблицю. Для клієнтських впроваджень ми додатково проєктуємо аварійний шлях, щоб звернення завжди мало куди потрапити.
Можна. Складність не в інструментах, а у винятках: що робити з порожнім полем, зі зверненням з іншої мовної версії, з клієнтом, який надіслав форму тричі. На це йде більшість часу, і саме про це два дні тестів.
П’ять років будував операційну роботу у WebWave: від створення відділу підтримки з нуля до посади Head of Operations та інтеграції після придбання компанії. Впорядковуючи ці процеси, він побачив, скільки часу забирають дії, які нікого не розвивають — і що інструменти, здатні їх перебрати, уже існують. Випускник факультету фінансів підприємств у Варшавській школі економіки (SGH).
Профіль у LinkedIn →