Chapter 26. 타다 호출 예약 서비스 기획 프로세스

1️⃣ 타다 이해도 높이기

🔷 타다 서비스 이해

O2O 플랫폰

• Business side
  • 라이더/드라이버 양쪽을 고려한 정책 수립
  • 실제 서비스는 오프라인에서 진행/완료 : 현장에서 일어날 수 있는 문제를 고려 후 해결
• Product Side
  • 한 쪽 유저의 액션이 다른 유저의 액션 영향 : 라이더/드라이버가 영향 -> 다른 사이드에서 영향을 받을 플로우 고려
  • 정책에 따른 로직 적용 및 구현 : 오프라인 정책을 고려

🔷 타다 호출 예약 서비스 이해

• 미래 시점 이동이 필요한 경우, 사전 예약 서비스
• 탑승 차량은 넥스트와 플러스로 한정
• 예약가능 일시는 최소 1시간 후 최대 14일 후
• 런칭 당시는 최소 3시간부터 예약 가능 운영안정화 후 1시간으로 단축.

---

2️⃣ 신규서비스 런칭

🔷 고민의 시작 - 유저 파고들기

📌 painpoint : 수요 대비 부족했던 차량 공급 수 -> 이동 시 바로 호출이 어렵고 배차시간이 깁

❗ unmet need : 동일한 이동결로를 반복적으로 호출하는 패턴 -> 동일한 출/도착지를 왕복으로 탑승하는 유저군 확인

❓예약을 하여 사전에 확정으로 painpoint, unment need를 해결할 수 있지 않을까?

 

🔷 신규 서비스 가능성 확인

서비스 실 경험을 오프라인에서 확인

모의테스트 진행

• 라이더
  • 실제 오프라인 상황에서 실시간 호출과 비교시 차별점
  • 정책적으로 반드시 챙겨야 할 혹은 방지되야할 항목 체크
• 드라이버
  • 운행 상황/시각/가격 측명에서 실시간 콜과의 차별점
  • 경쟁사 대비 매력으로 어필될 수 있는 포인트 발굴

🔸 테스트 단계

1. 시나리오 설계 : 다양한 운행 시간, 지역, 요금 및 운행차량 별 테스트 경로 구성
2. 테스터 모집 : 드라이버 및 사내 임직원 대상 구글 폼 신청을 통해 모집
3. 테스트 : [제품]임의 배차 event 형성, [운영] 실시간 대응 및 실행
4. 결과 wrap-up : [라이더] 배차 불안감 해소, 나만의 서비스라는 만족도  [드라이버] 안정적 운행 스케줄, 콜이 많이 않을때 운행이익이 높아짐.

 

---

3️⃣신규 서비스 런칭 준비 시작

🔷 현황 및 시장 분석 -  경쟁사 분석

• 기획/UX : 실제 유저 입장에서 서비스 결험을 통한 아이데이션
  • 경쟁사 서비스를 이용하며, 실제 상황에서 유저 인터뷰를 진행 -> 장단점과 니즈 발굴
• 디자인/UI : 유저 친화적인 UI 및 플로우 포인트 발굴
  • 혼동이 일어날 수 있는 부분 힌트 획듯
  • 차별점 혹은 포인트를 고민
• 사업/OP : BM 및 운영 정책 확인
  • 여러 시나리오 체험 테스트를 통해 운행 가격 등에 대한 BM확인
  • 실제 환경에서 어떠한 운영 정책이 적용되는지 확인

 

🔷 프로젝트 첫 걸음 - 킥오프 미팅

• Business side : 유사한 서비스가 이미 존재
  • 최대한 빠른 출시를 통한 시장 진출 & 유저 확보가 필요
• product side : 유저을 위한 main flow 초점
  • 서비스 이용 시 갖춰야 할 기본 기능 중심 고려

↓

• 차별화 포인트 : 후발주자로서 유사 서비스와의 경쟁 무기
  • 타다의 호출 예약을 선택해야하는 이유를 제공 : 반복 일정을 한번에 예약할 수 있는 "벌크 예약"
• 최소 스펙 정의 : 런칭 시 필수 스펙 최소화
  • 최초 제공 스펙은 유저가 이용을 완료 할 수 있을 것에 초첨
  • 이후 고도화 스펙 영역 정의 : 예약 일시 변겅은 취소 후 재접수, 미매칭 취소 시 자동 재매칭

↓

