Автоматизація заявок на оплату та внутрішніх заявок

Автоматизація заявок на оплату зазвичай починається зі скарги бухгалтера: «рахунки приходять звідусіль, а хто їх погодив — незрозуміло». Менеджер пересилає PDF у месенджер, керівник відповідає «ок» у загальному чаті, власник погоджує усно в коридорі. Через тиждень постачальник питає, де гроші, а рахунок лежить у чиїхось особистих повідомленнях. Так само живуть інші внутрішні заявки: «не працює пошта», «замовте картриджі», «як оформити відпустку».

Стаття для власників і операційних директорів компаній на 20–100 людей, де IT, господарські питання і кадри веде одна-дві людини, а оплати погоджує власник. Розберемо маршрут заявки на оплату від запиту до платежу: які поля потрібні, хто погоджує яку суму, що система перевіряє перед оплатою і як підключити банк. Потім покажемо, як той самий Telegram-бот приймає заявки до IT, адміністративно-господарської частини (АГЧ) і HR.

Окремо — як порахувати, чи окупиться автоматизація саме у вас, де ШІ корисний, а де рішення має лишатися за людиною, і коли досить форми з таблицею.

Коротко

Одна точка входу. Усі заявки — на оплату, до IT, АГЧ і HR — приходять в один бот. Канали «в особисті» і «в загальний чат» закриває правило, а не техніка.
Заявка на оплату — це маршрут, а не повідомлення. Ініціатор, керівник напряму, власник або фінансовий директор, бухгалтер. Хто погоджує, залежить від суми і статті витрат.
Перевірки — до оплати. Дубль рахунку, змінені реквізити, ліміт бюджету й залишок на рахунку система перевіряє сама. Підписує платіж у банку людина.
ШІ розбирає, правила вирішують. ШІ читає рахунок і довільний текст заявки, заповнює картку й перепитує. Маршрут, пороги і суми визначають правила.
Окупність рахується формулою. Заявки × хвилини ручної роботи × вартість години плюс ціна помилок. Порахуйте до старту, а не після.

Чому внутрішні заявки губляться

Кілька каналів, кілька відділів і жодного статусу

Типовий тиждень у компанії на 50 людей. Олена з відділу продажів пересилає бухгалтеру в особисті рахунок за рекламу. Андрій пише завгоспу про зламаний стілець у загальний чат. Марина питає HR поштою про відпустку. IT-фахівцю дзвонять, бо «так швидше». Власнику в коридорі кажуть: «там треба терміново оплатити підрядника».

У жодної з цих заявок немає номера, відповідального, терміну і статусу. Проблема не в людях, а у відсутності системи. Ніхто не бачить усього потоку, тому неможливо сказати, скільки заявок відкрито, які прострочені і хто їх тримає. Якщо виконавець захворів чи пішов у відпустку, його заявки зависають разом із ним.

Ознаки, що час наводити лад

Перевірте свою компанію за списком. Якщо збігаються три пункти й більше, автоматизація окупиться швидше, ніж здається:

рахунок оплатили двічі або не оплатили вчасно, бо він «загубився в чаті»;
погодження оплати — це «плюсик» у месенджері без суми й підстави;
бухгалтер щотижня питає «а це хто погодив?»;
співробітники питають статус заявки частіше, ніж її виконують;
IT-фахівець і завгосп не можуть назвати, скільки заявок отримали минулого місяця;
HR відповідає на одні й ті самі питання про відпустки й лікарняні;
після відпустки одного співробітника його незакриті справи доводиться збирати з чатів.

Чому окремий helpdesk-портал часто не приживається

Класичні системи підтримки — Jira Service Management, Zendesk — зроблені для служб підтримки з адміністратором, налаштованими чергами і звичкою працювати в порталі. У компанії на 50 людей основний робочий канал часто Telegram. Просити людей іти на окремий сайт, щоб подати заявку, — зайвий крок. Частина команди його пропускає і далі пише в особисті.

Друга причина — гроші й налаштування. Zendesk бере оплату за кожного агента: тариф Suite Team коштує $55 на агента на місяць при оплаті за рік і $69 при помісячній оплаті (Zendesk). Jira Service Management має безкоштовний тариф до 3 агентів (огляд eesel.ai, січень 2026), але погодження оплат із порогами, банк і українські документи там доведеться налаштовувати окремо. Третя причина — заявки на оплату для helpdesk-систем не основний сценарій. Їх будували для запитів «щось зламалося», а не для маршруту «рахунок → погодження → платіж».

Автоматизація заявок на оплату: маршрут від запиту до платежу

