불편하다는 말은 많았지만, 어디가 불편한지는 아무도 몰랐다.
회수 프로세스를 개선해달라는 요청은 꾸준히 들어왔습니다. CS 인입 건의 상당수가 회수 관련이었고, 만족도 조사에서도 회수 경험 점수는 항상 하위권이었습니다. 그런데 막상 데이터를 들여다보면 어디가 문제인지 특정하기가 어려웠습니다. 시스템엔 '완료' 상태만 찍혀 있었고, CS 로그엔 "회수가 늦었어요", "언제 오는지 모르겠어요"만 반복됐습니다.
여정을 쪼개야 측정할 수 있다
첫 번째로 한 일은 회수 여정을 단계별로 분해하는 것이었습니다. 하나의 '회수 완료' 이벤트 뒤에는 실제로 여러 단계가 있었습니다.
- 회수 접수
- 기사 배정
- 방문 예정 알림 발송
- 실제 방문
- 수거 완료 처리
- 유저 웹 상태 업데이트
각 단계에 시간 스탬프를 심고, 단계 간 소요 시간을 집계했습니다. 그제서야 병목이 보였습니다. 회수 지연은 실제로 존재했고, 특정 권역에서 집중적으로 발생하고 있었습니다. 기사 배정 이후 실제 방문까지의 소요 시간이 다른 권역 대비 두 배 이상이었습니다.
문제 로케이션을 특정하고 나서야 해결할 수 있었다
스탬프를 심기 전까지는 "회수가 늦다"는 피드백이 서비스 지역 전체적으로 고르게 발생하는 문제처럼 보였습니다. 하지만 데이터를 권역별로 쪼개자 문제가 집중된 구역이 명확하게 드러났습니다. 해당 권역의 배정 로직과 기사 운영 방식을 조정하면서 평균 회수 소요 시간이 줄었고, 관련 CS 인입도 40% 감소했습니다.
측정할 수 없으면 개선할 수 없습니다. '불편하다'는 피드백은 방향이지, 목적지가 아닙니다. 어디서 얼마나 느린지를 특정하고 나서야 실질적인 해결이 가능했습니다.