Field service: map the case and its visitsВыездной сервис: карта заявки и визитов
The customer wants a service case resolved, while dispatch manages individual visits. Treating them as the same object lets a finished visit close an unresolved problem. This map connects intake, assignment, on-site work and the customer outcome while keeping the reason for a return visit visible.Клиент ждёт решения своей заявки, а диспетчер управляет отдельными выездами. Если эти объекты смешать, завершённый визит закроет ещё не решённую проблему. Карта ниже связывает обращение, назначение, работу на месте и итог для клиента, сохраняя причины повторного выезда.
The case outlives an individual visitЗаявка переживает отдельный выезд
Give the case an identifier tied to the location, reported problem and promised result. Each visit needs its own time, assignee and outcome. Dispatch links a repeat report about the same problem after checking it; a matching phone number alone does not prove it is the same job.Заведите номер заявки для адреса, описания проблемы и обещанного результата. У каждого выезда должны быть собственные время, исполнитель и итог. Повторное обращение о той же проблеме связывают с исходной заявкой после проверки диспетчером; совпадение телефона само по себе не доказывает, что работа та же.
Define a response as a substantive acknowledgement with a next step, rather than an automatic receipt. Record the site contact, access conditions and acceptable window. Dispatch resolves gaps before promising a time; otherwise the technician receives an assignment that cannot actually be completed.Определите, что считается ответом на обращение: содержательное подтверждение и следующий шаг, а не автоматическая квитанция. В карточке нужны контакт на объекте, условия доступа и допустимое окно. Диспетчер уточняет пробелы до обещания времени, иначе мастер получает назначение, которое невозможно выполнить.
Four transitions with an ownerЧетыре перехода с владельцем
These are proposed operating rules for configuration. Case and visit states have different evidence: the technician accepts an assignment, the person doing the work records its result, and a service manager reviews a disputed outcome. Verify the implementation of transitions and exchanges with other systems separately.Это проект правил для настройки процесса. Статусы заявки и выезда меняются по разным основаниям: принятие задания подтверждает мастер, завершение работы описывает исполнитель, а спорный итог разбирает руководитель сервиса. Техническую реализацию переходов и обмен с другими системами проверяют отдельно.
A site service request arrivesПолучено обращение по объекту
- Responsible roleОтветственный
- Intake dispatcherДиспетчер приёма заявок
- Record / dataЗапись / данные
- Case record: site, problem, contact and promised outcomeКарточка заявки: объект, проблема, контакт и обещанный результат
- Permitted next stepРазрешённый следующий шаг
- Clarify access and set a response deadlineУточнить доступ и назначить срок ответа
- Exception / recoveryИсключение / восстановление
- Unclear site: request clarification rather than guessing a destinationНеясный объект: запросить уточнение, не создавать выезд наугад
The technician accepts the assignmentМастер подтвердил назначение
- Responsible roleОтветственный
- Visit dispatcherДиспетчер выездов
- Record / dataЗапись / данные
- Visit record with technician, window and case linkЗапись выезда с мастером, окном и ссылкой на заявку
- Permitted next stepРазрешённый следующий шаг
- Check access and issue the agreed partsПроверить доступ и выдать согласованные детали
- Exception / recoveryИсключение / восстановление
- Technician declines: return assignment to dispatch with the reasonМастер отказался: вернуть назначение диспетчеру с причиной
On-site work is recordedРабота на объекте зафиксирована
- Responsible roleОтветственный
- Technician responsible for this visitИсполнитель этого выезда
- Record / dataЗапись / данные
- Report: completed tasks, consumption, documents and remaining workОтчёт: сделанное, расход, документы и остаток работ
- Permitted next stepРазрешённый следующий шаг
- Submit the outcome for review or arrange a return visitПередать результат на проверку или оформить повторный визит
- Exception / recoveryИсключение / восстановление
- Wrong part: retain the visit record and open a replacement dependencyДеталь не подошла: сохранить факт визита и открыть ожидание замены
The case outcome is reviewedИтог заявки проверен
- Responsible roleОтветственный
- Service managerРуководитель сервиса
- Record / dataЗапись / данные
- Case outcome linked to every visit and supporting confirmationРезультат заявки со ссылками на все выезды и подтверждения
- Permitted next stepРазрешённый следующий шаг
- Close the resolved case and hand documents to billingЗакрыть решённую заявку и передать документы для расчёта
- Exception / recoveryИсключение / восстановление
- Customer disputes the outcome: assign a review and next response dateКлиент оспаривает итог: назначить разбор с датой следующего ответа
Keep unfinished work actionableЧто делать с незавершённой работой
If a part is missing, finish the report for the visit that occurred but leave the case waiting for that specific part. Record compatibility, quantity, purchasing ownership and the next update date. A warehouse reservation and a physical issue to a technician are different events; check current custody when rescheduling.Если детали нет, завершите отчёт о состоявшемся визите, но оставьте заявку в ожидании конкретной детали. Укажите совместимость, требуемое количество, владельца закупки и дату следующего обновления. Резерв на складе и фактическая выдача мастеру отражают разные события; при переносе проверьте, где деталь находится сейчас.
A replacement technician receives earlier observations and the remaining work list. They should not have to infer the return reason from messages. When access fails, dispatch agrees a new window and records why; calling that attempt successful would misstate both the customer promise and first-visit completion.Новый мастер получает предыдущие наблюдения и перечень оставшихся работ. Он не должен угадывать причину возврата по переписке. При отсутствии доступа диспетчер согласует новое окно и сохраняет причину; закрытие такой попытки как успешной исказит и обещание клиенту, и показатель выполнения с первого визита.
A return-visit acceptance testПроверка с повторным выездом
In a rehearsal, a technician accepts a case, arrives and finds that a different part is required. Dispatch assigns the return to another employee. Check that the first report stays available, the case remains open, the required part is linked to the new visit and the customer receives the current next step.Учебный сценарий: мастер принимает заявку, приезжает и обнаруживает, что нужна другая деталь. Диспетчер назначает повторный визит другому сотруднику. Проверьте, что первый отчёт остаётся доступен, заявка не закрыта, нужная деталь связана с новым выездом, а клиенту сообщён актуальный следующий шаг.
Resubmit the completion report after a connection delay. Acceptance requires one visit outcome, one parts consumption entry and a disputed customer response routed to the assigned manager. Treat an unclear payment state separately from evidence that the work was performed.Повторите отправку итогового отчёта после задержки связи. Приёмка проходит, если появляется один результат визита, расход детали учитывается один раз, а спорный ответ клиента возвращает заявку назначенному руководителю. Неясный статус оплаты рассматривайте отдельно от факта выполненной работы.
Response, first visit and unresolved casesОтвет, первый визит и открытые хвосты
Measure intake-to-substantive-response time, and separately the share of cases resolved in their first visit among cases whose first visit occurred in the chosen cohort. Set the repeat-report observation period in advance. Show cases that have not completed that period separately instead of declaring early success.Считайте время от поступления обращения до содержательного ответа и отдельно долю заявок, решённых за первый выезд, среди заявок с состоявшимся первым выездом в выбранной группе. Заранее задайте период наблюдения повторных обращений. Заявки, для которых он ещё не истёк, показывайте отдельно, без поспешного успеха.
Also show open cases without a next action and the reasons for return visits. This separates parts, access and workmanship problems. Start with one visit category and agree fields and roles before configuring SABSUS; the map does not promise a ready-made automation for a particular service business.Рядом показывайте число открытых заявок без следующего действия и причины повторных визитов. Эти данные помогают различать проблемы запчастей, доступа и качества работы. Начните с одного вида выездов и согласуйте поля и роли перед настройкой SABSUS; карта не обещает готовую автоматизацию конкретной службы.
Quick answersКороткие ответы
Can a visit close while its case stays open?Можно ли закрыть визит, не закрывая заявку?
Yes. A completed visit has its own report. If the promised result remains unmet, the case retains a waiting reason, owner and next action.Да. Состоявшийся выезд имеет собственный отчёт. Если результат не достигнут, у заявки остаются причина ожидания, ответственный и следующий шаг.
Who decides whether a repeat report is the same case?Кто решает, что повторное обращение относится к той же работе?
Dispatch checks the site and reported problem. Linking preserves history, but different faults should not be merged merely because the customer name matches.Диспетчер сверяет объект и содержание проблемы. Связь сохраняет историю, но не должна объединять разные неисправности только по имени клиента.
What should be checked before configuring visits in SABSUS?Что проверить в SABSUS до настройки выездов?
Check case versus visit identity, access to previous reports, parts records and repeated submissions. Validate the required fields and transitions using your own scenario.Разделение заявки и визита, доступ к прошлым отчётам, учёт деталей и обработку повторной отправки. Подтвердите нужные поля и переходы на своём сценарии.