Заявка на оплату — внутрішній запит оплатити рахунок: постачальнику, підрядникові, за оренду, рекламу, підписку, відрядження. Автоматизація заявок на оплату означає, що кожна така заявка має однакові поля, проходить описаний маршрут і закінчується статусом «оплачено» з документом-підставою. Закупівлі матеріалів мають ще й свої перевірки — порівняння постачальників, звірку з прийманням. Їх ми розібрали в статті про автоматизацію відділу постачання. Тут — загальний маршрут для всіх відділів.

Що має бути в заявці на оплату

Мінімальний набір полів, без якого бухгалтер усе одно піде перепитувати:

Отримувач: назва, код ЄДРПОУ або РНОКПП, IBAN.
Сума і валюта, з ПДВ чи без.
Підстава: рахунок (файл або фото), договір, номер замовлення чи проєкту.
Стаття витрат або напрям: реклама, оренда, матеріали, IT, господарські потреби.
Термін оплати: до якої дати і чи є штраф або знижка за дату.
Тип оплати: передоплата, часткова, після поставки.
Ініціатор і відповідальний за закриваючі документи — хто принесе акт чи накладну.

Ініціатор не заповнює це вручну. Він надсилає боту фото рахунку й одне речення: «оплатити рекламу за листопад, до п’ятниці». Решту система бере з рахунку й картки контрагента, а того, чого бракує, — допитується в ініціатора.

Маршрут: вісім кроків

Створення. Ініціатор надсилає рахунок і пояснення в бот. Система створює заявку з номером.
Розбір і заповнення. ШІ читає рахунок, підставляє реквізити, суму, призначення платежу і зіставляє отримувача з контрагентом у базі.
Перевірки. Дубль, змінені реквізити, ліміт статті, наявність договору. Якщо щось не так, заявка отримує позначку і повертається з питанням.
Погодження керівником напряму. Він бачить у Telegram суму, підставу і залишок бюджету статті та натискає «погодити» або «повернути» з коментарем.
Погодження власником або фінансовим директором — якщо сума вища за поріг або стаття поза бюджетом.
Реєстр на дату. Погоджені заявки потрапляють у реєстр оплат на конкретний день. Власник бачить, скільки треба заплатити сьогодні і скільки є на рахунку.
Оплата. Бухгалтер створює платіж у клієнт-банку, або система сама створює чернетку платежу через API банку. Підписує уповноважена людина.
Закриття. Після оплати ініціатор отримує повідомлення. Заявка закривається, коли до неї прикріпили акт або накладну. Без них вона висить у списку «чекаємо документи».

Хто погоджує яку оплату: пороги

Пороги — головне рішення, яке власник ухвалює до запуску. Принцип простий: що більша сума і що менш звична оплата, то вищий рівень погодження.

Тип оплати	Хто погоджує	Коли можна без власника
Регулярна за договором: оренда, зв’язок, підписки	Керівник напряму	Сума і отримувач не змінилися проти минулого місяця
Разова в межах бюджету статті	Керівник напряму	Сума нижча за ваш поріг
Разова понад поріг або поза бюджетом	Власник або фінансовий директор	Ніколи
Перший платіж новому контрагенту	Власник	Ніколи
Рахунок зі зміненими реквізитами	Власник після дзвінка контрагенту	Ніколи
Термінова «сьогодні до обіду»	Власник	Ніколи, навіть якщо сума мала

Поріг підбирайте під власні цифри. Візьміть заявки за минулий квартал і подивіться, на якій сумі закінчуються дрібні щоденні оплати. Нижче цієї межі власник не має бачити кожну заявку — лише тижневий підсумок. Якщо власник погоджує все підряд, погодження стає формальністю, і перевірка зникає.

Регулярні оплати: шаблон замість щомісячної заявки

Оренда, зв’язок, інтернет, підписки на програми, охорона — ці оплати повторюються щомісяця з тією самою сумою. Для них заявка створюється автоматично за графіком із шаблону: отримувач, стаття, сума минулого місяця. Погоджувач бачить лише відхилення: сума змінилася, прийшов рахунок від іншого отримувача, рахунок не прийшов до звичної дати. Якщо все збіглося, заявка йде в реєстр без ручного погодження. Це правило ви вмикаєте свідомо для кожного шаблону, а не для всіх одразу.

Статуси заявки на оплату

Статуси мають відповідати на одне питання: хто зараз тримає заявку.

Чернетка — ініціатор ще не надіслав заявку або бот чекає відповіді на питання.
На погодженні у [ім’я] — видно, у кого саме і скільки часу.
Повернуто на уточнення — з коментарем, що виправити.
Погоджено, у реєстрі на [дата].
Передано в банк — платіж створено, чекає підпису.
Оплачено — з датою і номером платіжної інструкції.
Чекаємо документи — гроші пішли, акту чи накладної ще немає.
Закрито або Відхилено — з причиною.

