AI-агент для заповнення веб-форм і тендерних заявок
Десятки зовнішніх порталів — державні та корпоративні майданчики, кожен зі своїм набором полів, лімітами на довжину рядка, обов’язковими вкладеннями та правилами іменування файлів.
Дані при цьому лежать в обліковій системі, вкладеннях до листів і папках на мережевому диску, а не в одному місці. Перенесення даних у форми вручну займає години на одну заявку і майже завжди спричиняє розбіжність із джерелом.
Ціна помилки вища, ніж здається: пропущений обов’язковий файл, реквізит з одруком або дата в неправильному форматі — і заявка повертається на доопрацювання або відхиляється формально, ще до оцінки по суті.
Коли тендерні заявки готують в останній день, часу на переперевірку не залишається — частина заявок не надсилається взагалі.
AI-агент змінює схему: він розбирає структуру конкретної форми, зіставляє поля з джерелами в обліковій системі (1С, вивантаження, реєстри), підтягує потрібні скани й довідки, перевіряє обов’язковість і заповнює форму. Людина залишається на підтвердженні перед надсиланням — тобто на рішенні, а не на перенесенні.
Автоматизація заявок знімає рутину зі спеціаліста: замість ручного заповнення веб-форм він перевіряє готову чернетку. При цьому AI-агент працює з тими формами, які є — доопрацьовувати чужі майданчики під себе не потрібно. Нижче розбираємо, як це влаштовано і що залишається під контролем замовника.
Що змінюється в процесі підготовки заявок і комерційних даних
До впровадження заявку збирали вручну: спеціаліст відкривав облікову систему, переносив картку компанії, банківські дані та позиції у форму замовника, потім вичитував усе рядок за рядком. На один лот витрачалися години, а за потоку з десятків заявок робота йшла в поспіху. Агент знімає механічну частину — збір і перенесення даних, — а людині залишається перевірка.
Реквізити перестають бути джерелом повернень. Розбіжності в найменуванні, ІПН, КПП, адресі та банківських даних — найчастіша причина, через яку заявку надсилають на доопрацювання.
Агент бере значення з одного довідника, перевіряє контрольні суми й підставляє поле із зазначенням джерела, тому невідповідність видно до надсилання, а не після зауваження комісії.
Навантаження на ключового спеціаліста змінюється якісно. Раніше копіюванням і звіркою займався найдосвідченіший співробітник — той, хто потрібен на ціновій частині та технічних вимогах.
Тепер його час іде на змістовні розділи, а рутинне складання відбувається паралельно за кількома заявками.
Передбачуваність подання зростає: у кожної заявки є статус, перелік незаповнених полів і нагадування про строк. Пропуск строку подання перестає бути рядовим ризиком — заявка збирається заздалегідь і лежить готовою до надсилання, залишається ухвалити рішення щодо ціни та умов.
Ефект вважаємо за чотирма величинами: час на одну заявку, частка повернень через розбіжності в реквізитах, кількість заявок на спеціаліста та частка поданих у строк. Їх знімаємо на старті й повторюємо після впровадження, щоб результат був вимірюваним, а не декларативним.
Режими роботи AI-агента: автономний і з підтвердженням
Режим роботи — це не галочка в налаштуванні, а різний рівень довіри до даних і різна ціна помилки.
Агент витягує значення з картки постачальника, комерційної пропозиції та статутних документів, зіставляє їх із полями форми й далі діє за одним із трьох сценаріїв: заповнює сам і надсилає, готує чернетку на контроль перед надсиланням або лише підказує оператору.
| Режим | Як поводиться агент | Коли підходить | Обмеження |
|---|---|---|---|
| Автономний режим | Заповнює форму й надсилає заявку без участі людини, спірні поля закриває значенням за замовчуванням | Масові однотипні заявки, майданчики з передбачуваною формою, дані вже вивірені | Помилка потрапляє у надіслану заявку; потрібні журнал дій і правила відкату |
| Заповнення з підтвердженням | Готує чернетку повністю, підсвічує поля з низькою впевненістю, надсилає після підтвердження оператора | Тендери з ціною та юридично значущими формулюваннями, нові майданчики | Потребує часу оператора — хвилини на заявку |
| Підказки оператору | Форму не чіпає, пропонує значення поруч із полем і посилання на джерело | Незнайомі форми, разові закупівлі, навчання на нових типах документів | Швидкість повністю залежить від оператора |
Вибір режиму задає рівень довіри до даних, а не зручність інтерфейсу: якщо джерела суперечать одне одному, агент не повинен мовчки вибирати значення.
Тому режими призначаються посекційно — реквізити й контакти можна віддати автономному режиму, а цінову пропозицію та декларації тримати на підтвердженні.
Зміна режиму не потребує переписувати сценарій: правила успадковуються від типу поля, а журнал фіксує, яке значення й з якого документа підставлено.
Як відбувається впровадження: етапи інженерної роботи
Починаємо не з налаштування моделі, а з інвентаризації: агент не заповнить поле, якщо невідомо, звідки брати значення й за яким правилом його нормалізувати.
Тому робота йде послідовно — від аудиту форм до дослідної експлуатації, і на кожному етапі залишається артефакт, який можна перевірити.
- Аудит форм і джерел даних. Збираємо всі форми та тендерні майданчики, розбираємо структуру полів, обов’язковість і обмеження формату. Паралельно фіксуємо джерела: реквізити, картки товарів, прайси, скани документів, листування щодо заявки.
- Карта полів. Зіставляємо кожне поле форми з джерелом і правилом вилучення: тип даних, нормалізація дат і адрес, одиниці вимірювання, що вважається допустимим значенням.
- Налаштування сценаріїв заповнення. Описуємо логіку: що заповнюється автоматично, де потрібна перевірка людиною, як агент поводиться за відсутності даних — залишає поле порожнім або запитує уточнення.
- Перевірка на тестових заявках. Проганяємо сценарії на накопичених заявках і звіряємо з еталоном: частка полів, заповнених правильно з першого разу, які розбіжності повторюються. Помилки правимо в карті полів, а не в окремій відповіді.
- Дослідна експлуатація. Агент працює в режимі підказки: готовий варіант бачить оператор і підтверджує його. Так накопичується статистика за формами, які не потрапили до тестового набору.
- Передача в експлуатацію. Віддаємо документацію щодо карти полів, регламент її оновлення при зміні форм і інструкцію для операторів. Після передачі правки в сценаріях команда замовника вносить сама.
Конфігурації, правила доступу й регламенти після впровадження
Впровадження закінчується не демонстрацією, а передачею комплекту артефактів, за якими систему можна експлуатувати й розвивати без нас. Нижче — те, що фізично залишається в замовника в його контурі та репозиторії.
- Налаштування агента та схеми розмітки полів — конфігурації за кожним типом форми: обов’язкові поля, джерела значень, перевірки перед надсиланням.
- Правила доступу й ролі користувачів — матриця «роль → дія → область даних»: хто запускає заповнення, хто підтверджує надсилання, хто бачить чернетки.
- Журнал дій — за кожною заявкою: хто ініціював, що агент підставив автоматично, що оператор виправив вручну, чим закінчилося надсилання.
- Регламент роботи з формами — порядок обробки черги, правила ескалації при відхиленні та точки, де обов’язкова перевірка людиною.
- Інструкція для оператора — сценарії розбору помилок розмітки, повторного запуску, коригування джерела даних і звернення до підтримки.
- Схема інтеграцій і план відкату — задіяні системи, порядок зберігання ключів, повернення до ручного режиму без втрати заявок.
- Порядок супроводу — оновлення правил і версій, періодичність перевірки якості розмітки, відповідальні за зонами.
Передача займає один-два робочі сеанси з вашою командою — далі систему веде внутрішній інженер або адміністратор, а ми підключаємося лише до змін логіки.
Кейс: заповнення тендерних заявок на потоці
Тендерний відділ холдингу з вісьмома напрямами веде потік заявок на постачання обладнання та послуг.
До впровадження кожну заявку збирали вручну: спеціаліст відкривав форму майданчика, переносив реквізити з картки контрагента, шукав актуальні сертифікати в мережевій папці та вписував характеристики з каталогу.
На одну заявку витрачалося 35–50 хвилин, а на піку сезонного попиту відділ обробляв лише частину запрошень — решта закривалася за строком подання.
Що змінили в схемі роботи
Основні втрати були не в наборі тексту, а в повторних заявках: більшість позицій уже подавалася в інших лотах, але збиралася заново з нуля.
Ми розібрали форми майданчиків на поля й пов’язали їх із внутрішнім довідником — реквізити, сертифікати та характеристики беруться з одного джерела з контролем версії та строку дії.
Агент підставляє дані у форму, позначає поля без підтвердженого значення й віддає заявку на перевірку: без підтвердження спеціаліста надсилання не відбувається. За кожною позицією зберігається профіль, і повторне подання збирається з історії — змінюються лише умови лота.
Метрики до і після
Підсумки кейсу впровадження зафіксували так: час на заявку — з 35–50 хвилин до 5–7, частка відхилень із формальних причин — з 12% до 2%.
Потік зріс з 30 до 90 заявок на тиждень за того самого складу тендерного відділу, бо знялася не швидкість друку, а повторне складання одних і тих самих даних.
Окремо перевіряли зв’язок із Єдиною інформаційною системою у сфері закупівель: розбіжності між картками зникли, оскільки джерело реквізитів тепер одне.
Що робити, якщо форми на порталах часто змінюються?
Агент не прив’язується до жорстких координат і порядку полів — він спирається на смислові ознаки: підпис, підказку, тип введення, сусідні мітки та структуру блоку.
Перейменування поля, перестановка секцій або зміна розмітки не ламають заповнення: зіставлення перераховується на льоту за сукупністю ознак, а не за одним зашитим правилом.
Карта полів — окремий шар опису, а не код: у ній зазначено, який реквізит заявки відповідає кожному полю, які формати та правила перевірки застосовуються.
Оновлення карти полів після правки порталу займає хвилини й не потребує перезбирання рішення — змінюється опис, сам агент залишається тим самим.
Після заповнення агент проходить форму повторно: звіряє внесені значення з вихідними даними, перевіряє маски, обов’язкові та приховані поля, реакцію форми на введення. Розбіжності не залишаються як є — поле позначається й віддається на ручну перевірку, а не заповнюється навмання.
Оновлення опису полів ведемо ми як частину рішення: відстежуємо зміни розмітки на підключених порталах, фіксуємо їх і переносимо до карти полів. Замовнику не потрібно тримати інженера, який вручну переписує правила після кожної правки на боці порталу.
Кожна дія залишається в журналі: видно, яке поле розпізнано, що підставлено й що перевірено. Стійкість до правок порталу стає передбачуваною — замість гонитви за змінною формою ви отримуєте процес, який відновлюється за один цикл перевірки.
Технічні сумніви й обмеження рішення
Точність тут — вимірювана величина: агент підставляє значення, вилучені з ваших документів, і не домислює відсутнє. Кожне поле зберігає посилання на фрагмент-джерело, тому перевіряльник бачить, звідки взялася цифра.
На моделях рівня OpenAI частка полів, прийнятих без правки, налаштовується під конкретний набір форм, а не береться із загальної статистики.
Наскільки точно агент заповнює поля?
Числа, дати та суми проходять перевірку формату й діапазону, текстові поля звіряються з довідником допустимих значень. Якщо в документі два суперечливі значення або поле не знайдено — воно залишається порожнім і потрапляє в чергу на перевірку людиною, а не заповнюється здогадом.
Як обробляються вкладення й табличні додатки?
Вкладення розбираються на текст і таблиці: рядки зіставляються з позиціями заявки, файли прикріплюються зі збереженням імені та порядку. Якщо майданчик приймає лише певний формат, документ конвертується, а вихідний файл залишається в чернетці заявки для звірки.
Які доступи до даних потрібні рішенню?
Окремий обліковий запис із правом лише на подання заявок і токен з обмеженим строком дії. Доступу до внутрішніх систем, листування та баз агент не отримує, а журнал дій показує, який документ читався й яке поле заповнено.
Що відбувається при перерваному заповненні?
Чернетка заявки зберігається після кожного підтвердженого кроку разом із ключем ідемпотентності. Повторний запуск продовжує з останнього кроку, а не з початку, тому дублі на майданчик не надсилаються, а незаповнена заявка не надсилається взагалі.
Обговоримо задачу: з чого почати роботу
Перша зустріч — робоча, а не презентаційна. Розбираємо, які форми та заявки заповнюються у вас зараз, хто цим займається і на яких полях найчастіше виникають помилки.
Щоб розмова була предметною, достатньо надіслати зразки документів і доступ до тестового контуру — решту уточнюємо по ходу.
- Перелік вхідних даних: 5–10 прикладів уже заповнених форм (PDF, DOCX, XLSX), порожні шаблони та внутрішні інструкції із заповнення, якщо вони є.
- Карта джерел значень: звідки AI-агент бере дані — картка компанії, реєстри, минулі заявки, довідники. Позначаємо, що доступне машиночитним, а що доведеться приводити до ладу.
- Правила й обмеження: обов’язкові поля, вимоги до форматів значень і перевірки, які заявка не проходить при розбіжності.
- Сценарії відмови: що агент робить, коли даних немає або вони суперечливі — залишає поле порожнім, позначає для людини або запитує уточнення.
- План робіт: етапи від розбору шаблонів до здачі, з точками, де ви бачите проміжний результат.
- Оцінка строків: від чого залежить тривалість — кількість типів форм, якість довідників, складність зовнішніх порталів.
- Межі пілотного запуску: один тип форми або один підрозділ, щоб перевірити точність на реальних даних до масштабування.
- Критерії приймання: частка полів, які заповнюються без правок, і порядок обліку помилок.
За підсумками зустрічі ви отримуєте короткий документ: перелік вхідних даних, план робіт за етапами, оцінку строків і погоджені межі пілота. Опишіть задачу — повернемося з оцінкою та планом.
