IT 서비스 기획/PM, PO, 기획자

[PM/PO/기획자] '배달의 민족' - 가게 요청사항 기능 개선안

필문(PM) 2025. 1. 6. 09:53
반응형

‘가게 요청사항’ 기능 개선

배달의 민족의 가게 요청사항을 프로덕트로 하여 기능 개선안을 작성하여 보았습니다.

아래 노션링크로 들어가시면 더 편하게 보실 수 있습니다.

 

https://foul-parrotfish-755.notion.site/1703c6a02ff58035bd0fdc74176efeb0

 

‘가게 요청사항’ 기능 개선 | Notion

6조 정필문(PM_1기) 필수문제

foul-parrotfish-755.notion.site

1. 서비스 이해

1) 주요 사용자

<aside> 💡

  • 문제 상황 속 프로덕트는?
    • In App 탐구: 배달 품목(조리 음식)을 기준으로 2가지 서비스로 분류함
    • ‘배달의 민족’은 서비스 비전 3.0 부터 음식 뿐만 아니라 모든 것을 ‘배달’하도록 서비스 영역을 확장해나가고 있다.
    Sector1 배달/포장판매처: 요식업 가게Sector2 장보기/쇼핑판매처: 요식업 가게를 제외한 가게→ 문제 상황 속의 가게 요청사항 은 2. 장보기/쇼핑 의 UX 분석 결과 Sector1 에서 작성하는 가게 요청사항에 한정함을 알 수 있다
    • (1) 택배 서비스에는 가게 요청사항 항목X. 대신 배송과 관련된 배송 시 요청 사항이 존재 → 문제 속 프로덕트 범위에서 제외
    • (2) 배달 서비스에는 가게 요청사항 항목O. 그러나 요식업과 관련된 옵션 항목(일회용품 사용 여부, 기본 반찬 수령 여부)이 없고 문제 상황에서 제시된 ‘리뷰 이벤트’ 등의 상황이 발생할 여지가 없음 → 문제 속 프로덕트 범위에서 제외
  • ∵ 장보기/쇼핑의 주문은 (1)택배 서비스와 (2)배달 서비스를 제공
  • 배달 품목: 디지털 기기, 꽃, 주류 등
  • 배달 품목: 조리 음식

</aside>

주요 사용자는 누구?

  • 가게 요청사항을 주로 사용하는 사람은?
    • 고객(구매자)과 사장님(판매자)
    • 라이더(배달)의 경우 → 배달 요청 사항 란이 별도 존재하여 제외
    • 고객 페르소나김민지(27세 여) 서울
      • 배경
        • 서울 논현 오피스텔(1인 가구)
        • 중견 IT 기업 사무직(야근 많음)
      • 목표
        • 퇴근 후 빠르고 간편한 식사
        • 퇴근 시간에 맞춘 정확한 도착 시간
        • 다양한 주문옵션 선호
      • 성격
        • 다소 내향적
        • 전화보다 텍스트 선호(디지털 기기로 소통하는 것에 익숙함)
      • 사용 시나리오
        • 점심 전, 자주 가는 샐러드 가게에서 포장 주문 - (요청사항)연어 셀러디에 렌치 소스 추가, 카페 라떼 두유 변경
        • 야근 전, 동료들과 함께 곱창 배달 주문 - 수저 인원+1추가, 쌈장을 소금장으로 변경
        • 퇴근 후 저녁, 집 도착 시간에 맞춰 항정살 덮밥 주문 - 양파 빼기
      • 선정이유
    • 사장님 페르소나박명수(50세 남) 서울
      • 배경
        • 서울 논현 4인가구 가장(1남 1녀)
        • 프랜차이즈 분식집(24시간)
        • 배민에 등록하여 배달 서비스 운영중
      • 목표
        • 폭 넓은 고객층 확보
        • 효율적인 주문 관리 시스템
      • 성격
        • 외향적. 배운 것에 한하여 제한적으로 디지털 기기 사용가능
      • 사용 시나리오
        • 출근 후, 리뷰와 평점 확인 - 감사 또는 사과 답글 달기
        • 주문 요청사항 및 라이더 도착 시간에 맞춰 조리 시작
        • 마감 전, 매출 및 주분 현황 등 종합적 확인
      • 선정이유
        • 통계에 따르면 일반음식점 사장님들의 평균 나이는 55.4세
        • 서울 음식점 매출액이 전국의 23% → 어플 사용량도 많을 것으로 추측
        • 프랜차이즈 음식점이 요식업계 중 36%을 차지하고 프랜차이즈 음식점의 경우 배달 서비스에 가입되어 있는 경우가 대다수이기 때문에 선정