• 배경/목적 align : 다양한 팀 간 이해도 및 공동의식 형성
  • 관련된 모든 팀 참여
  • 프로젝트의 발단 배경 및 해결하고자 하는 유저의 painpoint
  • 대응 방항 및 이에대한 검증 지표
  • 때로는 FAQ 미리 준비

↓

• 주요 스펙 align : 주요 사업/운영 정책 공유
  • 유저가 경험 할 주요 플로우 논의 (시각 자료 시안을 준비)
  • 각 플로우 별 반드시 고려되어야 할 사항을 명확히 전달
  • 옵션 별 객관적 측면의 장단점
  • 다양한 시안 중 유저 친화적인 디자인 선택

↓

• 주요 정책 align : 사업/운영 측면의 주요 정책 공유
  • 사전 정의가 필요한 서비스 주요 정책을 공유 : 노쇼 시 패널티 / 보상, 운행 요금...
  • 제품팀에서 정해진 정책과 일치하는 개발 구현 집중 

↓

• 프로젝트 kick-off 
  • 서비스 운영 관련 : 법무이슈 검토
    • 운영에 있어 미리 정책상 범무 검토가 필요한 영역 확인
    • 타다처럼 까다로운 모빌리티 산업은 사전 검토 + 사정 동의 영역을 꼼꼼히 확인
  • 제품 구현 관련 : 업데이트 시나리오 확인
    • 서버 배포만으로 가능한 영역 / 업데이트가 필요한 영역에 대한 확인 및 배포 시나리오 가능
    • 앱 업데이트가 필요한 경우 이전 버전을 사용하는 유제 대응 시나리오 체크
  • 진행 일정 관리 : 이후 주요 단계 일정 논의
    • 세부 시나리오까지 고려한 시안 공유 회의 목표 일정 결정
    • 개발 완료, 필드 테스트, QA, 런칭일 등 주요 마일스톤 일정 논의

 

---

4️⃣ 신규서비스 런칭 준비 과정

🔷 세부시나리오 및 UI 체크 - 디자인 시안 논의

• 세부 시나리오 : main flow 외 시나리오 및 미대응 엣지 케이스 논의
  • 유저가 취하는 다양한 케이스에 대한정리 및 대응 로직 결정
  • MVP 기능만 내는 경우 많이 빠질 대응 외 로직 빈도가 낮을 미대을 케이스는 빼고 과감하게 skip
  • 드라이버 매칭 중 취소, 예약 임박 시간 내 실시간 호출 등
• 최종 UI 결정 : 여러 안 UI 옵션 논의
  • product design 팀에서 짜온 여러 시안 중 최선 UI안을 논의 후 선택
  • 필드 테스트 후 결정도 가능
• 개발 일정 재조율 : 결정된 UI 기반 구현 일정 재산정
  • UI 확정 전 가안으로 결정했던 개발 일정 다시 한번 체크
  • 수정을 위한 버퍼 기간을 고려하여 개발 일정 및 필드 테스트, QA일정 산정

 

🔷제품 구현 및 UX 체크 - 필드 테스트

• 필드 테스트 목적
  • 본격적인 QA 돌입 전 기능 구현 점검
    • 개발 작업 완료 후 본격적인 시나리오 QA 전, 주요 플로우 및 시나리오를 중심으로 구현 현황 점검
  • 실제 상황에 대입 시 수정/보충 사항체크
    • 기획 UI/UX와 실제 현장의 적합도 체크 및 보안/수정이 필요한 포인트 확인

1. 시나리오 설계 
   • QA/PM이 테스트 시나리오 정리
   • 유관 부서로부터 필요한 체크 포인트 추가 수렴
2. 테스트 조 편성
   • 시나리오 별 1팀씩 2-3개 편성
   • 기능/스펙을 잘 모르는 동료 섭외
   • 담당 PM/디자이너/개발자/QA 동승
3. test 시행
   • 시나이로 별 현장 테스트
   • 동승한 담당자가 영상 녹화 및 체크리스트 기반 주요사항 기록
4. 결과 wrap-up
   • 기능 구형 중 hot fix가 필요한 사항 체크
   • 실제 현장에서 적합하지 않은 기획/UX 개선 포인트 공유 및 대응 스펙 결정

 

🔷 신규 서비스 출시 준비 - 유저 커뮤니케이션 전략

