AUT-0417· Виїзний сервіс
Контроль невдалого сервісного виїзду та повторного запису
Якщо спеціаліст не може виконати роботу на об’єкті, команда фіксує причину й доказ, зберігає заявку відкритою та погоджує наступний візит.
Чернетка · Оцінка потребує перевірки
01 / Проблема
Невдалий виїзд закривають як звичайну відмову або завершену роботу, через що губиться причина, клієнт не отримує наступного кроку, а диспетчер не повертає заявку в чергу запису.
02 / Результат
Спроба виїзду має стан «не виконано», зафіксовану причину та доказ; незавершена потреба залишається активною, клієнт отримує погоджене повідомлення, а повторний слот має відповідального й посилання на попередню спробу.
03 / Процес
ТригерСпеціаліст на місці реєструє, що не може почати або завершити заплановану роботу.
Зберегти первинне бронювання, час прибуття та пов’язану заявку; не позначати роботу виконаною.
Виконавець обирає перевірену причину: немає доступу, клієнта немає на місці, умови не підготовлено, потрібної частини немає або інша причина.
Додати короткий коментар і доступний доказ; не зберігати зайві чутливі дані чи фото без погодженого правила доступу.
Визначити, хто усуває причину, чи можна безпечно планувати повторний візит і які умови договору застосовуються до повторного виїзду.
За погодженим сценарієм повідомити клієнта про стан і потрібну дію; передати диспетчеру активну потребу з попередньою спробою в історії.
Після підтвердження клієнтом узгодити нове вікно й доступність спеціаліста; закрити контроль невдалої спроби лише після зв’язку з новим бронюванням або документованого скасування потреби.
04 / Реалізація1 варіант
Приклад · Зафіксована спроба й контрольований повторний запис
Майстер прибув у погоджене вікно, але представника клієнта немає на місці. Він фіксує час і причину без висновку про вину; заявка лишається активною, а диспетчер після контакту погоджує нове вікно.
Спосіб реалізації
- Гіпотеза для аудиту PlanFix: тип задачі для виїзду з контрольованими станами, полями причини й наступної дії, сценарієм на стан «не виконано» та фільтром диспетчера для активних потреб. Склад сценарію, доступів і календаря перевірити в цільовому акаунті.
- Якщо записи живуть в окремій системі, узгодити обмін ідентифікатором бронювання, результатом спроби та станом повторного запису; автоматичну синхронізацію перевірити окремо.
Що потрібно для реалізації
- Бронювання має окремі стани для завершення, скасування та невиконаної спроби; активна потреба відділена від конкретного запису в календарі.
- Погоджено список причин, мінімальний доказ, відповідального за повторний запис і правила клієнтських повідомлень.
- Договір і затверджений процес визначають, чи може повторний виїзд бути платним; автоматичне нарахування без перевірки заборонене.
- Є єдина черга активних сервісних потреб і журнал спроб виїзду.
- Визначено перелік причин, доступи до доказів і правило підтвердження повторного слота.
Обмеження
- Стани та повторний запис залежать від календаря, застосунку виконавця й налаштованих у цій системі статусів.
- Підтвердження статусу в Dynamics 365 Field Service не означає, що такі самі статуси є в PlanFix або в акаунті клієнта.
- Причину невдалого виїзду не можна автоматично трактувати як провину клієнта або підставу для оплати без перевірки доказів і умов договору.
- Календарний слот не гарантує, що клієнт підтвердив доступ або що технічна причина усунена.
- Умови оплати повторного візиту перевіряє відповідальний; картка не виставляє плату автоматично.
Що потрібно уточнити (2)
- Чи потрібно синхронізувати повторний запис із зовнішнім календарем або системою диспетчеризації?
Укажіть систему, джерело істини для вільних слотів, поля обміну й спосіб звірки скасування та нового бронювання.
- Чи потрібні окремі маршрути для кількох причин невдалого виїзду?
Наприклад, відсутність доступу, непідготовлений майданчик і відсутність деталі можуть мати різних відповідальних та умови повторного запису.