2) 핵심 가치

페르소나에 비춰본 사용자 핵심가치

  • 고객
    • 요청 사항을 빠르고 정확하게 수행하는 배달 서비스
    • 요청 사항을 통한 다양한 주문 옵션 구현
  • 사장님
    • 고객 요청 사항 반영한 가게 운영 _고객 취향 파악, 메뉴 개발, 고객 서비스 파악
    • 앱 서비스를 통한 고객 요청 사항의 효율적 관리

3) 사용자 경험

<aside> 💡

목표 UX: ‘시간’과 ‘품질’에 대한 약속을 지키는 물류 경험(회사소개서 3p.)

</aside>

    1. 배달/포장
    • 60자 내로 작성(줄바꿈 불가)
    • 일회용품 선택 기능
    • 주문하기 → 가게 요청사항(클릭)
    • 기본반찬 선택 기능(기본반찬 제공 가게에 한함)
    1. 장보기/쇼핑
    • 택배 서비스: 대용량특가, 배달전국별미 등 글자수 제한 없음
    • 배달 서비스: 배달/포장의 경우에서 일회용품, 기본반찬 서비스 제외
  • → 문제 상황 속 프로덕트는? 의 정의에 따라 1번 항목의 UX만 고려
  • User Journey Map
      1. 요청 사항 발생
      • 고객: 메뉴 탐색 및 선택 후 필요 요청 사항 발생
      • EX) 토핑 추가/제외, 맵기 조절, 장부 결제
      1. 요청 사항 작성
      • 고객: 글자 수 및 리뷰 이벤트 조건 등 형식에 맞게 작성
      1. 요청 사항 반영 - Aha Moment
      • 사장님: 요청 사항 확인 및 수락/거부
      • 수락 시 요청 사항 반영하여 음식 전달
      • 거부 시 요청 사항 반영X
      • 고객: 요청 사항이 반영된 음식 수령
      • 이후 반응 예시: 리뷰 작성(만족 여부),

2. 문제 정의

<aside> 💡

  1. 현상발견: 가게 요청사항 은 1개의 요청만 저장 가능 → 사용자가 매번 새롭게 작성하는 불편함
  2. 결과
  • 고객: 특정 문구 작성(리뷰 이벤트) or 가게 별 다른 요청사항 반복 입력의 불편함 가중 → 서비스 운영에 대한 불만 및 해당 가게 결제 불편 사항으로 인한 이탈가능성
  • 사장님: 정확한 요청사항 미반영 or 결제 속도 저하 및 불편으로 인한 고객 이탈 가능성 </aside>

원인: 5 Whys(With logic tree)

  • 문제: 사용자가 가게 요청사항을 매번 새롭게 작성하는 것에 불편함을 느낀다
  • 1차 why 왜 불편함을 느끼는가?
  1. 주문 속도 저하 2)반복 입력에 대한 피로감
  • 2차
      1. why? 왜 주문 속도가 저하 되었는가? 저장한 문구를 바로 작성하는 것에 비해 직접 작성하는 시간이 소요된다. 지난번 요청한 사항이 기억이 나지 않을 경우 주문을 검토하는 시간도 발생한다
      1. why? 반복 입력은 왜 피로한가? 고객이 동일한 작업(주문)을 매번 함에도 불구하고 반복된 노력(작성)을 해야 하기 때문
  • 3차
      1. why? 왜 작성하는 데 시간이 걸리는가? 자신이 사용하는 모든 요청 사항을 개인이 기억하기 힘들다. 특히 반복된 단체 주문의 경우(회사 팀 식사 등)는 기억하기 힘들다. 때문에 매번 확인 후 작성해야 한다
      1. why? 왜 반복된 작성을 해야만 하는가? 요청 사항은 고객이 필요한 경우, 작성 해야만 하기 때문이다
  • 4차
      1. why? 왜 기억하기 힘든가? 자신의 작성한 요청 사항을 따로 기록하지 않는다
      1. why? 요청 사항을 왜 작성해야만 하는가? 가게에 자신이 필요한 사항을 알기기 위해서
  • 5차
      1. why? 왜 기록하지 않는가? in app 외에 가게 별 요청 사항을 정리하는 데에 자원이 필요하기 때문
      1. why? 왜 알려야만 하는가? 왜 알리는가? 음식을 먹는데 필요한 요소를 얻거나, 불편한 점을 제거하려고