Рядок «на погодженні у Сергія вже два дні» замінює десяток повідомлень «ну що там з оплатою?».

Перевірки перед оплатою: дублі, реквізити, бюджет і банк

Дубль рахунку

Один рахунок легко оплатити двічі: його надіслали і на пошту, і в месенджер, а потім ще принесли роздрукованим. Система порівнює кожну нову заявку з попередніми: той самий контрагент, той самий номер рахунку, та сама сума за останні тижні. Збіг дає попередження з посиланням на першу заявку. Людина вирішує, чи це справді дубль, чи повторна поставка.

Змінені реквізити

Найдорожча помилка в оплатах — гроші на чужий рахунок. Схема відома: лист «від постачальника» з новими реквізитами, а рахунок належить шахраю. Асоціація ЄМА радить перевіряти кожен запит на зміну реквізитів, не користуватися контактами з листа, де просять зміну, а брати їх із попереднього листування, і для платежів понад встановлений ліміт підтверджувати рахунок отримувача особисто (ЄМА).

Система перетворює цю пораду на правило. IBAN у рахунку звіряється з карткою контрагента. Якщо він інший, заявка автоматично йде власнику з позначкою «реквізити змінено» і задачею зателефонувати контрагенту на номер із картки, а не з листа. Український IBAN починається з UA і має 29 символів. Система перевіряє формат і контрольні цифри ще до погодження, тож описка в номері рахунку не дійде до бухгалтера.

Ліміт бюджету і платіжний календар

Для кожної статті витрат задається місячний ліміт. Заявка показує погоджувачу, скільки вже витрачено і скільки лишиться після цієї оплати. Перевищення не блокує заявку, а піднімає її на рівень власника.

Окремо система збирає платіжний календар: погоджені оплати за датами плюс очікувані надходження від клієнтів. Якщо на п’ятницю погоджено більше, ніж буде на рахунку, власник бачить це в середу, а не в п’ятницю зранку. Тоді є час перенести некритичні оплати або домовитися з постачальником про відстрочку.

Банк: платіж як чернетка, підпис за людиною

Українські банки дають API для бізнесу. Наприклад, у ПриватБанку через API можна створювати платежі в «Приват24 для бізнесу», отримувати виписки й відстежувати баланси. Сервіс безкоштовний для клієнтів банку; для юридичних осіб він доступний на тарифах «Бізнес Комфорт» і «Бізнес ПРО» (ПриватБанк). Відкритими API банку, за його даними, користуються вже понад 85 000 бізнес-клієнтів (ПриватБанк, серпень 2026).

Для заявок на оплату це означає: погоджена заявка стає чернеткою платежу в банку з уже заповненими реквізитами й призначенням. Бухгалтер не переписує IBAN і суму, а перевіряє і підписує. Виписка з банку повертається в систему, і статус «оплачено» ставиться сам, щойно гроші списалися.

Банк і сам тримає людину в контурі. Коли ПриватБанк запустив ШІ-сервіс, що створює платіж із фото рахунку чи тексту, після розпізнавання користувачу все одно «залишається перевірити реквізити та підписати платіж» (ПриватБанк). Так само будуємо й ми: система готує платіж, людина його підписує.

Якщо ваш банк не дає API або доступ закритий тарифом, проміжний варіант — файл імпорту платежів. Той самий ПриватБанк приймає дані у форматах CSV або DBF (ПриватБанк). Система формує файл реєстру, а бухгалтер завантажує його в клієнт-банк однією дією замість десятка ручних платежів.

Що робить ШІ з рахунком, а чого не робить

Робить:

читає рахунок у PDF чи на фото і дістає отримувача, код, IBAN, суму, ПДВ, номер і дату;
розбирає довільний текст на кшталт «оплатити Нову Пошту за жовтень, як завжди» — знаходить контрагента і попередню заявку;
перепитує ініціатора в Telegram, якщо бракує статті чи терміну;
пише чернетку призначення платежу;
готує тижневий звіт: що оплачено, що прострочено, де ще чекаємо документи.

Не робить:

не погоджує оплату і не змінює пороги;
не підписує платіж і не надсилає гроші;
не рахує ліміти й залишки — це роблять формули за даними з системи і банку;
не вирішує, дубль це чи ні, а лише показує збіг.

Розібраний рахунок завжди видно поруч з оригіналом. Погоджувач бачить і цифри, і сам документ, тому помилку розпізнавання легко помітити до підпису.

