시간순 작업 기록

Problem

고객 불만은 ‘문제가 생길 때만 연락받는다’는 말로 자주 나타났다. 매장이 제품의 가치를 먼저 느끼게 할 방법이 필요했다.

Bet

매장별 데이터를 한 달에 한 번 SMS로 보내면 만족도와 재계약 가능성을 높일 수 있다고 봤다.

Action

부산 300개 매장에서 시작해 6개월 동안 500개 매장으로 넓혔다. 재방문율, 신규 고객 수, 적립금, 마케팅 메시지 샘플 링크를 담은 리포트형 링크를 발송했다.

Result

평균 SMS 클릭률은 20%를 넘었고, VOC 톤은 더 협조적으로 바뀌었다. 3개월 뒤 제품팀을 설득해 Monthly Report가 정식 제품으로 만들어졌고, 제품을 만드는 방향으로 이동하는 전환점이 됐다.

Problem

전국 매장 설치는 방문 설치가 기본이었다. 한 사람이 하루 2–5개 매장만 설치할 수 있어 지연, 이탈 위험, 팀 과부하가 생겼다.

Bet

원격 설치에 대한 저항은 실제 설치 필요성보다 고객 기대와 내부 믿음에서 비롯된다고 봤다.

Action

원격 전환 필요성을 내부에 공유하고, 부산 지점에서 4주 실험을 진행해 품질과 처리량 데이터를 모았다.

Result

1인 설치 처리량은 하루 2–5개에서 최대 20개까지 늘었다. 원격 설치는 Spoqa의 표준 프로세스가 되었고, 이 프로젝트는 Spoqa Mate 선정으로 이어졌다.

Problem

가맹 신청은 지원팀과 점주 사이의 카카오톡 대화로 처리됐다. 서류와 사진 누락, 신청 지연, 휴가나 퇴사 때의 인수인계 약화, 계약 지연, 지원 피로가 반복됐다.

Bet

신청 유형과 필요 서류를 웹 흐름으로 구조화하고 백오피스 처리와 연결하면 속도, 정확도, 협업이 개선될 것이라고 봤다.

Action

내부 백오피스/T-board DB와 연결된 웹 신청서를 기획·구축했다. 개인/법인과 업종별 서류 체크리스트를 나누고, 카카오톡으로 링크를 보내면 백오피스 기록 생성과 담당자 배정이 자동으로 이어지게 했다.

Result

신청 완료 시간은 3–5일에서 1–2일로 줄었다. 계약/지원팀의 서류 누락 병목이 줄었고, 접수부터 등록까지의 흐름이 자동화됐다.

Problem

약 40,000개 가맹점의 반복 갱신 관리가 필요했지만 갱신 시점을 쉽게 파악할 수 없었다. 영업/지원팀이 데이터를 수동으로 구글시트에 옮겼고, 소유권과 신뢰도가 낮아 이탈 관리가 어려웠다.

Bet

계약 종료 30일 전에 갱신 업무를 자동 생성하고 담당자에게 배정하면 선제 대응이 가능해진다고 봤다.

Action

계약 종료일 기준으로 갱신 업무를 만들고, 담당자를 자동 배정했다. 갱신, 이탈, 보류 같은 응답 처리를 전자계약 흐름과 연결했다.

Result

계약 만료 전에 갱신 위험을 관리할 수 있게 되었고, 시스템/프로세스 부재 때문에 생기는 피할 수 있는 이탈 위험을 줄였다.

Problem

숙박 운영자는 빈방을 줄이기 위해 여러 OTA에 판매하지만, 재고·요금·예약을 수동으로 관리하는 일은 복잡하고 스트레스가 크다. 기존 SMS/이메일 파싱 방식은 OTA 메시지 형식 변경이나 데이터 누락에 취약해 예약 식별 실패와 신뢰 문제가 생겼다.

Bet

취약한 메시지에서 데이터를 추출하기보다, 업주가 PC에서 보는 OTA 웹 정보를 RPA 기반으로 가져오면 더 안정적인 예약 연동이 가능하다고 봤다.

Action

OTA 채널 범위와 동기화 기간을 단계적으로 넓혀 15개 채널, 1일에서 30일, 180일 범위까지 확장했다. 누락 예약 같은 부작용을 막기 위해 `sell-stop` MVP를 냈고, 고객 만족과 인입 수요로 정성·정량 검증을 진행했다. 이후 수량 조정과 유료화도 시도했다.

Result

예약 동기화 성공률은 97%에 도달했고, 펜션 고객 획득과 월 300건 이상의 인입 리드로 초기 수요를 확인했다. 다만 보안, 캡차, 플랫폼 대응과 지연 증가로 일관성 기대치와 간극이 생겼다. 재고/판매 상태 기능은 제한하고 예약 동기화만 남긴 뒤 Channel Manager 2.0으로 전환했다.

Problem

Channel Manager MVP는 크롤링 기반 예약 동기화와 오버부킹 방지 수요를 검증했지만 안정적인 서비스 제공에는 한계가 있었다. 로그인 변경, 보안 프로토콜, 상품 식별 문제가 신뢰와 비즈니스 위험으로 이어졌다.

Bet

숙박 운영자의 고통과 MVP의 사업 학습을 바탕으로, 공식 OTA/PMS 연동 기술과 국내·글로벌 OTA/PMS 스펙을 고려한 구조를 만들면 여전히 매력적인 사업이 될 수 있다고 봤다.

Action

글로벌 OTA/PMS 확장을 기준으로 기획과 구조를 다시 잡았다. 채널별 프로세스와 요금 동기화 스펙을 설계하고, 긴급 설정/수정 업무를 셀프온보딩 쪽으로 옮겼다. 내부/외부 알림과 빠른 수정 가능성도 함께 설계했다.

Result

클로즈드 베타 안정성 검증을 완료했고 정식 출시와 구독 전환을 계획했다. 불안정한 예약/재고/요금 동기화 구조를 통합 구조로 개선했으며, 운영 리스크를 줄이고 공식 국내·글로벌 OTA 연동, 다국어 준비, 무설치 서비스 환경을 마련했다.

Problem

합류 당시 Vendit Concierge는 기획과 디자인이 이미 끝나고 개발이 진행 중이었다. 결제, 룸서비스, IoT 제어처럼 아이디어 중심 범위가 컸지만 우선순위, 시장 반응, 정산 모델, 운영 검증은 분명하지 않았다.

Bet

초기 마케팅 수요가 있던 얼리/레이트 체크아웃 같은 업셀 기능을 먼저 내고, 룸서비스와 IoT는 뒤로 미루면 낭비를 줄이며 시장 검증을 할 수 있다고 봤다.

Action

중간에 PM으로 합류해 과도한 범위의 절반 이상을 덜어냈다. 팀 우선순위를 다시 잡고 결제 모듈을 먼저 출시했으며, 시장 규모와 중복 PG 등록 같은 구조적 위험을 분석해 리더십에 확장 리스크를 보고했다.

Result

국내 시장은 100억 원 미만, 글로벌 시장은 1조 원 미만으로 추정되어 확장 매력이 낮다고 판단했다. 핵심 기능만 유지하고 추가 기능 개발을 멈췄으며 리소스를 재배치했다.