Виїзд працівника, підтверджений адресою, актом та історією правок
Кейси

Виїзд працівника, підтверджений адресою, актом та історією правок

Завдання

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

Рішення

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

Результат

Зарплата рахується за закритими й підтвердженими фактами - виїздами, дорогою й актами, і керівник зі співробітником мають одну перевірювану історію із зафіксованими правками.

Запис у розкладі ще не доводить, що роботу виконано

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

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

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

Один виїзд починається із заявки або договору

Візьмемо звичайний візит до клієнта. Він з'являється одним із двох способів: клієнт залишає заявку або настає дата планового обслуговування за договором. Керівник обирає виконавця й призначає виїзд на конкретний день. Працівник бачить адресу та час у своєму розкладі.

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

На об'єкті є два способи відзначитися

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

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

Ручний варіант не маскується під автоматичну перевірку: в історії видно, яким способом підтвердили конкретний візит. Це дозволяє зберегти робочий процес без зв'язку й водночас не видавати дзвінок диспетчеру за геопозицію пристрою.

Дорога між клієнтами стає частиною розрахунку

Робота виїзного працівника складається не лише з часу на об'єкті. Між двома адресами він їде, і договір може окремо враховувати кілометри та час у дорозі.

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

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

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

Клієнт підтверджує не лише присутність, а й результат

Координати показують, що телефон опинився поруч з об'єктом. Вони нічого не кажуть про виконану роботу. Тому перед тим, як піти, працівник заповнює акт: відзначає, що зробив, і отримує підпис клієнта.

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

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

Закритий виїзд не можна виправити заднім числом

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

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

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

Зарплата збирається із закритих фактів

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

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

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

Один сигнал може помилитися, кілька дають контекст

Найважча частина системи - довести фізичну присутність людини за межами офісу. Єдине цифрове джерело на об'єкті - телефон самого працівника, а його геопозиція та зв'язок не гарантують ідеальної точності.

Тому портал не будує довіру на одному сигналі. Кожен механізм відповідає на своє питання й компенсує слабкі сторони решти.

Підтвердження Що воно показує Чого не доводить саме по собі
Геопозиція застосунку Телефон перебував у допустимому радіусі від адреси Що передбачену договором роботу виконано повністю
Дзвінок диспетчеру Візит зафіксовано без застосунку чи інтернету Точне положення телефона за координатами
Акт із підписом клієнта Клієнт підтвердив перелічені в документі роботи Коректність маршруту та оплати дороги
Журнал змін Хто, що й коли змінював до закриття Фізичну присутність працівника на об'єкті

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

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

Де закінчується точність системи

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

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

Олександр

Олександр

Fullstack-розробник з 8+ роками досвіду - від промислової автоматизації та роботи з обладнанням до електронного документообігу і чат-ботів. Зараз фокус на прикладному ШІ - від RAG-платформ для діалогових ботів до комп'ютерного зору.

Знеособлений кейс

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