Закриваючі документи після оплати

Типова дірка — оплатили передоплату, а акт чи накладну так і не отримали. У кінці кварталу бухгалтер збирає їх дзвінками. Тому заявка не закривається самою оплатою. Вона переходить у статус «чекаємо документи», а ініціатор отримує нагадування через обумовлений строк. Якщо документи приходять через сервіс електронного документообігу, їх можна прикріпити до заявки автоматично за номером рахунку. Як ШІ читає накладні й акти, ми розібрали в статті про автоматизацію роботи з документами.

IT-helpdesk у Telegram без окремого порталу

Типові сценарії: доступ, техніка, VPN, програми

Доступ до сервісу. Новий співробітник пише: «мені потрібен доступ до пошти і до спільного диска». Бот створює заявку, записує ім’я, відділ і сервіси та надсилає IT-фахівцю. Якщо доступ потребує згоди керівника, бот спершу питає керівника, і лише після «так» заявка йде в роботу. Коли IT закриває заявку, співробітник отримує повідомлення.

Проблема з технікою. «Ноутбук дуже гальмує». Бот класифікує заявку: IT, техніка, середній пріоритет. Одразу дає коротку інструкцію з бази знань: перезавантажити, закрити зайве, перевірити оновлення. Якщо не допомогло, співробітник натискає «не допомогло», і заявка йде фахівцю вже з відповідями на перші питання.

VPN або віддалений доступ. Бот видає інструкцію з підключення і паралельно відкриває заявку. Вирішилось — співробітник закриває її сам. Ні — IT отримує сповіщення з описом того, що вже пробували.

Програми й ліцензії. «Потрібен графічний редактор для макетів». Платна програма — це вже не лише IT-заявка, а й заявка на оплату. Бот це бачить, питає керівника і після погодження створює пов’язану заявку на оплату ліцензії. Зв’язка «IT плюс оплата» — найчастіший випадок, де одна система краща за дві окремі.

Якщо окремого IT-фахівця немає

У компаніях без IT-відділу технічні питання вирішує хтось «між справою» або зовнішній підрядник. Тут бот корисний ще більше. Заявки не розсипаються по особистих повідомленнях, а підрядник отримує їх уже з описом та історією. З ним можна домовитися про час реакції і бачити, чи він його дотримується.

Частину питань бот закриває без людини, з бази знань. З чого почати базу: пароль гостьового Wi-Fi, як підключити принтер, інструкція до VPN, як відновити пароль до пошти, куди зберігати файли, що робити, якщо не працює телефонія. Кожну відповідь пише відповідальна людина, а не ШІ: бот лише знаходить потрібну і переказує простими словами.

SLA всередині компанії: приклад налаштування

SLA (Service Level Agreement) — домовленість про час реакції і виконання. У більшості малих компаній внутрішнього SLA немає зовсім: заявку виконують «коли руки дійдуть». Почніть із простих рівнів. Нижче приклад, а не норма: строки підбирайте під свою команду.

Рівень	Приклад	Реакція	Що робить система при простроченні
Критичний	Немає інтернету в офісі, не працює касова програма	30 хвилин	Повторне сповіщення фахівцю і керівнику, дзвінок
Високий	Людина не може працювати	2 години	Нагадування фахівцю, потім керівнику
Середній	Робота йде, але незручно	Той самий день	Нагадування фахівцю
Низький	Питання, новий доступ, побажання	1–2 робочі дні	Потрапляє в тижневий звіт

Рівень обирає співробітник кнопкою або бот пропонує сам за текстом. Фахівець може змінити рівень. Через місяць подивіться, скільки заявок були «критичними». Якщо майже кожна — критерії розмиті, і їх треба переписати конкретніше.

Статус без питань «ну як там?»

Питання про статус забирають час обох сторін. Фахівець відривається, перевіряє, відповідає, а потім те саме ще раз. Бот прибирає це двома способами. Перший — сповіщення при кожній зміні: взято в роботу, чекаємо деталь, виконано. Другий — команда «мої заявки»: співробітник бачить усі свої відкриті заявки з відповідальним і очікуваним терміном. Фахівець отримує лише нові заявки і підтвердження виконання.

АГЧ: адмін-заявки без завгоспа-диспетчера

Типові заявки і правила призначення

Адміністративно-господарська частина часто найменш упорядкована. Запити приходять усно, у загальний чат, у коридорі. Типові:

канцтовари, витратні матеріали, вода, кава, побутова хімія;
ремонт меблів, техніки, кондиціонера, сантехніки;
перепустка для гостя чи нового співробітника;
переміщення майна між офісами чи складами;
бронювання переговорної, ключі, паркування.

