이 글의 순서
핵심 내용
지역 배송 앱을 준비할 때는 요청을 등록하고 가까운 배송 담당자와 연결하는 화면을 먼저 떠올리기 쉽습니다. 그런데 담당자가 물건을 전달했다고 표시한 순간, 신청자의 확인까지 끝났다고 볼 수 있을까요? 수거 전 취소와 수거 후 변경도 같은 버튼으로 처리해도 될까요?
먼저 물건을 보내는 신청자, 배송을 수행하는 담당자, 상황을 확인하는 운영자가 한 배송에서 언제 무엇을 처리하는지 적어보세요. 요청·수락·수거·배송 완료와 신청자의 최종 확인을 구분하면 첫 개발에 필요한 화면과 운영 범위가 구체적으로 보입니다.
배송 요청에는 담당자가 판단할 조건을 담습니다
물건을 보내려는 신청자는 무엇을 어디서 어디로 옮길지 알려야 합니다. 담당자는 그 조건을 보고 맡을 수 있는 요청인지 판단합니다. 물건명·수량·취급 시 주의사항, 출발·도착 장소와 시간 조건처럼 배송에 실제로 쓰이는 정보를 먼저 고르세요.
예를 들어 ‘소형 화분을 같은 지역의 다른 장소로 보낸다’면 주소만으로는 충분하지 않을 수 있습니다. 몇 개인지, 기울이면 안 되는지, 어느 장소에서 전달받을 수 있는지도 필요합니다. 사진이나 추가 입력 항목은 담당자의 판단에 필요한지 확인한 뒤 정합니다.
요청을 받을 마감과 물건을 수거·전달할 시간은 서로 다릅니다. ‘오늘 14시까지 담당자를 찾는다’는 신청 마감이고, ‘오늘 16시에 물건을 전달한다’는 업무 시간입니다. 두 조건을 한 날짜로 표현하면 담당자가 언제까지 수락하고 언제 방문해야 하는지 모호해집니다.
배송비도 금액을 보여주는 것과 실제 결제를 처리하는 것을 나누어 보세요. 요청자가 금액을 제시할지, 정해진 요금표를 적용할지, 앱에서 결제까지 받을지는 각각 필요한 범위가 다릅니다.
수락·수거·배송의 담당과 기준을 정합니다
요청 등록은 배송을 맡을 사람을 찾는 단계입니다. 담당자가 요청을 수락한 뒤에도 물건을 받았는지, 배송을 시작했는지, 전달을 마쳤는지는 따로 확인해야 합니다. 신청자에게 보여줄 진행 상태와 담당자가 누를 동작을 함께 정하세요.
한 배송을 요청 등록 → 담당자 수락 → 물건 수거 → 배송 시작 → 배송 완료 → 신청자 최종 확인으로 나누어 볼 수 있습니다. 서비스에 따라 단계를 합칠 수는 있지만, 수락만 한 상태를 물건까지 수거한 상태로 보여주지는 않아야 합니다.
각 단계에는 누가 처리하고 무엇을 확인해야 다음으로 넘어가는지 기준을 둡니다. ‘수거’는 실제로 물건을 받은 뒤 담당자가 처리하고, ‘배송 완료’는 전달을 마친 뒤 처리하는 식입니다. 버튼 이름뿐 아니라 신청자와 운영자에게 어떤 결과로 보일지도 함께 적어두세요.
담당자를 연결하는 방식도 먼저 하나를 고르세요. 담당자가 요청을 보고 직접 수락하는 방식과 운영자가 배정하는 방식은 필요한 화면이 다릅니다. 자동 배차·경로 최적화부터 범위에 넣기보다 첫 운영에서 실제로 누가 배송을 맡길지 정하는 것이 먼저입니다.
배송 완료와 신청자의 최종 확인을 구분합니다
배송 담당자의 완료 표시는 ‘물건 전달을 마쳤다’는 처리입니다. 신청자의 최종 확인은 그 결과를 확인하는 별도의 행동입니다. 담당자가 완료 버튼을 눌렀다는 이유만으로 신청자도 확인한 것으로 바꾸면, 실제로 확인하지 않은 결과가 기록됩니다.
예를 들어 담당자 화면에는 ‘배송 완료’를 표시하고, 신청자 화면에는 ‘배송 완료 · 최종 확인 대기’와 확인할 행동을 보여줄 수 있습니다. 신청자가 확인한 뒤에 최종 완료로 바꾸면, 전달이 끝난 시점과 신청자가 확인한 시점을 나누어 볼 수 있습니다.
확인이 늦어졌을 때의 처리도 정해야 합니다. 알림을 보낼지, 운영자가 내역을 확인할지, 일정 조건 뒤 자동으로 마감할지는 별도의 운영 선택입니다. 단순히 화면에서 대기 표시를 지우기 위해 자동 완료로 바꾸지 말고, 적용 조건과 안내 범위를 먼저 정하세요.
신청자는 물건을 보내는 사람이며, 도착지에서 물건을 받는 사람과 같지 않을 수 있습니다. 받는 사람의 확인도 필요하다면 누가 어떤 방법으로 확인할지 별도로 정합니다. 신청자 확인을 수령인의 서명이나 인수 증빙과 같은 기능으로 보지 않습니다.
배송·최종 확인과 결제·정산도 각각 구분하세요. 최종 확인이 끝났다는 표시만으로 결제 승인이나 담당자 정산까지 완료됐다고 안내해서는 안 됩니다. 결제와 정산을 함께 개발한다면 어떤 결과를 기준으로 언제 처리할지 별도로 연결합니다.
취소와 변경은 수거 전후로 나누어 봅니다
담당자가 정해지기 전 요청 취소와 물건을 이미 수거한 뒤 취소는 필요한 확인이 다릅니다. 수거 뒤에는 물건을 어떻게 처리할지까지 남기 때문에 상태만 ‘취소’로 바꾸어 끝낼 수 없습니다.
첫 개발에서는 변경 가능한 단계·확인할 사람·그동안 유지할 상태를 정하세요. 요청 수락 전에는 신청자가 주소를 수정할 수 있더라도, 수락 뒤에는 담당자가 바뀐 조건을 확인해야 할 수 있습니다. 수거 이후의 도착지 변경은 운영자가 먼저 확인하는 방식으로 시작할 수도 있습니다.
요청 수락 전
신청자가 수정·취소할 수 있는 항목과 신청 마감 이후의 처리 기준을 정합니다. 누가 맡기 전인지, 이미 담당자가 정해졌는지를 구분합니다.
수락 뒤 · 수거 전
시간이나 주소가 바뀌면 담당자가 다시 확인할지, 맡을 수 없다면 어떻게 연결을 해제할지 정합니다. 변경 요청과 실제 적용된 조건을 구분하세요.
수거 뒤 · 배송 중
연락이 닿지 않거나 전달 장소가 달라졌을 때 누가 확인할지 정합니다. 재방문·반환·추가 비용이 있다면 운영 기준과 개발 범위를 따로 합의합니다.
배송 완료 뒤
신청자가 결과를 확인하지 않았거나 문제가 있다고 알린 경우를 정합니다. 이전 진행 기록을 지우기보다 어떤 배송의 어떤 상황인지 운영자가 살펴볼 수 있게 합니다.
채팅은 일정과 장소를 협의하는 데 도움이 됩니다. 다만 채팅에서 주소 변경에 동의했다면, 실제 배송 상세에도 새 조건이 반영됐는지 확인할 방법이 필요합니다. 대화 내용만 바뀌고 담당자가 보는 주소는 이전 값으로 남지 않도록 처리 범위를 정하세요.
운영자가 확인할 배송 내역까지 첫 범위에 넣습니다
신청자 앱과 담당자 화면만 만들면 확인이 늦거나 잘못 처리된 배송을 운영자가 찾기 어렵습니다. 신청자·담당자·물건명·일시·진행 상태로 같은 배송을 조회할 수 있는 관리자 범위를 함께 정하세요.
운영 화면에서는 ‘배송 중’과 ‘담당자 배송 완료·신청자 확인 대기’를 구분해 찾을 수 있어야 합니다. 변경·취소 요청이 들어오면 담당자가 정해졌는지, 수거했는지, 최종 확인이 남았는지를 보고 후속 업무를 결정할 수 있습니다. 모든 배송을 임의로 완료시키는 권한부터 만드는 것은 적절하지 않습니다.
처리한 사람과 시각, 변경 전후 상태를 어디까지 남길지도 정합니다. 잘못 누른 완료를 되돌릴 수 있게 한다면 허용할 사람과 조건, 양쪽 이용자에게 보여줄 결과까지 함께 확인하세요.
개발 상담에는 배송 한 건을 기준으로 다음 내용을 가져오면 됩니다.
확인해보세요
- 배송 조건: 활동 지역, 물건 종류, 출발·도착 정보, 신청 마감과 업무 시간
- 담당자 연결: 직접 수락 또는 운영자 배정 중 첫 방식과 확정 기준
- 진행 처리: 수거·배송 시작·배송 완료를 누가 언제 처리할지
- 최종 확인: 신청자가 확인할 내용과 확인 지연·문제 제기 때의 처리
- 변경·취소: 수거 전후 허용 범위와 운영자가 확인할 상황
- 추가 기능: 결제·정산·위치 확인·사진 제출 등 첫 버전에 꼭 필요한 범위
지도에 현재 위치를 표시하는 것, 배송 상태를 조회하는 것, 담당자의 이동 위치를 계속 추적하는 것은 서로 다른 기능입니다. ‘실시간 배송 앱’이라는 한 표현으로 묶지 말고 어떤 정보를 언제 보여줄지 구체적으로 전달하세요.
다나르다는 요청부터 신청자 확인까지 연결했습니다
다나르다는 물건을 보내는 ‘보내주’와 지역의 배송을 수행하는 ‘나르맨’을 연결한 개발 사례입니다. 한 계정에서 두 역할을 이용하며, 보내주가 물건과 배송 조건을 등록하면 나르맨은 활동 지역의 요청을 살펴보고 수락합니다.
앱은 매칭·물건수령·배송시작·배송완료·최종완료를 구분합니다. 나르맨의 배송 완료 뒤 신청자가 최종 완료를 확인하고, 배송 건별 채팅으로 수령 일정과 장소를 협의합니다. 관리자는 신청자·나르맨·물건명·일시·상태로 배송 신청내역을 조회합니다.
데브크래프트는 고객 기획을 바탕으로 UX·UI, Ionic 모바일 앱과 운영 관리자 웹, Firebase 배송 정보 연동을 구성했습니다. 아래 사례에서 요청 입력부터 수락·진행·최종 확인과 운영 조회가 어떻게 이어지는지 살펴볼 수 있습니다.
