Диспетчер відкриває помічник планування, щоб знайти виконавця для термінового ремонту, і бачить один-єдиний варіант: сертифікованого техніка за дві години їзди. Його колега, який перебуває за десять хвилин від об’єкта, має таку саму сертифікацію, але її ніхто не прив’язав до його запису ресурсу — тож помічник його так і не запропонував. Планування в Dynamics 365 Field Service працює рівно настільки добре, наскільки якісні дані про ресурси, вимоги та бронювання, на які воно спирається. У цьому посібнику — що саме змоделювати ще на етапі впровадження, до запуску будь-якого інструмента планування.

У Microsoft Dynamics 365 Field Service планування розподілене між двома рівнями. Field Service визначає, що потрібно зробити і де; Universal Resource Scheduling — хто може виконати роботу і коли. Кожен наряд на роботу (work order) автоматично створює вимогу до ресурсу (resource requirement), і саме цю вимогу бронюють на конкретного техніка.

Диспетчери мають три способи зіставити вимоги з людьми. Дошка планування (Schedule Board) призначена для ручного бронювання й підходить для аварійних робіт або нескладних завдань. Помічник планування (Schedule Assistant) пропонує час і ресурси для окремого завдання, а диспетчер обирає один із варіантів. Для великих обсягів є надбудова Resource Scheduling Optimization: вона планує одразу багато завдань відповідно до ранжованих цілей. Scheduling Operations Agent, який наразі доступний у preview, оптимізує розклад одного чи кількох техніків просто з дошки планування або з бічної панелі Copilot.

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

Вимога успадковує від наряду назву, місцезнаходження, тривалість та інші атрибути, а подальші зміни в наряді автоматично переходять і в неї. Окремої уваги потребує тривалість. Якщо в наряді немає сервісного завдання (service task) чи типу інциденту (incident type), він отримує тривалість бронювання за замовчуванням, проте вимога не переносить це значення у власне поле Duration. Типи інцидентів працюють як шаблони нарядів, тож реалістична тривалість у їхніх налаштуваннях — це частина роботи з планування, а не наведення порядку в довіднику.

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

Ресурси для бронювання (bookable resources) містять поля, на основі яких інструменти планування виконують розрахунки. Кожен ресурс має власний часовий пояс (Time Zone), а поля Start Location і End Location повідомляють системі, де починається і де закінчується його робочий день. Якщо обрати значення Location agnostic, час на дорогу до першого бронювання й від останнього не розраховується взагалі. Маршрутизація, оцінка часу в дорозі та відображення на мапі теж залежать від коректних геокодованих адрес.

Доступність визначають робочі години. Помічник планування показує лише ті ресурси, що мають вільну потужність у межах робочих годин, і пропускає будь-який ресурс, у якого параметр Enable for Availability Search має значення No. Потужність (Capacity) за замовчуванням дорівнює 1; значення 0 виключає ресурс із пошуку доступності.

Навички зберігаються в тому самому записі. Характеристики бувають двох типів: Skill — навичка, яку оцінюють за моделлю рейтингу, і Certification — підтверджена кваліфікація, яку ресурс здобув. У нарядах зазначено характеристики, потрібні для роботи, і диспетчери зіставляють їх із тим, що має кожен технік. Розширені характеристики (enhanced characteristics), які наразі в preview, додають до сертифікації дату видачі та дату завершення дії. Профіль ресурсу доповнюють призначені території.

Автоматизоване планування додає правила, без яких ручне бронювання цілком обходилося. Для Scheduling Operations Agent кожен статус бронювання має параметр Optimization Method — його описано в документації з налаштування Scheduling Operations Agent. Значення Optimize дозволяє агенту переносити або видаляти бронювання з цим статусом, Do Not Move зберігає час прибуття, а Ignore дозволяє агенту бронювати поверх нього — саме його Microsoft рекомендує для скасованих бронювань. Якщо поле залишити порожнім, агент розглядатиме кожне бронювання з таким статусом як Do Not Move, тож за неналаштованих статусів йому майже нічого змінювати.

Пріоритети потребують такої самої уваги. Агент зчитує Priority Value в діапазоні від 1 до 100 і не враховує поле Level of Importance. Microsoft радить задавати значення, які чітко відрізняються між собою, але лежать у вузькому діапазоні: якщо Low дорівнює 1, Medium — 10, а Emergency — 100, аварійні роботи потраплять у результат майже незалежно від того, наскільки неефективним буде таке розміщення.

Крім того, агенту потрібні увімкнені налаштування локації та мап, значення Yes у полі Display on schedule board для кожного ресурсу, який він має враховувати, а також дві призначені ролі безпеки.

Microsoft рекомендує впроваджувати планування в Dynamics 365 Field Service поетапно: спершу ручне планування на дошці, щоб усталити бізнес-процеси; потім помічник планування; далі — Resource Scheduling Optimization, починаючи з оптимізації для одного ресурсу. На кожному етапі дані спочатку проходять через диспетчера і лише потім від них починає залежати автоматичний запуск.

Агент змінюється швидко. Публічна preview-версія розширила його можливості до 5 ресурсів із дошки планування та до 30 — через план оптимізації (Microsoft 365 Message Center, MC1392246, червень 2026 р.); 30 вересня 2026 року додалися регулярні запуски, які застосовують розклад автоматично (MC1476008). Microsoft зазначає, що функції в preview не призначені для робочого середовища, тож пілоти варто планувати з урахуванням цього.

Відрізняється й модель оплати. Вартість Resource Scheduling Optimization залежить від кількості ресурсів, що оптимізуються, тоді як Scheduling Operations Agent витрачає кредити Copilot Studio, і їхня кількість зростає разом із кількістю ресурсів у кожному запиті.

І нарешті — призначте відповідального. Microsoft описує нову роль аналітика з планування, який відповідає за охоплення, цілі та параметри оптимізації. У плануванні Field Service ці налаштування втілюють бізнес-пріоритети — і хтось має визначити їх до першого автоматичного запуску.

OntargIT впровадила Dynamics 365 Field Service та Dynamics 365 Customer Service для KTS Engineering — інжинірингової компанії, що працює з розподіленою генерацією, і автоматизувала планування виїздів та обробку сервісних звернень. Як Microsoft Solutions Partner — AI Business Solutions, OntargIT реалізувала 150+ проєктів для 140+ клієнтів у 24 країнах.

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