Правила призначення залежать від типу:

«Зламалось», «ремонт» — завгосп, а бот одразу питає його: «потрібен зовнішній майстер?». Якщо так, створюється пов’язана заявка на оплату послуг майстра.
«Перепустка» — завгосп і охорона одночасно, з іменем гостя і часом.
«Канцтовари», «витратні» — завгосп, із терміном до кінця наступного дня. Дрібні позиції збираються в одне замовлення на тиждень.

Якщо заявка на ремонт висить без оновлення кілька днів, бот нагадує завгоспу і водночас пише ініціатору, що заявка в роботі і чому затримка. Людина бачить, що про неї не забули, і не йде з’ясовувати це особисто.

Журнал замість блокнота

Усі заявки автоматично лягають у журнал: дата, ініціатор, тип, опис, виконавець, дата закриття, коментар і сума, якщо була оплата. Через місяць у завгоспа й власника є відповіді на питання, які раніше ніхто не міг навіть поставити: що повторюється, що забирає найбільше часу, на що йдуть гроші.

Що робити з журналом:

Знайдіть позиції, які замовляють щомісяця: воду, папір, картриджі. Переведіть їх на поповнення за графіком, а не за заявкою.
Подивіться, яке обладнання ламається повторно. Три ремонти одного кондиціонера — привід порахувати заміну.
Порівняйте ціни однакових закупівель у різні місяці. Якщо ціна росте, а постачальник той самий, час попросити пропозиції в інших.

HR: відпустки, довідки й типові питання

Про кадрове адміністрування загалом ми писали в статті про автоматизацію HR. Тут — лише те, що проходить через спільний бот заявок.

Заявка на відпустку: від повідомлення до наказу

Без системи відпустка — ланцюжок пересилань: співробітник, HR, керівник, знову HR, бухгалтерія. Кожен крок може загубитися. З ботом:

Співробітник пише: «хочу у відпустку з 22 по 26 грудня».
Бот розпізнає дати і, якщо підключено кадровий облік, показує залишок днів відпустки.
Керівник отримує заявку в Telegram разом із графіком свого відділу на ці дати — видно, хто ще буде відсутній, — і натискає «погодити» чи «перенести».
HR отримує погоджену заявку для наказу, бухгалтерія бачить її для розрахунку відпускних.
Співробітник отримує статус на кожному кроці.

Наказ і підписи за кадровим законодавством лишаються за HR. Бот прибирає пересилання і питання «ну що там з моєю відпусткою?».

База відповідей на типові питання

Більшість питань до HR повторюються: як оформити лікарняний, коли виплата, де бланк заяви, як отримати довідку з місця роботи, хто відповідає за медичне страхування. Відповіді записуються один раз у базу знань. Бот відповідає на них будь-коли, а HR бачить, які питання бот закрив сам, а які передав людині.

Приклад відповіді: «Лікар оформлює медичний висновок, на його основі формується електронний лікарняний. Повідомте в цьому боті дати, щоб керівник знав про вашу відсутність, а HR перевірить лікарняний у кабінеті роботодавця. Інше питання — напишіть “HR”». Відповіді в базі пише і перевіряє HR. Якщо відповіді в базі немає, бот передає питання людині, а не вигадує.

Онбординг через той самий бот

Перший тиждень нового співробітника — потік питань: де що лежить, як отримати доступи, до кого з чим іти. Бот бере частину цього на себе:

у день виходу надсилає вітальне повідомлення з чеклістом першого дня: документи, доступи, контакти;
ще до виходу людини автоматично створює заявки до IT на доступи і до АГЧ на робоче місце та перепустку;
відкриває наступні кроки поступово: перший день, перший тиждень, перший місяць;
відповідає на питання з бази знань, а невідомі передає HR.

Сенс у зв’язці: одна подія «новий співробітник» запускає заявки в трьох відділах, і жодна не залежить від того, чи хтось згадав. Детальніше — у статті про автоматизацію онбордингу.

Чутливі дані: що не просити в чаті

Telegram-бот отримує повідомлення через сервери Telegram. Неотримані ботом оновлення Telegram зберігає не довше 24 годин (Telegram Bot API), але саме листування з ботом лишається в історії чату, як будь-яке повідомлення. Тому правило таке: бот приймає опис заявки, а паспортні дані, медичні документи чи банківські реквізити співробітника — лише через захищену форму в системі з доступом за роллю. Бот дає посилання на форму, а в чаті лишається тільки номер заявки.

Як влаштований один бот для всіх відділів

