기사님, 이 오더 왜 안 받으세요? | 잇트럭 서비스팀의 차주앱 톺아보기
안녕하세요. UMOSONE 잇트럭 서비스팀은 차주와 화주를 연결하고, 운송의 계획부터 실행·관리까지 전 과정을 잇는 화물 운송 플랫폼을 기획, 디자인하고 있습니다.
단순히 오더를 연결하는 데 그치지 않고 화주에게는 더 효율적인 운송 운영 경험을, 차주에게는 더 안정적으로 운송을 이어갈 수 있는 경험을 만드는 것이 저희 팀이 풀고 있는 문제입니다.
오늘은 그 과정에서 마주한 문제 중 하나인 오더 수락률을 높이기 위한 방법을 저희 팀이 어떻게 바라보고, 풀어가고 있는지 소개해 드리려고 합니다.
01. 문제 인식
우리는 기사님이 원하는 오더를 정말 알고 있을까?
이번 프로젝트의 시작은 하나의 질문에서 출발했습니다.
“왜 생각만큼 오더를 수락하지 않으실까?”
차주앱에서는 기사님이 오더를 확인하고 수락한 뒤 운송과 정산까지 이어갈 수 있습니다. 기사님에게 더 많은 오더를 보여주면 자연스럽게 수락도 늘어날 것이라 생각했습니다.
하지만 현실은 우리의 기대와 조금 달랐습니다. 오더는 노출되고 있었지만 기대했던 만큼 수락으로 이어지지 않았고, 기사님이 왜 오더를 선택하지 않았는지 알기 어려웠습니다.
- 원하는 운임이 아니어서일까요?
- 원하는 지역의 오더가 아니어서일까요?
- 아니면 오더를 찾고 비교하는 과정 자체가 불편했던 걸까요?
차주앱에서는 운임, 출발지, 도착지, 차량 조건 등의 정보를 기준으로 오더를 제공하고 있었습니다. 다만 기사님이 실제 어떤 기준으로 오더를 선택하는지 알 수 없었습니다.
그래서 화면 안에서 답을 찾는 대신 현장으로 나가보기로 했습니다.
02. 인터뷰
저희는 실제 화주사 물류센터를 찾아가 저희와 계약된 기사님들을 직접 인터뷰했습니다.
단순히 “저희 차주앱 어떠세요?”라고 묻는 인터뷰는 피하고 싶었습니다. 기사님이 평소 어떻게 운송을 시작하는지, 오더를 받을 때 어떤 정보를 먼저 확인하는지, 어떤 상황에서 오더를 포기하는지까지 실제 업무의 흐름을 따라가며 질문했습니다.
“오더를 탐색하는 과정이 복잡하면 잘 안 보게 돼요.”
의외로 자주 나온 이야기는 오더를 탐색하는 과정의 번거로움이었습니다.
오더를 확인하기 위해 화면을 여러 번 이동해야 하거나, 추가 과정이 필요한 경우 기사님은 끝까지 확인하지 않았습니다.
물류 현장에서 기사님은 앱만 보고 있지 않습니다. 운전 중이거나, 상·하차를 준비하거나, 다음 일정을 확인해야 합니다.
저희에게는 버튼 한두 번이지만 기사님에게는 오더 수락을 번거롭게 하는 원인이었습니다.
“돌아올 때 빈 차가 아니었으면 좋겠어요.”
운임이 오더를 선택하는 가장 강한 기준 중 하나라고 생각했지만 인터뷰를 해보니 기사님들은 운임만 보지 않았습니다.
특히 현재 위치에서 상차지까지 얼마나 이동해야 하는지, 운송이 끝난 뒤 어느 지역에 도착하는지, 그리고 그곳에서 다음 오더를 잡을 수 있는지를 함께 판단하고 있었습니다.
운임이 조금 높더라도 다음 운송을 잡기 어려운 곳에서 끝나는 오더라면 매력도가 떨어질 수 있습니다. 반대로 운임만 보면 평범한 오더라도 기사님이 자주 운행하는 지역으로 이어지고, 그곳에서 다음 오더까지 받을 수 있다면 훨씬 좋은 선택지가 될 수 있었습니다.
여기서 저희의 질문도 바뀌었습니다.
‘어떤 오더를 추천할까?’가 아니라
‘어떻게 하면 원하는 오더를 잘 찾도록 할까?’
‘운송을 이어서 하려면 무엇을 알아야 할까?’
03. 문제 해결
과제 1. 차주 선호 운송 조건
기획 김민규 : “기사님마다 각자 원하는 조건을 가지고 있었어요”
문제 정의
기사님들은 자신이 어떤 오더를 선호하는지 알고 계셨습니다.
“이 지역은 갑니다.”
“저쪽 방향은 안 갑니다.”
“이 시간 이후에는 일을 안 합니다.”
“이 금액 아래로는 안 갑니다.”
하지만 기사님의 다양한 선호 조건에 맞는 오더를 탐색할 수 있는 방법이 없었습니다. 그러다 보니 기사님은 매번 많은 오더를 살펴보면서 자기 조건에 맞지 않는 오더를 눈으로 걸러내야 했습니다. 그래서 문제를 이렇게 정의했습니다.
기사님의 번거로운 과정을 우리가 해결하자.
번거로움 줄이기
오더를 탐색할 때마다 더 많은 선호 조건을 입력하게 만들 수도 있었습니다. 하지만 조건이 많아질수록 입력 자체가 부담이 된다는 것을 경계했습니다.
따라서 오더 수락에 가장 영향을 미치는 조건 3가지로 좁혔습니다.
상하차 지역
최소 보장 운임
시간 내 상차 가능 여부(ETA)
대부분의 기사님은 선호하는 운행 경로가 정해져 있어 그 경로를 크게 벗어나지 않았습니다. 예를 들어 서울 → 강릉 경로의 오더를 운송하는 기사님은 해당 경로 내에서 오더를 찾았습니다.
또한 기사님별로 기대하는 운임 기준이 달랐습니다. 한 번 운송할 때 “최소 얼마는 받아야 한다”고 정해 둔 운임을 가지고 계셨습니다.
마지막으로 시간 내 상차 가능 여부를 추가한 이유는 다른 조건이 맞아도 실제 상차 시간까지 도착할 수 없다면 볼 필요가 없기 때문입니다. 따라서 ETA(Estimated Time of Arrival)에 실제 상차지까지의 이동 거리와 소요 시간을 고려한 오더 탐색 경험을 제공하고자 했습니다.
디자인 한주희 : “어떻게 하면 기능을 사용할까?”
문제 정의
기획 단계에서는 오더 탐색의 번거로움을 줄이기 위해 조건을 상하차 지역, 최소 보장 운임, ETA 세 가지로 좁혔습니다. 조건이 많아질수록 입력 자체가 부담이 된다는 걸 경계한 결정이었어요.
그런데 조건을 세 가지로 줄여도 그걸 입력하는 과정 자체가 번거롭거나 애초에 이런 조건을 설정할 수 있다는 걸 기사님이 모른다면 그 결정은 무의미해집니다.
저에게 남은 질문은 두 가지였어요. 운송 선호 조건 설정 기능을 어떻게 알릴까? 그리고 어떤 편의 기능이 있으면 잘 쓰일까?
이점을 인지시켜 설정하도록 유도하기
이 기능을 사용하게 만들기 위해 조건을 설정하면 어떤 점이 좋아지는지를 먼저 알려주고 싶었어요. 그래서 가입 완료 직후 바텀시트로 기능의 이점을 먼저 안내했습니다.
단순히 “이런 기능이 있어요”에서 그치지 않고 설정 전/후로 무엇이 바뀌는지, 무엇이 좋아지는지를 담아 혜택을 인지시켜 그 흐름 그대로 실제 설정까지 이어질 수 있도록 유도했어요.
기획이 조건의 개수로 줄인 번거로움을, 저는 진입 시점에서 한 번 더 줄이고 싶었습니다.
정해진 경로 왕복을 원하는 기사님을 위해
상하차 지역을 상차지·하차지로 나눠 설정하다 보니, 자연스럽게 떠오른 사용자층이 있었어요. 상차지(A) → 하차지(B) 방향뿐 아니라, 같은 하차지(B) → 상차지(A) 경로의 오더도 수락하고 싶어 하는 기사님들이었습니다.
이분들 입장에서는 상차지 지역과 하차지 지역을 사실상 동일하게, 방향만 바꿔서 설정하고 싶을 거라고 생각했어요. 그래서 상차지 필터에는 ‘하차지와 동일’ 버튼을, 하차지 필터에는 ‘상차지와 동일’ 버튼을 넣었습니다. 버튼을 누르면 각각 반대편에 넣어둔 지역 값을 그대로 가져와 세팅해주는 방식이에요. 같은 지역을 두 번 고르는 수고를 없애고 싶었습니다.
과제 2. 후속 액션 유도(복화 추천)
“복화는 더 많이 버는 것보다, 빈 차로 돌아오는 손실을 줄이는 문제였습니다”
기획 박선영 : “기사님이 다음 오더를 찾기 전에 먼저 보여드리면 어떨까?”
문제 정의
인터뷰를 통해 기사님들이 한 건의 오더만 보고 움직이지 않는다는 것을 알게 되었습니다. 현재 오더의 운임도 중요하지만, 운송이 끝난 뒤 어디에 도착하는지, 그리고 그곳에서 다음 오더를 이어서 잡을 수 있는지까지 함께 고려하고 있었습니다.
특히 장거리 운송 후 다음 오더를 잡지 못하면 빈 차로 다시 이동해야 합니다. 기사님 입장에서는 운임이 괜찮은 오더를 수락했더라도 이후 공차 이동이 길어지면 하루 전체 수익은 낮아질 수 있습니다. 그런데 기존 앱에서는 하나의 운송이 끝난 뒤 기사님이 다시 오더 목록으로 돌아가 직접 다음 오더를 탐색해야 했습니다.
앞서 발견한 ‘번거로운 오더 탐색’이라는 문제도 여기서 다시 나타났습니다.
그래서 질문을 바꿔봤습니다.
기사님이 다음 오더를 찾게 하지 말고,
필요한 순간에 우리가 먼저 제안하면 어떨까?
운송의 흐름이 끊기지 않도록
다음 오더가 필요한 시점을 크게 두 가지로 나누었습니다. 첫 번째는 현재 오더를 수락한 직후, 두 번째는 현재 운송을 완료한 직후입니다. 오더를 수락한 시점에는 이미 도착 예정 지역을 알 수 있기 때문에 해당 지역에서 이어서 운송할 수 있는 오더를 미리 탐색할 수 있습니다. 또 운송을 완료한 뒤에는 실제 하차 위치를 기준으로 바로 수행할 수 있는 다음 오더를 제안할 수 있습니다.
이를 통해 기존의
하차 완료 → 오더 목록 진입 → 여러 오더 탐색 → 조건 비교 → 수락
과정을
하차 완료 → 복화 오더 추천 → 확인 → 수락
으로 줄이고자 했습니다.
기사님에게 많은 선택지를 보여주는 것이 아닌, 필요한 순간 수락 가능성이 높은 오더를 먼저 보여주는 것이 핵심이었습니다.
아무 오더나 추천하지 않기
추천 시점만큼 중요한 것은 어떤 오더를 추천하는가였습니다.
과제 1에서 정의한 차주 선호 운송 조건을 다음 오더 추천에도 활용하기로 했습니다.
기사님이 설정한
- 상·하차 선호 지역
- 최소 보장 운임
- 상차 가능 시간
을 기준으로 먼저 후보를 좁히고, 현재 운송의 하차 지역과 다음 오더의 상차 위치까지 함께 고려하도록 했습니다.
예를 들어 부산에서 하차 예정인 기사님에게 서울에서 출발하는 오더를 추천한다면, 운임이 아무리 좋아도 실제 선택 가능성은 낮습니다. 반대로 현재 하차지 인근에서 출발하면서 기사님이 선호하는 방향으로 이동하는 오더라면 다음 운송으로 이어질 가능성이 더 높다고 판단했습니다.
결국 과제 1에서 ‘기사님이 원하는 오더가 무엇인지’를 정의했다면, 과제 2에서는 그 정보를 활용해 ‘언제 그 오더를 보여줄 것인지’를 해결하고자 했습니다.
디자인 우수완 : “조건에 맞는 오더를 최적의 타이밍에 추천하자”
문제 정의
다음 오더를 추천한다고 해서 기사님의 현재 업무를 방해해서는 안 된다고 생각했습니다.
기사님은 운송 중 앱을 계속 바라보고 있는 사용자가 아닙니다.
운전하고, 상·하차를 준비하고, 화주와 연락하는 등 여러 일을 동시에 수행합니다. 따라서 추천이 필요한 순간이라 하더라도 화면을 갑자기 가리거나 행동을 강요하면 오히려 불편한 경험이 될 수 있습니다.
그래서 디자인에서는 ‘어떻게 강하게 노출할 것인가’보다 ‘언제, 어떤 방식으로 자연스럽게 개입할 것인가’를 중요하게 보았습니다.
오더를 언제 추천해야 할까?
초기 기획은 기사님이 하차를 완료하는 시점에만 다음 오더를 추천하는 방향이었지만 “꼭 하차를 완료한 시점에만 제공해야 할까?”라는 생각이 들었습니다.
다음 운송을 고민하는 시점은 꼭 하차 이후일 필요가 없다고 생각했습니다. 첫 오더를 수락한 순간부터 다음 오더를 함께 탐색할 수 있다면, 운송을 시작하기 전부터 이후 일정까지 미리 계획할 수 있기 때문입니다.
예를 들어 서울 → 강릉 오더를 수락할 때 강릉 → 서울로 돌아오는 오더를 추천하는 방식으로요.
오더 수락, 하차 완료 이후 자연스럽게 다음 행동을 고민하는 시점에 오더 목록을 찾아가지 않아도 다음 오더를 바로 확인할 수 있도록 연결하고자 했습니다.
놓치지 않도록 알려드려요!
인터뷰를 통해 기사님들이 항상 차주앱을 확인하고 있지는 않다는 사실도 확인했습니다.
좋은 오더가 있더라도 그 순간 앱을 보고 있지 않다면 추천 자체가 의미가 없어질 수 있습니다.
그래서 앱 내부 추천과 함께 푸시 알림을 통한 진입 경험도 함께 설계했습니다. 추천 기능의 목적은 새로운 화면 하나를 만드는 것이 아니라, 기사님이 직접 오더를 찾기 위해 사용하는 시간과 행동을 줄이는 것이었기 때문입니다.
04. 앞으로
현재 저희 팀의 개발자분들이 두 과제에 대한 작업을 하고 계십니다. 그래서 아직은 기능 도입을 통해 “수락률이 몇 % 올랐다”고 이야기할 수 없습니다.
저희 서비스를 이용 중인 회원 차주분들의 매칭 경험이 나아졌는지를 보기 위해 아래와 같은 퍼널 및 지표를 통한 데이터를 기준으로 개선 사항을 도출해 보려고 합니다.
차주 선호 운송 조건 — 선호 조건에 맞는 추천이 실제 수락까지 연결되는지
A. 통합 퍼널
[A] 인앱 : 앱 진입 ─▶ 대기오더목록 ─▶ 추천 오더 노출 ─┐
├─▶ 수락
[B] PUSH : 발송 ─▶ PUSH 확인 ─▶ 클릭 ───────────┘
B. 수락률 지표
- 추천 오더 수락률 :
추천 수락(A_total) / 전체 오더 수락(Total) × 100 - 경로별 수락률
- In-app :
인앱 추천 수락(A_in) / 추천 수락(A_total) × 100 - Push :
PUSH 추천 수락(A_push) / 추천 수락(A_total) × 100
- In-app :
복화 추천 — 복화 오더 추천이 실제 오더 수락까지 연결되는지
A. 통합 퍼널
[A] 직접(인앱) : 오더수락 / 하차완료 ─┐
├─▶ 추천화면 진입 ─▶ 수락
[B] 영향(푸시) : 발송 ─▶ 단말도달 ─▶ 클릭 ┘
B. 수락률 지표
- 복화 오더 수락률 :
수락한 복화 오더 수(A_total) / 전체 복화 오더 수(Total) × 100 - 경로별 수락률
- In-app :
In_app_sess / 복화 추천 화면 진입 수 × 100 - Push :
PUSH_sess / 복화 추천 화면 진입 수 × 100
- In-app :
배포 이후에 추천 화면에 얼마나 진입했는지, 실제 추천 오더가 얼마나 수락으로 이어졌는지, 복화 추천을 받은 기사님이 다음 운송까지 얼마나 자연스럽게 연결되는지를 함께 살펴보려고 합니다.
- 알고리즘이 문제인지,
- 푸시 문구가 문제인지,
- 화면에서 판단하기 어려운 것이 문제인지
이번 인터뷰를 계기로 저희는 이 작업을 한 번의 이벤트가 아니라, 제품을 만드는 관점에서 지속적으로 사용자의 행동을 추적하고 개선점을 도출하는 일로 만들려고 합니다.
05. 되돌아보며
이번 프로젝트에서 가장 크게 배운 점은 “답은 현장에 있다”는 것이었습니다.
데이터만 봤다면 더 많은 오더를 노출하거나, 운임이 높은 오더를 우선적으로 보여주는 방향으로 문제를 해결하려 했을지도 모릅니다.
결국 우리가 개선해야 했던 것은 오더 하나의 조건이 아니라 기사님이 오더를 탐색하고, 수락하고, 다음 운송으로 이어지는 전체 여정이었습니다.
앞으로도 잇트럭 서비스팀은 이 과정을 반복하려고 합니다. 그리고 언젠가는 이런 질문을 조금 덜 하게 되기를 기대합니다.
“기사님, 이 오더 왜 안 받으세요?”
대신 저희가 먼저 기사님에게 이렇게 제안해 보겠습니다.
“기사님, 다음 오더 어떠세요?”