Коротка відповідь: Повідомлення про помилки в корпоративному застосунку — саме той процес, який варто автоматизувати повністю: користувач натискає плавучу іконку безпосередньо в застосунку, позначає проблему на скриншоті й надсилає повідомлення. Система сама додає технічний контекст, зокрема помилки з консолі браузера, мовна модель узагальнює повідомлення й пропонує пріоритет, а сповіщення надходить у Telegram раніше, ніж користувач встиг би дописати електронного листа. Ми створили таку систему для власних потреб: вона централізовано обслуговує кілька проєктів одночасно, а для її підключення до нового застосунку достатньо вставити один рядок коду. У цьому кейсі ми розповідаємо, як система працює зсередини та що з неї можна запозичити для автоматизації процесів у вашій компанії.
Про автоматизацію бізнес-процесів ми вже двічі писали в блозі загалом — що насправді варто автоматизувати та сім процесів, які заощаджують години. Але загальні поради мають слабке місце: на них не покажеш зблизька, який вигляд має готова автоматизація — де вона починається, де закінчується і що в ній залишається за людиною. Тому цього разу розглянемо конкретний проєкт із нашої практики: систему повідомлень про помилки, яку ми створили для себе, бо нам набридли типові звернення на кшталт «не працює, подивіться, будь ласка».
Початковий стан: «не працює» електронною поштою
Ми обслуговуємо кілька вебзастосунків — як власних, так і тих, які створили та адмініструємо для клієнтів. І в кожному з них рано чи пізно виникає однакова ситуація: користувач стикається з помилкою й має комусь про неї повідомити.
Без спеціальної системи цей процес щоразу виглядає однаково:
- Користувач пише електронного листа або телефонує: «Я не можу зберегти запис».
- Технічний фахівець ставить додаткові запитання: у якому браузері? На якій сторінці? На що саме ви натиснули? Можете надіслати скриншот?
- Користувач тим часом займається іншими справами, відповідає через день і вже не пам’ятає половини подробиць.
- Технічний фахівець намагається відтворити помилку наосліп — часто безуспішно, оскільки в описі бракує ключової обставини.
Кожен цикл такого листування означає очікування для обох сторін. А головне — повідомлення не мають ані єдиної структури, ані спільної черги. Одне надходить електронною поштою, друге — телефоном, третє повідомляють усно на зустрічі, а четверте губиться зовсім, бо користувач «не хотів турбувати».
За критеріями з нашої статті про автоматизацію це хрестоматійний кандидат: процес повторюється, має чіткий вхід і вихід (помилка → структуроване повідомлення в черзі), а зараз його гальмують ручне переписування інформації та додаткові запитання.
Завдання: повідомлення створюється там, де виникла помилка, і потрапляє до єдиної черги
Ми визначили такі цілі:
- Користувач повідомляє про помилку безпосередньо в застосунку, де з нею зіткнувся, — без електронної пошти, перемикання між вікнами та окремого створення скриншотів.
- Повідомлення завжди має однакову структуру: скриншот із позначеним місцем, опис і технічний контекст.
- Усі застосунки надсилають повідомлення до єдиної централізованої черги — замість п’яти поштових скриньок, п’яти форм і п’яти різних підходів.
- Пріоритет і короткий виклад пропонує AI-тріаж, щоб черга була впорядкована ще до того, як її вперше відкриє людина.
- Команда дізнається про нове повідомлення миттєво через Telegram.
Що бачить користувач: жучок у правому нижньому куті
У кутку застосунку розміщена невелика плавуча іконка жучка. Після натискання відкривається трикроковий майстер:
- Позначити місце. Віджет створює знімок поточного екрана, а користувач позначає проблемну ділянку олівцем або рамкою. Жодних «натисніть PrintScreen і вставте зображення в лист» — малювати можна просто в застосунку.
- Описати. Користувач коротко пояснює, що сталося і якого результату очікував. Той, хто не хоче писати, може продиктувати опис голосом.
- Перевірити й надіслати. Користувач бачить, які дані буде надіслано, і підтверджує відправлення.
Усе це займає менше часу, ніж відкриття поштового клієнта. І що особливо важливо: до повідомлення автоматично додаються помилки з консолі браузера — саме та технічна інформація, яку звичайний користувач ніколи не надіслав би, бо навіть не знає про її існування.
Віджет працює в так званому shadow DOM, тому повністю не залежить від технології сторінки. Він не порушує оформлення застосунку, і не має значення, чи створено сайт на React, у старішій системі керування контентом або як статичну сторінку.
Що відбувається після надсилання: санітизація, тріаж, Telegram
Тут починається найцікавіша частина. Усе наведене нижче відбувається без жодного втручання людини:
1. Санітизація. Ще до запису в базу даних текст повідомлення проходить через фільтр, який приховує паролі, токени, адреси електронної пошти, номери телефонів і чеські особисті номери (rodná čísla). Якщо користувач випадково вставить пароль в опис, до черги він уже не потрапить. Водночас особу автора повідомлення — ім’я та адресу електронної пошти — система зберігає, щоб було кому відповісти.
2. AI-тріаж. Мовна модель читає повідомлення й додає запропонований пріоритет і стислий виклад. Завдяки цьому черга впорядкована ще до того, як її вперше відкриє людина: збій збереження опиниться вгорі, а косметичне зауваження щодо кольору кнопки зачекає. Тріаж працює через OpenAI-сумісний інтерфейс, тому модель можна запускати локально на власному обладнанні — тоді повідомлення з внутрішніх застосунків не залишають меж компанії.
3. Сповіщення в Telegram. Повідомлення про нову помилку надходить у чат одразу після відправлення. Кожен проєкт може мати власний канал, тому сповіщення із застосунку клієнта бачать саме ті люди, які за нього відповідають.
4. Черга в панелі адміністратора. Відповідальний фахівець бачить усі повідомлення в одному місці й може фільтрувати їх за проєктом, статусом, типом або пріоритетом. Кожне повідомлення містить анотований скриншот, опис, помилки консолі та контекст — додаткові запитання не потрібні, адже вся важлива інформація надходить із першого разу. Після виправлення фахівець позначає повідомлення як вирішене.
Зверніть увагу на розподіл роботи, про який ми говоримо в кожному матеріалі про AI: машина сортує й готує, людина ухвалює рішення та виправляє. Тріаж лише пропонує пріоритет — він сам нікого не будить і нічого не виправляє. Так задумано навмисно. Повідомлення про помилку — процес із чітким входом і виходом, ідеальний для автоматизації; безпосередня діагностика та виправлення — уже ні.
Конфіденційні дані: що система навмисно не записує
У внутрішніх інструментах про безпеку часто замислюються лише після впровадження. Тут вона була частиною вимог із самого початку:
- Приховування конфіденційних даних перед записом. Паролі, токени, адреси електронної пошти, номери телефонів і чеські особисті номери (rodná čísla) видаляються з тексту повідомлення до збереження будь-яких даних.
- Скриншоти поза публічною частиною сайту. Знімки екрана зберігаються поза загальнодоступними файлами, а переглядати їх можна лише через захищену панель адміністратора. Тому скриншот із внутрішнього застосунку ніколи не розміщується за публічною адресою.
- Перевірка джерела. Сервер приймає повідомлення лише з доменів, зареєстрованих для відповідного проєкту. Сторонній сайт не може засмічувати чергу.
- Панель адміністратора захищена токеном. Доступ до черги повідомлень можливий лише із секретним токеном; без нього сервер відхиляє запит.
Підключення до іншої системи: один рядок коду
Від самого початку система створювалася як центральний сервіс для кількох проєктів. Підключення до нового застосунку виглядає так:
- На сторінку додається один тег
<script>, який посилається на центральний сервіс. - У реєстрі сервісу проєкт отримує ключ, перелік дозволених доменів і, за потреби, власний канал Telegram.
- Готово — жучок з’являється в кутку, а повідомлення починають надходити до спільної черги.
Втручатися в систему клієнта не потрібно: жодних змін у її коді, інсталяцій на її сервері чи залежності від технологій, на яких створено сайт. Водночас увесь сервіс працює як один контейнер на нашому сервері — без складної інфраструктури, яку мав би обслуговувати хтось іще.
Варто також згадати, як виникла ця система. Приблизно 80 % коду ми взяли з модуля повідомлень про помилки, який спочатку створили для одного конкретного застосунку з керування комісіями, а потім узагальнили для кількох проєктів; наступним стало впровадження в нашому застосунку для обліку перевірок. Це типовий шлях хорошої автоматизації — вона не виникає з нуля як великий проєкт, а постає внаслідок узагальнення рішення, яке вже добре зарекомендувало себе в реальній експлуатації.
Що це насправді заощаджує
Ми не стверджуватимемо, що заощадили точну кількість годин, — ми цього не вимірювали. Однак економію добре видно безпосередньо зі структури процесу:
- Зник цикл додаткових запитань. Раніше скриншот, версію браузера та послідовність дій доводилося збирати протягом кількох раундів листування; тепер усе надходить одразу, зокрема помилки консолі, які користувач сам ніколи не надіслав би.
- Повідомлення не губляться. Усе перебуває в єдиній черзі зі статусами. Нічого не зависає в поштовій скриньці, нотатках із телефонної розмови чи в чиїйсь пам’яті.
- Пріоритет відомий одразу. Машина попередньо сортує чергу, тому критичні проблеми не губляться серед дрібниць.
- Повідомляти про помилки стало простіше. Коли для цього достатньо трьох натискань безпосередньо в застосунку, аргумент «не писатиму через це електронного листа» зникає — і помилки швидше потрапляють до відповідального фахівця.
Що варто запозичити, якщо ви хочете автоматизувати власний процес
Цей проєкт точно відповідає підходу, який ми описуємо в загальних статтях:
- Чіткий вхід і вихід. Помилка в застосунку → структуроване повідомлення в черзі. Жодних рішень, що передбачають відповідальність, — ідеальна робота для автоматизації.
- Людина залишається в контурі. AI сортує та узагальнює; діагностику, виправлення й комунікацію з користувачем виконує технічний фахівець.
- Конфіденційні дані під контролем. Санітизація перед збереженням, скриншоти поза публічною частиною сайту, можливість використовувати локальну модель.
- Спочатку невелике рішення, потім узагальнення. Спершу модуль в одному застосунку; лише після того, як він добре себе зарекомендував, із нього створили центральний сервіс для всіх проєктів.
Такий самий підхід можна застосувати до приймання замовлень, рекламацій, внутрішніх IT-запитів або погодження матеріалів — усюди, де сьогодні циркулюють неструктуровані електронні листи, а хтось вручну переносить із них інформацію далі.
Якщо під час читання ви подумали: «Нам теж таке потрібно», — незалежно від того, йдеться про повідомлення щодо помилок чи зовсім інший процес, який у вас досі тримається на електронних листах і додаткових запитаннях, — саме такі автоматизації ми створюємо для компаній на замовлення в межах послуги IT для компаній. Ми починаємо з короткої консультації щодо вашого конкретного процесу, а не з презентації про штучний інтелект; зв’язатися з нами можна через сторінку контактів. А якщо ви хочете, щоб ваша команда самостійно знаходила подібні можливості, для цього є навчання з AI для компаній.
Поширені запитання
Чи працює віджет лише в сучасних застосунках?
Ні. Він підключається одним скриптом і завдяки shadow DOM працює незалежно від технології сторінки — у сучасному односторінковому застосунку, старішій системі керування контентом або на статичному сайті. Втручатися в код застосунку не потрібно.
Що станеться, якщо користувач напише в повідомленні пароль або персональні дані?
Перед збереженням текст повідомлення проходить санітизацію, яка приховує паролі, токени, адреси електронної пошти, номери телефонів і чеські особисті номери (rodná čísla). Ім’я та адресу електронної пошти автора зберігають, щоб після вирішення проблеми було кому відповісти.
Чи замінить AI-тріаж програміста?
Ні — і це не є метою. Тріаж узагальнює повідомлення й пропонує пріоритет, тому людина відкриває впорядковану чергу замість купи неструктурованих електронних листів. Діагностику та виправлення завжди виконує технічний фахівець.
Чи обов’язково передавати дані з повідомлень до закордонної хмари?
Ні. Сервіс працює на власному сервері, скриншоти зберігаються поза загальнодоступними файлами, а AI-тріаж можна запускати за допомогою локальної моделі. У такому разі повідомлення з внутрішнього застосунку не залишають інфраструктуру компанії.
Скільки коштує така автоматизація?
Це залежить від масштабу та від того, які системи вже є у вашій компанії, тому конкретну пропозицію ми готуємо лише після короткої консультації щодо вашого процесу. Загальні орієнтири вартості корпоративного AI ми описуємо у статті скільки коштує AI для компанії.
Де нас знайти
ITHOPE — компанія з Брно, Чехія: ми робимо відновлення даних з дисків, RAID і NAS, сервіс ПК та ноутбуків та IT для бізнесу, усе у власній лабораторії за адресою Viniční 3587/216, 615 00 Brno.
Телефон +420 775 556 063 (цілодобово). Пристрій можна привезти особисто або надіслати курʼєром (Zásilkovna, PPL).