Ключова перевага — один бот замість чотирьох контактів. Співробітнику не треба пам’ятати, кому писати. Є один корпоративний бот, наприклад @company_help_bot, і він сам вирішує, куди йде заявка.

Кнопки чи ШІ-розбір: коли що

Сценарний бот — це меню з кнопками: «IT» → «техніка» → «ноутбук». Його легко зробити, і для заявок на оплату кнопки на старті корисні: вони гарантують, що ініціатор обере статтю витрат. Але якщо заявка не вписується в кнопки, людина закриває бота і пише в особисті.

ШІ-розбір дозволяє писати довільним текстом, голосовим чи фото. Бот визначає відділ, тип і пріоритет та заповнює картку. Практичне правило: кнопки — для полів, де помилка дорога (стаття витрат, терміновість), довільний текст — для опису. Найкраще працює поєднання: людина пише як звикла, а бот показує розпізнані поля з кнопками «так» і «виправити».

Маршрутизація: правила, впевненість і перепитування

Порядок обробки повідомлення:

Бот отримує текст, голосове або фото.
ШІ визначає відділ (оплата, IT, АГЧ, HR), тип заявки і оцінює, наскільки він упевнений.
Якщо впевнений, заявка йде відповідальному за правилами цього типу.
Якщо ні, бот перепитує: «Це питання до IT чи до адміністративного відділу?» Одне питання з кнопками краще, ніж неправильна маршрутизація.
Заявка записується в базу з усіма деталями та історією змін.

Перший місяць хтось має переглядати заявки, які бот перепитував або які виконавці перекинули в інший відділ. Це матеріал для уточнення правил і бази прикладів. Через кілька тижнів таких заявок стає помітно менше.

Кожен виконавець бачить лише свої заявки. IT-фахівець не бачить HR-запитів і сум оплат. Власник бачить усе і загальну статистику за відділами.

Ескалація: два рівні

Без ескалації автоматизований helpdesk лише акуратніше записує те, що потім однаково зависає. Мінімум, який варто налаштувати з першого дня:

Рівень 1 — звичайний режим:

нова заявка — сповіщення відповідальному;
зміна статусу — сповіщення ініціатору;
наближення терміну — нагадування відповідальному.

Рівень 2 — ескалація:

термін минув — сповіщення керівнику відділу;
критичну заявку не взяли в роботу вчасно — повторне сповіщення і дзвінок;
заявку на оплату з терміном «сьогодні» не погодили до обіду — сповіщення власнику.

Як налаштувати нагадування, щоб вони не перетворилися на шум, ми розібрали в статті про штучний інтелект в управлінні підприємством.

Де зберігати заявки: таблиця чи система

Google Sheets чи Notion як база заявок працюють на старті: безкоштовно і всім знайомо. Обмеження видно, щойно додаються погодження оплат. У таблиці важко розмежувати доступ: бухгалтер не має бачити кадрові заявки, а IT — суми оплат. Немає надійної історії, хто що змінив, і будь-хто може випадково стерти рядок.

Поріг простий. Поки через бот ідуть лише заявки до IT і АГЧ, таблиці досить. Щойно через систему йдуть гроші, потрібні ролі, журнал змін і щоденні резервні копії.

Що обрати: чат, таблиця, helpdesk, облікова програма чи своя система

Варіант	Коли підходить	Чого бракує
Чат у месенджері	До 10 людей, оплати погоджує і робить сам власник	Статусів, історії, контролю термінів
Google Форма і таблиця	Простий потік заявок до IT і АГЧ, оплат мало	Ролей, погоджень із порогами, банку
Helpdesk: Jira Service Management, Zendesk	Багато IT-заявок, окрема служба підтримки	Telegram як основного входу, маршруту оплат, українських документів
Модуль погодження в обліковій програмі, наприклад BAS	Бухгалтерія вже живе в програмі, команда до неї звикла	Зручного входу для всіх співробітників, заявок до IT, АГЧ і HR
Своя система з ботом	Telegram — основний канал, потрібні оплати і заявки кількох відділів в одному місці	Потрібен опис процесу і хтось, хто систему збере

Критерії вибору:

Хто подає заявки? Якщо всі співробітники, вхід має бути там, де вони вже є. Найчастіше це Telegram.
Чи йдуть через заявки гроші? Якщо так, потрібні пороги, ролі, журнал змін і зв’язок із банком.
Скільки типів заявок? Один тип — підійде готовий інструмент саме для нього. Три-чотири відділи — вигідніша одна точка входу.
Чи є облікова програма, з якою треба працювати? Тоді система має передавати їй дані, а не замінювати її.

