배차나 현장 작업이 바뀔 때마다 운영자는 담당 기사에게 다시 연락하고, 변경된 내용을 전달한 뒤, 누가 어디까지 처리했는지 확인해야 합니다. 이 과정을 앱으로 옮기려 할 때 가장 먼저 나오는 선택은 기사 화면입니다. 현장 기사가 작업을 보고 시작과 완료를 누르게 하면 혼선이 줄어들 것처럼 보이기 때문입니다.
하지만 작업 담당자와 내용이 자주 바뀌고, 운영자가 최신 지시를 받은 사람을 다시 확인해야 한다면 우선순위는 달라집니다. 이 경우에는 기사 앱의 화면 구성보다 먼저, 작업을 만들고 배정하고 바꾸고 완료로 판단하는 관리자 화면과 기록 기준을 정하는 편이 안전합니다.
담당자가 자주 바뀌면 작업의 기준점부터 만든다
가령 오전에는 A 기사에게 배정했던 방문 작업을 오후에 B 기사에게 넘겨야 하는 상황을 생각해 볼 수 있습니다. 고객 일정이 바뀌거나 차량 문제가 생기거나, 현장에서 필요한 작업 내용이 달라질 수 있습니다. 이때 중요한 것은 변경 알림을 보냈는지가 아닙니다. 운영자가 현재 유효한 지시가 무엇인지, 지금 담당자가 누구인지, 이전 담당자의 작업은 어떻게 정리됐는지를 한곳에서 판단할 수 있어야 합니다.
기사 앱만 먼저 만들면 기사는 자신에게 보이는 작업을 확인하고 완료를 입력할 수 있습니다. 그러나 재배정 뒤 A 기사가 예전 지시를 보고 완료를 누르면, 운영자는 그 완료를 인정할지 예외로 처리할지 판단해야 합니다. 작업 변경이 잦은 조직이라면 앱의 첫 화면보다 이 판단을 가능하게 하는 작업 원본이 먼저 필요합니다.
관리자 화면은 지도보다 변경 기록이 먼저다
초기 관리자 화면이 복잡한 관제 시스템일 필요는 없습니다. 운영자가 작업을 생성하고 담당자를 배정하거나 바꾸며, 보류와 취소를 처리하고 현재 상태를 볼 수 있으면 됩니다. 작업마다 고객과 장소, 희망 시간, 지시 내용, 담당 기사, 진행 상태를 연결해 두면 전화와 메신저에 흩어진 내용을 한 건의 작업으로 모을 수 있습니다.
특히 변경 뒤에 무엇이 남는지를 요구사항으로 정해야 합니다. 처음에는 아래 정도의 정보와 상태만 있어도 운영 대화를 시스템 안으로 옮길 수 있습니다.
- 작업번호와 고객·장소·희망 시간
- 현재 담당 기사와 작업 지시 내용
- 초안, 배정됨, 기사 확인, 작업 중, 완료, 보류·취소 같은 상태
- 변경한 사람, 변경 시각, 변경 사유
- 완료 시각과 결과, 또는 완료하지 못한 이유
업체와 범위를 논의할 때는 기능 목록보다 최근 작업 사례를 보여주는 편이 낫습니다. 재배정된 작업, 기사 확인이 늦은 작업, 고객 요청으로 시간이 바뀐 작업처럼 실제로 헷갈렸던 사례를 가져가야 합니다. 그 사례에서 “이전 기사가 완료를 누르면 어떻게 보이는가”, “변경된 지시를 아직 확인하지 않은 기사는 어떻게 구분하는가”를 물으면 필요한 화면과 기록 범위가 선명해집니다.
기존 운영 도구가 기준을 갖고 있다면 기사 앱부터 연결한다
기사 앱을 먼저 만드는 선택도 가능합니다. 이미 엑셀, 배차 시스템 또는 업무 관리 도구에서 작업번호, 담당자, 변경 권한, 완료 기준을 안정적으로 관리하고 있을 때입니다. 운영자가 현재 배정 상태와 변경 이력을 바로 확인할 수 있다면, 다음 병목은 현장 기사의 작업 확인과 완료 입력일 수 있습니다. 이때는 기존 도구를 작업의 원본으로 유지하고, 기사에게는 내 작업 조회, 지시 확인, 시작·완료, 예외 보고처럼 한 손으로 처리할 흐름부터 제공하는 방식이 맞습니다.
통신이 불안정한 현장도 별도로 판단해야 합니다. 오프라인 상태에서 완료를 입력할 수 있게 하는 기능은 유용할 수 있지만, 연결이 회복된 사이 서버의 지시가 바뀌었을 수 있습니다. 휴대폰에 남아 있던 예전 지시와 새 배정이 충돌할 때 자동 완료로 처리할지, 운영자 확인으로 넘길지를 미리 정하지 않으면 현장 입력 기능이 오히려 판단을 늦출 수 있습니다.
처음 만들 화면은 누가 더 자주 사용할지를 기준으로 고르기보다, 누가 최신 작업을 확정해야 하는지를 기준으로 정하는 편이 좋습니다. 변경과 재배정의 기준이 아직 없다면 관리자 화면부터, 그 기준이 이미 운영 도구에 갖춰져 있다면 기사 앱부터 시작하면 됩니다.