핵심 문제 정의

  • 페인포인트: 가게 요청사항 을 APP내에서 저장 및 기록할 수 없고, 사용자들은 개인적으로 요청사항을 따로 정리/기록 해두지 않아 요청 사항을 매번 새로 작성하게 된다
  • 조건: 2)로 부터 도출 → 가게 요청사항은 필요한 경우 반드시 사용해야 한다
  • 서비스 운영에 미치는 영향
    • 페인포인트 미해결 시 VoC 증가 → 브랜드 이미지 저하 → 경쟁력 감소
    • 새로 작성하는 것을 잊고 이전 내용 그대로 주문하는 경우 → 요청 내용 오기로 인한 소통 비용 발생

3. 가설 설정

<aside> 💡

가설 : 가게 요청사항의 편의성을 높이면 유저 이탈이 발생하지 않을 것이다

  • 편의성
    1. 가게 요청사항을 새로 작성하는 데 드는 자원을 효율적으로 관리
    2. 작성한 요청사항을 가게에 정확하게 전달하여 반영하기 </aside>

4. 해결 방안

해결 방안 1

  • IF 요청 사항이 가변적인 경우 → 가게 별 요청 사항 저장 기능 추가
  • 해설: 개인 별로 가게에 대한 요청 사항이 다를 수 있는 경우 = ‘가변적 경우’라 한다
  • ex) 알러지 - 알러지는 개인마다 보유하는 것이 다르다 → 요청 사항이 사람 별로 다르게 적힌다 → (복숭아 알러지 - 복숭아 토핑 제거 요청), (피망 알러지 - 피망 토핑 제거 요청)
  • 가게 별로 요청 사항을 저장할 경우 → 가게 요청 사항을 새로 작성하는데 드는 자원을 효율적으로 사용 가능하다

<aside> 💡

효율성 비교

  • 요청 사항을 작성한 횟수 = 소모 자원
    1. 기존 방식(매번 새로 요청사항을 작성하는 경우)
      1. 총 주문 횟수 - 요청 사항 없는 주문 횟수 - 저장한 요청 사항(1개)을 사용한 경우 = 요청 사항을 작성한 횟수
    2. 가게 별 저장 기능 추가 시
      1. 총 주문 횟수 - 요청 사항 없는 주문 횟수 - 저장한 가게 별 요청 사항을 사용한 횟수 = 요청 사항을 작성한 횟수
  • 가게 요청사항을 1개만 저장할 수 있는 경우보다 가게 별로 다수의 요청 사항을 저장할 수 있는 경우에 요청 사항 작성 횟수가 작기 때문에(자원 소모가 덜하기 때문에) 2번 케이스가 더 효율적이다 </aside>
  • 가게 별 요청 사항 기능 추가 - 도입 방식
    • 가게 별 문구 라이브러리 개설
      • 해당 가게의 요청 사항 기록 → 다수 저장 가능
      • 해당 가게에서만 보임 및 사용 가능 → 다른 가게의 라이브러리가 보일 경우 유저 혼란 증가

해결 방안2

  • IF 요청 사항이 고정된 경우 → 요청 사항 자동 반영 시스템
  • 해설: 개인 별로 가게에 대한 요청 사항이 동일한 경우 = ‘고정적 경우’라 한다
  • ex) 수저/포크 필요, 기본 반찬 필요, 리뷰 이벤트 제공품
  • 작성 문구 내용에 개인차가 없다 → 제한된 범위 내에서 요청하기 때문
  1. 메뉴 선택 단계에서 선택하였을 경우 별도의 요청 사항 작성 없이, 가게 요청사항에 반영되는 UI 개발
  2. 사장님의 입장에서도 고정된 문구로 요청 사항을 전달 받아, 소통의 정확도가 향상됨

참고 자료 모음

https://www.openads.co.kr/content/contentDetail?contsId=8753

반응형

'IT 서비스 기획 > PM, PO, 기획자' 카테고리의 다른 글

[PM/PO/기획자] PM이 Chat GPT를 업무에서 활용하는 방법  (4) 2025.01.23
[PM/PO/기획자] IT업계 속 PM의 정의와 역할  (2) 2025.01.18
[PM/PO/기획자] 배달의 민족 '가게 요청사항' 문제 사항 분석  (0) 2025.01.04
[PM/PO/기획자] 서비스 기획에서의 문제 정의 및 가설 수립&검증 + GPT4 활용 방안  (0) 2025.01.02
[PM/PO/기획자] 서비스 기획에서 문제정의와 해결 및 목표 설정  (0) 2024.12.31

'IT 서비스 기획/PM, PO, 기획자'의 다른글

  • 현재글[PM/PO/기획자] '배달의 민족' - 가게 요청사항 기능 개선안

관련글

티스토리툴바