Якщо вагаєтеся між готовою програмою і своєю системою, пройдіть тест «готова програма чи своя система» — він займає кілька хвилин. Ширше про те, які процеси автоматизувати першими і якими програмами, — у статті автоматизація бізнес процесів.

Як порахувати, чи окупиться автоматизація заявок

Формула

Місячна вартість ручної обробки = (заявки за місяць × хвилини ручної роботи на одну заявку ÷ 60) × вартість години + вартість помилок.

У «хвилини ручної роботи» входять пошук рахунку, перепитування ініціатора, пересилання погоджувачу, нагадування, внесення платежу в банк, відповіді на питання про статус і пошук закриваючих документів. Рахуйте час усіх учасників, а не лише бухгалтера.

У «вартість помилок» входять подвійні оплати, пені й втрачені знижки через прострочку, простої через неоплачений рахунок і години на розбір конфліктів.

Розібраний приклад

Приклад умовний, вихідні дані — з відкритих джерел. Середня зарплата бухгалтера в Україні на Work.ua — 32 000 грн на жовтень 2026 року (Work.ua). Додаємо єдиний внесок роботодавця 22% (Закон № 2464-VI) — виходить 39 040 грн. Ділимо на 168 робочих годин на місяць — близько 232 грн за годину.

Умовна компанія отримує 120 заявок на оплату на місяць. На кожну бухгалтер витрачає 10 хвилин: перепитати, знайти рахунок, внести платіж у банк, відповісти про статус. Це 1 200 хвилин, тобто 20 годин, або близько 4 640 грн на місяць лише часу бухгалтера (Work.ua, єдиний внесок за законом). До цього додайте час керівників на погодження в чатах і час власника на питання «а що ми сьогодні платимо?».

Внутрішні заявки до IT, АГЧ і HR порахуйте так само. Тиждень записуйте кожен запит і час на нього. Окремо позначайте, скільки разів хтось питав статус. Тиждень записів покаже, чи не забирають питання «ну як там?» більше часу, ніж виконання дрібних заявок.

Що не потрапляє у формулу, але коштує грошей

Подвійна оплата. Одна така помилка може перекрити місячну економію часу. Повернення від контрагента — це листи, дзвінки й акт звірки.
Оплата на підмінені реквізити. Такі гроші часто не вдається повернути взагалі. Перевірка реквізитів — найдешевше страхування.
Прострочений рахунок ключового постачальника. Затримана поставка і зірвані терміни для ваших клієнтів.
Залежність від однієї людини. Коли бухгалтер чи завгосп у відпустці, без системи ніхто не знає, що в роботі.

Рішення не ухвалюють за однією цифрою. Якщо часу на заявки йде небагато, але були подвійні оплати чи прострочки, автоматизація все одно має сенс. Якщо часу йде багато, а помилок немає, почніть з одного найповільнішого кроку.

Типові помилки і коли автоматизація не потрібна

Зробили бота — не змінили правило

Бот готовий, а через місяць частина команди досі пише в особисті, бо так звично. Рішення — правило для виконавців, а не для всіх. Бухгалтер, IT-фахівець, завгосп і HR не беруть заявки з особистих повідомлень і ввічливо відповідають: «перешліть, будь ласка, боту, щоб не загубилось». Перші тижні найважчі. Власник має сам подавати заявки через бот, інакше правило не втримається.

Автоматизували один відділ, решта лишилась у чатах

Якщо через бот іде тільки IT, а оплати і господарські питання — у чатах, люди плутаються, куди що писати. Краще одразу запустити одну точку входу для всіх відділів, навіть якщо функцій на старті мінімум. Якщо ресурсу немає, почніть з одного відділу, але одразу оголосіть, коли підключаться інші.

Погодження без порогів

Власник погоджує кожну оплату, бо «так надійніше». Через тиждень він погоджує не читаючи, а заявки чекають на нього годинами. Пороги з таблиці вище повертають власнику лише ті оплати, де його рішення справді потрібне.

Немає ескалації

Бот приймає і записує заявки, але якщо виконавець захворів, заявка висить днями. Мінімальна ескалація налаштовується за кілька годин і закриває цю дірку.

Заявку на оплату закривають самою оплатою

Гроші пішли, заявку закрили — акт так і не прийшов. Закриття можливе тільки з документом або з явним рішенням «документ не потрібен».

Коли автоматизація не потрібна

Команда до 10 людей, оплати погоджує і робить сам власник, IT-заявок кілька на місяць. Досить одного чату з правилом «одна заявка — одне повідомлення».
Заявок мало, і вони однотипні. Вистачить Google Форми і таблиці.
У компанії вже працює helpdesk-система, і люди нею користуються. Не міняйте те, що працює. Додайте лише те, чого бракує, наприклад погодження оплат.
Процес оплат щомісяця змінюється, бо компанія перебудовується. Спочатку домовтеся про правила, потім автоматизуйте.