• 커뮤니케이션 주요 목적
  • 신규 기능 런칭 예고 : 신규 기능 런칭이 임박했음을 알려 유저 기대감 유도
  • 단계 별 사용법 안내 : 유저들이 어려움 없이 이용할 수 있도록 주요 프로세스 안내
  • 주요 유의사항 전달 : 기존 실시간 호출과 상이한 주요 이용정책을 축약하여 전달
  • 주요 활동tip 소개 및 이용 유도
    • 예약 서비스 특성 상, 실시간 호출 이용과 상충되는 상황 발생 사능
    • 호출 예약의 적절한 상황/환경 가이드를 콘텐츠화 하여 제시
    • [비즈니스 측면] 두 서비스가 균형을 이루며 공존
    • [제품 측면] 상황에 따라 앱 내에서 어떻게 액션을 취해야 할지 명확히 전달

 

🔷 신규 서비스 모니터링 준비 - 데이터 지표 및 트래킹

• 데이터 모니터링 목적
  • 호출 예약 서비스성과 측정
    • 신규 서비스 유저 반응, 이용도, 목표 지표 달성 여부 트레킹
  • 이상 신호 및 가드레일 지표와 상충 감지
    • 기존 서비스 라인업 성과 지표와 카니발라이제시션 방지
    • 실시간 지표가 마이너스 성정이라면 역효과니 지속적 모니터링

1. 지표 리스트업
   • 제품/사업 측면에서 필요한 모니터링 지표 선정.
   • 지표 정의, 모니터링 사유, 관찰시점 및 공식 등 정리
2. 데이터팀 협의
   • 각 데이터 지표에 대한 이해도 align
   • 유저 플로우 및 각 부서변 니즈 기반, 트래킹, 테이너 논의
3. dashborad 구성
   • daily, weekly, monthly 등 각 주기별 데이터 트래킹 대시보드 형성
   • 가벼운 시트 형태로 시작하여 이후 전사 정식 대시보드 편입
4. 사후 분석 주제 선정
   • 트래킹을 통해 목표하는 data insight 논의
   • 향후 제품/사업 고도화를 위해 살펴봐야 하는 data 지표 논의

 

🔷 신규 서비스 운영 준비 - 교육자료 및 응대 가이드

• CX팀 대상 앱 상세 플로우 & 정책 공유 : CX 팀의 제품 이해도를 높임.
• 도움말 / FAQ 구성 : FAQ 초안 작성 후 CX 팀에서 세부내용 완성
• 패널티 / 보상 관련 자유도 align : 예상되는 주요 상황 체크 및 발생 CX팀 유연한 응대 범위에 대해 사전 협의 진행.

 

---

5️⃣  런칭 후 대응 및 고도화

• 서비스 오픈 : 실시간 제품 오류 및 운영 이슈 대응
  • 서비스 오픈은 출근 or  점심시간 이후 이슈가 대응 가능한 시간대 or 수요가 높은 시간대 고려
  • 오픈 당일 및 해당 주는 실시간으로 제품 오퓨 및 긴급 대응이 필요한 운영 이슈 발생을 면밀히 체즈
• 주요 운영 이슈 대응 : 긴급대응 / 핫픽스 TF 운영
  • 첫 런칭은 완벽한 스펙을 담기 보다 MVP, 최소 스펙 런칭을 지향
  • PM/서버/백오피스/CX 인원을 주축으로 긴급 수정 및 대응이 필요한 이슈를 선정하여 작업하는 한시적 조직 운영
• 고도화 영역 확인 : 스펙 고도화를 위한 로드맵 구축
  • PM/사업팀이 주축으로 향후 고도화가 필요한 스펙을 리스트업
  • 가용 리소스 및 임팩트를 고려한 우선순위 선정, 진행 로드맵 구체화.
• 대 고객 메세지 정비 : 서비스 이용 단계 별 대고객 발송 메세지 점검
  • 런칭 시 작성한 push/sms 메세지 중 수정 보안이 필요하 영역 체크
• 도움말 정비 : 추가 안내가 필요한 영역 점검
  • UI 개선 방안도 고려할 수 있음
• 추가 마켓팅 진행 : 서비스 운영 상황에 따른 마켓팅 커뮤니케이션
  • 런칭 직후 : 업데이트 비율 증대에 초점을 맞춤 정보성 성격 마켓팅
  • 안정화 후 : 호출 예약 인지 및 이용 유도에 초점을 맞춘 광고성 성격 마케팅