Кейс: бот обліку змін і сайт для Profline Group

Це найдовший кейс із наших — і єдиний, де замовлення не закінчилося здачею. Profline Group, українська компанія з підбору персоналу, замовила Telegram-бот для обліку змін. Через кілька місяців ми були технічною службою компанії: правки в бекенді того ж дня, розбори інцидентів на живих даних, сайт на чотирьох мовах. Нижче — як разова задача стала постійною роллю, що ламалося дорогою і де ми сказали клієнту «ні».

Три етапи, а не три замовлення

Profline постачає персонал на логістичні майданчики — депо й термінали в Києві, Одесі, Львові, Броварах, Вінниці, Житомирі, Луцьку, Рівному, Тернополі, Хмельницькому, Чернівцях. Люди виходять на зміни, отримують перепустку-бейдж, відпрацьовують години й отримують оплату. До бота це жило в переписках, голосових і таблицях.

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

Що робить бот

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

• Пул бейджів — облік фізичних перепусток: хто взяв, коли повернув, які вільні. Іменний бейдж автоматично повертається в пул після пʼяти днів без активності.
• Табелі в Excel за наявним шаблоном замовника: період одним днем, діапазоном або «останні 7 днів», зведення по всіх локаціях із колонкою «Локація».
• Нагадування й нуджі — за годину до зміни з кнопками «Я буду» / «Я не прийду»; окрема джоба помічає, що зміна почалася, а старт не натиснуто.
• Звіт по рекомендаціях — хто скільки людей привів і скільки з них реально вийшло на зміни.
• Черга заявок, рознесена по трьох топіках: активні, видані бейджі, архів. До цього все лежало в одному потоці й змішувалося.

Загальний підхід до таких задач ми розбирали окремо — у матеріалі про Telegram-ботів для бізнесу і в тексті про автоматизацію бізнес-процесів.

Розмова, у якій ми сказали «ні»

У червні клієнт прийшов із великою ідеєю: власна CRM. Усі месенджери в одному вікні, вхідні з майданчиків вакансій, телефонія з карткою кандидата на вхідному дзвінку, внутрішні відеодзвінки, дзеркалення робочих Viber-груп, керування Telegram-групами не виходячи із системи, табелі, кабінет працівника, аналітика по кожному менеджеру. Можна було погодитися й почати писати. Замість цього ми розклали список на три категорії й повернули його з позначками.

1. 1

   Зелене — робиться, база вже є

   Вхідні з Telegram у CRM, база кандидатів і воронка статусів, закріплення за менеджером, міста й локації, розсилки за таймером, табелі, кабінет працівника, аналітика, виплати. Усе це вже частково жило в боті, тож переносилося з високим рівнем перевикористання.

2. 2

   Жовте — можливо, але через третіх

   Телефонія — не «Київстар напряму», а Binotel або Ringostat: у них є API й вебхуки, звідти беруться дзвінки з CRM, записи, історія та спливання картки кандидата. Оператор підключається вже до них, і починати варто з одного провайдера.

3. 3

   Червоне — офіційного способу немає

   Viber Bot API не дозволяє читати чужі групові чати, тож «дзеркалити» робочі Viber-групи в CRM легально нічим. Майданчики вакансій віддають переписку через партнерські або закриті API, а скрейпінг — це порушення умов і крихка конструкція. Керування Telegram-групами «як людина» потребує роботи через MTProto замість Bot API, що суперечить правилам Telegram і ризикує акаунтом.

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

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

Коли код не може полагодити проблему

У липні прийшла скарга: на одному з депо люди беруть зміну, а в табелі їх немає. Найпростіше було б списати на баг обліку. Ми пішли в дані.

На всі локації, крім однієї, працювало сорок чотири реальні бейджі. За добу з них зробили сто видач — тобто кожен бейдж обертався приблизно двічі з половиною на день. Девʼять бейджів за день видали кільком людям поспіль, один — чотирьом. А далі знайшлося те, що не могло бути правдою фізично: один і той самий бейдж за день «побував» на двох різних депо — о 06:55 на одному, о 09:55 на іншому, ввечері знову на першому.

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

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

Помилка, яка брехала

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

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

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

Оплати без жодного нового інтерфейсу

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

1. 1

   Повідомлення за шаблоном

   Дані на оплату публікуються в чаті у вільній формі, з однією обовʼязковою умовою — рядком із сумою. Решта полів оформлюється як зручно.

2. 2

   Реакція замість кнопки

   Хто оплатив — ставить на повідомлення будь-яку реакцію. Бот записує, хто саме, скільки й коли, і відповідає власною позначкою: вона означає «зараховано».

3. 3

   Скасування — зняти реакцію

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

4. 4

   Звіт однією командою

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

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

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

Сайт: четвертою мовою — урду

Третій етап — маркетинговий сайт: Next.js із серверними компонентами, Payload CMS, PostgreSQL, розгортання через Coolify за Cloudflare, медіа в обʼєктному сховищі, захист форм від ботів. Дошка вакансій — фасетна, зі структурованими даними JobPosting, щоб вакансії потрапляли в Google Jobs. Пошук схований за інтерфейсом: зараз працює на PostgreSQL, підключення Meilisearch міняє одну змінну оточення й не зачіпає UI.

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

Вимоги надходили не документом, а голосовими: прибрати анімацію, яка збільшує блок і ховає меню; полагодити картку вакансії, де довга назва лізе на фон; додати вибір статі й віку у форму; закласти структуру під усі міста, а не лише Київ. Це нормальний спосіб роботи з замовником, який щодня в операційці, а не в макетах.

Відгук замовника

Статус проєкту

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

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

Часті питання про цей проєкт

Коротко

• Замовлення на один Telegram-бот для обліку змін переросло у три етапи: бот, постійна технічна модерація, маркетинговий сайт.
• На запит про велику власну CRM ми повернули список із трьома категоріями й прямо назвали те, що офіційно неможливе: дзеркалення чужих Viber-груп і читання переписки з майданчиків вакансій.
• Скарга на облік змін виявилася нестачею фізичних перепусток: сорок чотири бейджі обслуговували сто видач на добу, і код цього полагодити не міг.
• Помилка «немає вільних бейджів» брехала не про кількість, а про область видимості: прив’язка одного бейджа мовчки відрізала локацію від загального пулу.
• Облік виплат зробили реакціями на повідомлення в наявному чаті — без нового інтерфейсу й без навчання персоналу.
• Підрахунок зарплати на прохання клієнта прибрали: цифра в боті провокувала суперечки замість прозорості.
• Сайт запущений на чотирьох мовах, включно з урду справа наліво; цифр по конверсії поки немає, і ми їх не вигадуємо.