Як ми запускаємо таку систему

Порядок робіт

Directoria будує ШІ-систему управління бізнесом під процеси компанії: заявки з етапами, погодження, документи, оплати, задачі й сповіщення в Telegram, звіти. Код пише штучний інтелект під контролем архітектора. Архітектор описує процес і критерії готовності, ШІ-агент пише код і тести, людина перевіряє на реальних заявках. Тому перша робоча версія готова за кілька днів, а не місяців.

Розмова й демо — 30 хвилин, безкоштовно. Показуємо робочу систему на вигаданих даних.
Опис процесу — 1 тиждень. Маршрути заявок, пороги погодження, ролі, статті витрат, SLA, тексти сповіщень. Як підготувати такий опис самостійно, ми розповіли в статті про програми для опису бізнес-процесів.
Запуск — 2–4 тижні. Перша версія за кілька днів, далі модулі по одному: заявки на оплату, IT, АГЧ, HR. Два тижні система працює паралельно зі старим способом, щоб під час переходу нічого не загубилось.
Підтримка й розвиток. Нові модулі — за фіксованою ціною.

Система належить вам: код і дані — ваші. Ставимо на ваш сервер або на наш, із передачею будь-коли. Резервна копія — щодня. Інтерфейс — українською або російською.

Що ми перенесли з власної системи Saloy

Saloy — наша компанія з виробництва на верстатах з ЧПК. Перша робоча версія її системи управління була готова за 1 день, усі модулі — за 3 тижні. Кілька рішень звідти прямо застосовні до внутрішніх заявок:

Telegram як основний інтерфейс. Вхід через Telegram, сповіщення і задачі там, де команда вже працює. Окремого порталу ніхто не відкриває.
Попередження, а не блокування. Коли замовлення з відкритими питаннями намагаються перевести у виробництво, система Saloy попереджає, а не блокує. Так само із заявками на оплату: перевищений ліміт чи змінені реквізити піднімають заявку на рівень власника, а не зупиняють роботу.
Ролі. У Saloy три ролі — власник, менеджер, виробництво, і прибуток бачить лише власник. У заявках так само: суми оплат бачать лише ті, кому це потрібно.
Нагадування замість пам’яті. ШІ-асистент Saloy у призначений день пише клієнту в Telegram, розбирає відповідь і записує її в картку, а якщо відповідь неясна — перепитує. Та сама механіка нагадує ініціатору про акт після оплати.
Контроль версій і бекапи з першого дня. Одного разу оновлення зі старої копії затерло свіжий модуль, і його відновлювали вручну. Для системи, через яку йдуть оплати, це правило обов’язкове.

Детальніше — у кейсі власної системи управління. Інші процеси, які варто перевести в систему, зібрані в прикладах автоматизації бізнес процесів підприємства. Якщо йдеться про заявки від клієнтів, а не внутрішні, дивіться сторінку про автоматизацію заявок і замовлень від клієнтів.

Часті питання

Що таке автоматизація заявок на оплату простими словами? Кожна заявка оплатити рахунок проходить однаковий шлях. Ініціатор надсилає рахунок у бот, система заповнює поля і перевіряє дублі та реквізити, погоджувачі натискають кнопку в Telegram залежно від суми, а бухгалтер отримує готовий реєстр або чернетку платежу в банку. Людина вирішує і підписує, система переносить дані й нагадує.

Чи потрібна окрема helpdesk-система, якщо є Telegram-бот? Для компанії до 100 людей зазвичай ні, якщо бот працює разом із базою заявок, ролями й ескалацією. Окрема helpdesk-система виправдана, коли є служба підтримки з кількома лініями, великий потік IT-заявок і потрібні складні звіти. Заявки на оплату в ній однаково доведеться налаштовувати окремо.

Що робити, якщо співробітник пише не боту, а в особисті? На старті це неминуче. Виконавці не беруть заявки з особистих і просять переслати боту. Виняток — критичні ситуації, де потрібна негайна реакція. Але й тоді заявку потім записують у бот, щоб вона лишилась у журналі.

Якщо у вас заявки на оплату, IT, господарські й кадрові питання живуть у чатах, опишіть, як зараз іде одна оплата — від рахунку до платежу. Покажемо систему на демо за 30 хвилин і чесно скажемо, що вам вигідніше: таблиця, готова програма чи своя система. Детальніше — ШІ-система управління бізнесом.