박우석Portfolio / Operations & Automation
박우석 · 서비스운영팀장 · 운영혁신 · 업무자동화

운영 문제를
정책과 시스템으로
해결합니다.

청소 매칭 플랫폼 청연의 서비스운영팀장 박우석입니다. 1차 운영을 재택으로 이관하고, 필요한 업무 시스템을 직접 구축했습니다.

경력 요약 / Experience

청연 · 서비스운영팀장

2020.04–현재 재직 · 서비스운영팀장 · 리스크관리(RM)팀장 겸직(2021.01부터)

1차 운영의 재택 이관을 주도해, 본사가 핵심 기획과 운영 개선에 집중하는 조직으로 전환했습니다.

대표를 설득해 재택상담 인력을 확충하고, 교육 기준·업무 배분·본사 지원 체계를 정비했습니다. 재택상담사의 역할을 전화·채팅 등 1차 운영으로 넓혔습니다.

분석·기획SQL · VOC 분석 · 정책 설계
관리 범위5개 파트(사무실 포함) · 약 30명 규모 재택상담 조직 · 성과 평가

이전 경력 제조 품질관리 · 창업·판매 · 서비스 운영
  1. 2014–2016

    SIMPAC · 품질관리

    품질 기록의 ERP 전산화 TFT에 참여하고, 협력사 품질·검사 이력을 관리했습니다.

  2. 2016–2018

    창업 · 이커머스 운영

    반려동물 정보 서비스 MVP를 구축했으나 출시 전에 종료했고, 이후 주얼리 이커머스를 운영했습니다. 상품 소싱부터 상세페이지·판매·고객 응대까지 직접 수행했습니다.

  3. 2018–2019

    제품 개발·품질 · 서비스 운영

    햇빛일루콤의 자동차 전장품 개발 일정·품질관리, 로킷헬스케어의 제품 검사·ISO 인증 준비, 미소의 펫시터 매칭 정책·운영을 경험했습니다.

Projects

운영 현장에서 직접 설계하고 구축한 두 시스템입니다.

업무 환경

청소 서비스의
상담·운영 구조

청연은 고객과 청소 매니저를 연결하는 청소 매칭 플랫폼입니다. 청연에서는 약 30명 규모의 재택상담사가 고객과 청소 매니저의 문의에 답합니다. 직접 처리하기 어려운 문의는 본사관리자에게 확인합니다. 상담사는 1차 응대에 집중하고, 본사관리자는 권한이 필요한 처리와 예외 판단을 맡는 구조입니다.

청소 매니저
고객 집을 방문해 청소 서비스를 제공하는 인력
재택상담사
고객·매니저 문의의 1차 상담과 안내
본사관리자
운영 기준 안내, 승인·예외 판단, 업무분장 관리
Slack 핫라인
상담사가 처리 방법과 판단을 본사에 묻는 내부 문의 채널
빙고 · 상담 지원 봇·KMS

사례를 찾고 질문한 뒤,
상담 결과까지 남깁니다.

상담사는 Slack의 이전 답변과 Notion 매뉴얼을 따로 찾아봐야 했습니다. 근거와 답변 초안을 주는 빙고를 만들고, 기존 업무 웹앱에 상담 지원 KMS를 구축했습니다. 사례 검색과 질문, 상담 결과와 개선 의견 기록을 한곳에 연결했습니다.

제 역할
설계부터 구축·운영까지 직접 담당
구현
Python · React · Claude Code · Codex
사용 환경
재택상담사 Slack 핫라인 · 업무 웹앱
지식 검색
PostgreSQL + pgvector 직접 운영
연결·검증
Slack Bolt · Notion API · Pydantic

사례를 검색하고, 당시 답변을 바로 확인합니다.

Slack에 흩어진 상담을 업무 웹앱에서 찾아봅니다. 최근 사례와 원칙 문서를 나누고, 필요한 답변의 원문으로 이어지도록 했습니다.

빙고 KMS의 사례 검색 화면. 매니저 취소 검색 결과와 당시 담당자 답변 미리보기, 원칙 문서 탭이 보인다.화면 크게 보기 ↗
실제 웹앱 캡처. 자료 검토 모드이며, 200건은 해당 화면의 검색 결과 표시입니다. 누적 상담 실적을 뜻하지 않습니다. 직원 이름과 내부 링크 등 식별 정보만 가렸습니다. 표시된 날짜·배정·수치는 원본 그대로입니다.
실제 KMS 화면 · 질문과 나의 기록

사례로 답을 찾지 못하면, 같은 곳에서 질문합니다.

상황과 관련 링크를 넣어 질문하고, 이전 질문과 처리 결과를 다시 찾아볼 수 있게 했습니다. 자료 검토와 실제 상담은 용도를 구분합니다.

빙고 KMS의 질문 입력과 나의 질문 기록 화면. 자료 검토 용도와 상담 실적 제외 표시가 보인다.화면 크게 보기 ↗
실제 웹앱 캡처. 선택된 자료 검토 모드의 입력·기록 화면이며, 실시간 답변을 실행하는 데모가 아닙니다. 직원 이름과 내부 링크 등 식별 정보만 가렸습니다. 표시된 날짜·배정·수치는 원본 그대로입니다.

상담사와 관리자가 같은 기록을 봅니다.

사례부터 찾아보거나 바로 빙고에 질문할 수 있습니다. 답변을 확인한 뒤에는 처리 결과와 불편했던 점을 남깁니다.

  1. 사례·원칙 찾기

    비슷한 상황과 당시 답변을 보고 Slack·Notion 원문을 확인합니다.

  2. 빙고에게 질문

    상황과 관련 링크를 넣고 답변 초안과 출처를 확인합니다.

  3. 결과·의견 남기기

    실제 상담 결과와 교육 중 자료 검토를 구분해 기록합니다.

관리자는 고칠 부분을 확인합니다.

답변이 다르거나 자료를 찾기 어려웠다는 기록을 모아, 원인을 확인하고 조치한 뒤 다시 시험합니다.

업무 흐름을 설명한 도식입니다. 실제 웹앱 캡처가 아닙니다.

이전 Slack 운영 기록 · 2026.10.05 리포트

당시 7일 기록

257건 중 187건에 초안 제공 72.8%

2026.10.05 생성 리포트의 최근 7일 집계이며, 누적 제공 건수가 아닙니다. 계속 운영 중인 빙고봇의 특정 시점 기록입니다. 초안 제공률은 정확도나 문의 해결률과 다릅니다.

리포트 수치의 기준

2026.10.05 생성 · 최근 7일 집계 · impact_history.json과 impact_report.py 대조

  • 초안 제공 비율: 질문 257건 중 초안 187건, 72.8%.
  • 초안 활용 추정률: 초안과 본사관리자 답변을 비교한 80건 중 43건, 53.8%. 모델이 참고·활용 여부를 추정한 값이며, 사람이 누른 채택 버튼 비율은 아닙니다.
  • 답변 일치 지표: 비교 가능하다고 분류한 55건 중 일치 30건, 54.5%. 이 역시 모델의 비교 판정이며, 전체 답변의 정확도나 고객 문의 해결률을 뜻하지 않습니다.

현재 운영 수치가 아니라 해당 시점의 기록입니다.

과거 답변을 그대로 따라 쓰지 않도록 했습니다.

같은 질문처럼 보여도 당시 조건이 다르면 안내가 달라집니다. 사례에서는 상황과 원문을 먼저 확인하게 하고, 교육 중 검토한 기록은 실제 상담 결과와 나눴습니다. 예외 승인이 필요한 문의는 본사관리자가 판단하도록 했습니다.

빙고봇 도입 전후의 업무 방식
업무BeforeAfter
기준 찾기비슷한 문의에도 본사관리자가 정책과 기록을 다시 검색빙고봇이 운영 지식과 관련 기록을 조회해 근거와 초안 제공
처리 판단처리 방법을 본사에 문의확인된 기준으로 안내하고, 추가 확인·예외 승인이 필요한 문의는 본사로 이관하도록 설계
답변 재사용이전 답변이 Slack 대화에 흩어짐본사관리자가 검증한 답을 다음 상담에서도 찾아 쓰도록 구성
상담 지식 재사용 분석 · 178건 검토

재사용 후보 178건을 검토한 분석 메모에서, 근거 사례 116건을 28개의 기준 후보로 묶었습니다.

분석 메모에서 묶은 주제 일부
주제근거 사례
서비스 범위 밖 요청5건
예약 단위·부분 청소6건
평수 입력 기준6건

2026.08.03 분석 메모 · 학습 대기 기록 중 재사용 후보 검토. 운영 정책으로 승인된 항목 수나 전체 문의 통계는 아닙니다.

근거가 부족한 답은 본사에 넘기도록 설계했습니다.

청소 서비스의 예외 상황은 본사관리자 사이에서도 판단이 달랐습니다. 확인된 기준으로 답하는 범위와 사람이 판단할 범위를 나눴습니다.

기존 사례를 다시 풀게 하는 회귀 평가도 AI가 답을 판정합니다. 평가 점수만으로 실제 상담에 써도 되는 답이라고 단정할 수는 없습니다. 근거가 부족한 답은 추가로 확인하거나 본사관리자에게 넘기도록 설계했습니다.

Slack 상담 답변 지원 봇의 질문 처리 과정

상담사가 질문하면 필요한 자료를 찾고, 근거를 확인한 뒤 답변 방식을 정합니다. 단계를 눌러 처리 방식과 판단 기준을 볼 수 있습니다. 사용 기술은 각 단계에서 펼쳐볼 수 있습니다.

질문의 의도와 필요한 근거 정리

어떤 상황에서 무엇을 묻는지 파악하고, 답변 전에 확인할 정보를 정리합니다. 첨부 이미지의 글자도 읽어 질문과 함께 확인합니다.

사용 기술 보기Python · Slack Bolt · OCR · QuestionFrame · Pydantic

정책과 실제 상담·예약 기록 조회

질문에 필요한 정책과 이전 상담·예약 기록을 찾습니다. 답변에 필요한 근거가 빠져 있으면 추가로 조회합니다.

사용 기술 보기ResearchPlanner · ResearchExecutor · PostgreSQL + pgvector · OpenAI Embeddings · API 조회

근거의 충분성과 인용문 확인

답변에 필요한 자료가 모였는지 확인한 뒤 초안을 만듭니다. 인용한 문장이 실제 원문에 있는지 대조하고, 정책을 상황에 맞게 적용했는지는 본사관리자가 검수합니다.

사용 기술 보기OperationalDraft · EvidenceVerifier · 인용문 대조 · 본사관리자 검수

확인 결과에 따라 응답 방식 선택

근거와 답변 초안을 질문한 대화에 남깁니다. 정보가 부족하면 추가로 묻고, 예외 판단이 필요하면 본사관리자에게 넘깁니다. 조건에 따라 답변을 남기지 않기도 합니다.

사용 기술 보기answer · clarify · escalate · silent · OpenAI Agents SDK의 답변 표시 단계
답변 초안

근거와 출처를 함께 제공

추가 질문

확인할 정보가 더 필요

본사 이관

고객 확인·예외 판단 필요

무응답

조건에 따라 답변하지 않음

검증한 코드와 설계를 요약한 설명입니다. 실시간으로 빙고봇을 실행하는 화면은 아닙니다.
기술 구성 · 근거 검증 · 학습 · 운영
Slack · 상담사 내부 문의 채널동작 방식
“이건 어떻게 처리하나요?”
빙고봇이 운영 지식과 관련 기록 조회 · 답변 근거 확인
근거로 안내할 수 있는 질문

봇이 답변 초안 작성

처리 절차와 근거 링크를 질문한 스레드에 남기도록 설계했습니다.

고객 확인·예외 판단이 필요한 질문

본사관리자에게 이관

확인된 내용과 추가로 판단할 내용을 구분해 넘기도록 설계했습니다.

답변과 이관의 설계 흐름을 설명한 도식입니다. 실제 Slack 화면이나 답변 인용은 아닙니다.

별도 확인 사례 · 교육 신청기한

2026.10.06 매니저 재등록 교육 문의는 12:38:08에 올라왔고, 빙고봇은 12:38:48에 답했습니다. 문의부터 답변까지 40초는 이 한 사례의 메시지 시각 차이입니다. 질문자의 ‘도움됐다’ 표시와 제가 추가한 👍 반응은 각각 확인했습니다.

질문 해석 · 입력 검증

Python·Slack Bolt로 상담사의 질문을 받고, 이미지가 있으면 OCR로 텍스트를 추출합니다. QuestionFrame에 사건 식별값(case_id), 질문 의도(intent), 필요한 근거(required_evidence)를 담습니다. required_evidence는 표준 코드로 지정하고 Pydantic 스키마로 검증합니다. 선언되지 않은 필드는 extra="forbid"로 차단합니다.

Agentic RAG · 조사 계획과 자료 조회

ResearchPlanner가 근거 코드에 맞춰 조사할 도구를 정하고, ResearchExecutor가 병렬로 조회합니다. 예약·취소 이력, 채팅 로그, Notion 지식, Slack 이력 등을 확인하며 조건에 따라 GitHub 코드도 조회합니다. 모은 근거가 지금 질문에 충분한지 확인하고, 부족하면 다시 조사합니다.

PostgreSQL · pgvector 직접 운영

PostgreSQL에 pgvector를 붙여 운영 지식의 벡터 검색을 구성했습니다. OpenAI Embeddings를 사용하며 임베딩 갱신을 정기 작업으로 돌립니다. 검색 결과와 실제 운영 기록을 답변 근거로 모읍니다. 기존 업무 웹앱에 상담 지원 KMS를 구축했습니다. 상담사가 사례와 원칙을 찾고 질문한 뒤 결과를 남기며, 관리자는 이용 기록과 개선 의견을 확인합니다. 과거 사례는 현재의 공식 정책과 구분해 확인하도록 했습니다.

근거 검사 · 인용문 대조

OperationalDraft에 판정, 분석, 실행 단계와 근거 링크를 담습니다. EvidenceVerifier는 필수 근거와 고위험 정책의 충족 여부를 검사합니다. 답변 표시 코드에서는 evidence_quote가 근거 원문에 포함되는지 대조합니다. 인용문 검사를 모델의 판단에만 맡기지 않았습니다.

인용이 맞아도 정책을 적용한 판단까지 맞는 것은 아닙니다. 그래서 근거의 충분성 확인과 본사관리자 검수를 함께 둡니다. 결과는 answer(답변), clarify(추가 질문), escalate(본사관리자 이관), silent(무응답)로 나눕니다.

검수 기록 · 학습 · 회귀 검사

스레드에 초안과 근거 링크를 남기고, 본사관리자의 채택·정정·‘가르치기’ 기록을 받습니다. 수정된 필드를 기록해 학습에 반영합니다. 본사관리자가 답을 정정했더라도, 그 상담에서 승인한 예외까지 일반 기준으로 저장해서는 안 됩니다.

골든케이스 회귀 검사, ablation 평가와 이벤트 리플레이를 둡니다. 주간 임팩트 리포트에서는 초안 제공 비율, 본사관리자 답변 일치율, 초안 활용 추정률과 선응답 시간을 확인합니다. 사람이 확인할 답이 쌓였을 때는 답변 품질만 높이기보다 검수 흐름을 다시 설계했습니다.

프로세스 복구 · 정기 작업

launchd → watchdog.py → bingo_bot.py 복구 체인을 두고 운영합니다. impact_report.py로 주간 리포트를 만들고, 지식 갱신과 회귀 검사를 정기 실행합니다. 실행 도구, 근거, 검증 실패와 trace ID를 남기며 개인정보는 pii_mask 모듈로 처리합니다.

스택은 Python, Slack Bolt, PostgreSQL·pgvector, Notion API, OpenAI Embeddings입니다. OpenAI Agents SDK는 답변 표시(present) 단계에 사용합니다.

02 / 통합 근무 관리 시스템

근무·배정을 통합하고,
인원 부족을 바로 알립니다.

시간마다 여러 표를 맞춰 보던 근무·업무분장·휴가 정보를 하나로 통합했습니다. 자동배정과 승인 기능을 직접 구축하고, 운영 중 인원이 부족하면 화면 경고와 Slack 알림으로 알려 관리자가 배정을 조정할 수 있게 했습니다.

제 역할
설계·구축 · Git 관리 · Docker 패키징
구현
React · Claude Code · Codex
서버 적용
개발팀 협조
관리 범위
근무계획 · 자동배정 · 승인 · 권한 · 운영 이력

달라진 업무

사람이 표를 대조해 찾던 공백을,
시스템이 먼저 알려주도록 바꿨습니다.

본사관리자는 알림에서 부족한 시간과 역할을 확인하고 배정을 조정합니다. 재택상담사도 같은 현황을 보고 누락된 인원이나 배정을 제보합니다.

인원 부족을 판단하는 기준

출근 인원이 아니라, 그 시간에 실제 상담을 맡을 수 있는 인원을 계산했습니다. 점심·휴가·근무시간을 반영해 30분 단위로 역할별 최소 인원과 비교합니다. 자동배정 결과의 형평성과 예외는 관리자가 검토하고, 운영 중 부족한 구간은 경고·알림으로 확인합니다.

실제 운영 중인 관리자 기능

배정표 조회부터 승인과 운영 관리까지 연결했습니다.

  1. 01 근무계획

    월별 근무패턴과 공휴일·추가 근무를 관리합니다.

  2. 02 자동배정

    근무 조건에 맞춰 배정 후보를 만들고 관리자가 예외를 검토·조정합니다.

  3. 03 검토·승인

    배정안을 최종 승인하고, 휴가 신청과 근무 변경을 처리합니다.

  4. 04 일일 운영

    화면 경고와 Slack 알림으로 부족한 시간·역할을 확인하고 배정을 조정합니다.

관리자 기능의 업무 흐름을 요약했습니다. 아래 실제 관리자 화면에서 시간대별 배정과 안전선 미달 표시를 볼 수 있습니다.

인원이 부족한 시간대를 먼저 표시합니다.

출근 인원만 보는 대신, 시간대별 실제 배정과 역할을 확인합니다. 최소 인원에 못 미치는 구간은 붉게 표시하고, 오른쪽에 미달 구간을 모아 관리자가 보충할 곳을 찾도록 했습니다.

최신 관리자 업무분장 화면에서 07시 30분과 12시 30분 안전선 미달을 붉게 표시하고 오른쪽에 점검 슬롯 23개와 미달 구간 2개를 보여준다.화면 크게 보기 ↗
실제 관리자 UI. 선택된 배정 날짜는 2026.10.04이며, 안전선 점검 23개 구간 중 2개 미달은 이 화면의 배정 상태입니다. 직원 이름과 내부 링크 등 식별 정보만 가렸습니다. 표시된 날짜·배정·수치는 원본 그대로입니다.
스케줄 시스템 도입 전후의 업무 방식
업무BeforeAfter
근무 확인엑셀을 한 줄씩 대조하며 시간대별 담당자 확인근무시간과 부재를 반영해 역할별 인원 계산
결원 대응본사관리자가 표를 계속 보며 공백 확인화면 경고·Slack 알림으로 부족한 시간·역할을 확인해 배정 조정
관리 범위점심·휴가·결원이 생길 때마다 배정을 다시 확인근태·업무분장과 휴가 승인·추가근무를 한 시스템에서 관리
본사관리자와 재택상담사가 함께 확인하는 방식

본사와 재택상담사가 같은 현황을 봅니다.

업무분장 시스템시간대별 근무 가능 인원과 부족한 역할
본사관리자화면 경고·Slack 알림 확인

부족한 시간과 역할을 확인하고 배정을 조정합니다.

재택상담사공동 화면 확인·제보

같은 업무분장 화면을 보고 빠진 인원이나 배정을 알려줍니다.

근무 현황과 인원 부족 알림을 함께 확인하는 실제 운영 방식을 정리했습니다.
최신 관리자 화면 · 역할 전환·점심·지난 시간 접기

역할 전환과 점심까지 같은 배정표에서 봅니다.

고객 상담·매니저 상담 배정과 출근·점심·이슈당번을 한 화면에 모았습니다. 역할이 바뀌는 시점은 별도로 표시합니다.

2026년 11월 5일 업무분장 계획 화면. 시간대별 고객·매니저 상담 배정, 역할 전환 표시, 오른쪽 출근·점심·이슈당번 현황이 보인다.화면 크게 보기 ↗
실제 관리자 화면. 2026.11.05 계획 조회이며, 화면의 안전선 충족 표시는 선택된 배정의 점검 결과입니다. 직원 이름과 내부 링크 등 식별 정보만 가렸습니다. 표시된 날짜·배정·수치는 원본 그대로입니다.

지난 시간대는 접고, 필요한 배정을 봅니다.

시간이 지난 배정은 기본 화면에서 접어둡니다. 필요한 경우 ‘지난 시간 펼치기’로 다시 확인할 수 있어, 현재와 이후에 확인할 내용에 집중하도록 했습니다.

지난 시간 07시 30분부터 19시까지 19칸 펼치기 버튼과 출근·점심 요약이 보이는 관리자 화면. 지난 시간대가 접혀 중앙 배정 목록이 비어 있다.화면 크게 보기 ↗
실제 관리자 화면. 중앙 여백은 지난 시간대가 접힌 상태입니다. 배정이 없거나 화면이 로딩되지 않은 상태를 뜻하지 않습니다. 직원 이름과 내부 링크 등 식별 정보만 가렸습니다. 표시된 날짜·배정·수치는 원본 그대로입니다.
배정 검사 · 승인 권한 · 구현과 배포
업무분장 · 근무 가능 인원구조 설명
시간대별 근무 가능 인원

휴가·반차·점심·근무시간을 배정과 함께 확인하고, 역할별 최소 인원과 대조했습니다.

근무 정보근무시간 · 휴가 · 점심
역할별 배정고객 상담 · 매니저 상담 · 예외 처리 담당
30분별 인원 검사필요한 인원에 못 미친 구간 표시
부재자는 배정에서 표시하고, 점심 중인 인원은 별도 구분했습니다. 본사관리자는 부족한 구간을 확인해 배정을 조정합니다.
React 소스의 근무 인원 계산과 배정 검사 구조를 정리한 도식입니다. 실서비스 화면과 직원 정보는 사용하지 않았습니다.

휴가·점심을 반영한 근무 인원 계산

점심·휴가·반차와 근무시간을 확인해 실제 근무 인원을 계산했습니다. 휴가자는 원래 역할에 취소선으로 남겨 누가 빠졌는지 보이도록 했습니다. 점심 인원은 별도 줄로 구분했습니다.

시간대별 최소 인원 검사

30분별 고객 상담·매니저 상담·예외 처리 담당 인원을 최소 인원 기준과 대조했습니다. 평일·주말·점심·늦은 근무시간의 기준을 나누고, 부족한 시간과 역할을 표시하도록 만들었습니다.

파트별 휴가 승인 권한

휴가 신청에는 승인·반려·철회 상태를 뒀습니다. 승인자는 신청자의 소속 파트와 권한에 따라 제한하고, 서버에서도 같은 권한을 확인하도록 구성했습니다.

발행된 배정 조회 · 중복 알림 차단

Python 모니터가 웹앱 업무분장 API를 조회해 전환 계획을 계산합니다. 전환 대상자만 DM 경로에 넣고, 같은 시각의 중복 발송을 막습니다. Slack 현황봇에는 퇴근 시각이 지났는데 상담 상태가 남은 인원을 확인하는 안내도 구성했습니다.

React 구현 · Git 관리 · Docker 배포

React로 화면을 만들고 Git으로 변경을 관리했습니다. 구현에는 Claude Code와 Codex를 썼습니다. 직접 Docker로 패키징했고, 서버 적용에는 개발팀의 협조를 받았습니다.

운영·사업 경험 / Operations & Business

반복 업무를 줄이고,
가격과 이용 조건도 바꿨습니다.

반복 확인은 자동화하고, 미수가 발생하는 이용 조건은 바꿨습니다. 고객 문의와 지역별 수요·공급은 신규 상품과 가격 기준으로 연결했습니다.

반복 확인 업무

Auto-call

API 조사 · Postman PoC · 개발팀 협업

95% 이상 감소 — 본사관리자의 서비스 진행 확인전화

청소 매니저가 앱에서 출발·시작 상태를 누르지 않으면 서비스가 진행되는지 본사관리자가 전화로 확인해야 했습니다. 놓치면 노쇼 대응이 늦어질 수 있는 업무였습니다.

지자체의 불법주차 자동전화에서 착안해 기존 통화 솔루션의 API를 조사하고 Postman으로 시험했습니다. 예약시간과 앱 상태에 따른 발신 조건을 정하고 개발팀과 운영에 적용했습니다.

변화본사관리자의 반복 확인전화 → 조건에 따른 자동 발신
결제·이용 정책

미수금 예방

데이터 분석 · 본인확인 도입 추진 · 결제·이용 조건 설계

미수가 반복되는 이용 조건을 찾아,
결제·이용 정책을 바꿨습니다.

회수 전화가 반복돼, 미수가 발생하는 이용 조건부터 데이터를 확인했습니다.

데이터에서 반복되는 패턴을 살펴보니, 1회 이용 고객이 결제에 실패해도 서비스를 이용할 수 있었습니다. 돈을 받는 절차를 보완해도 미수가 생기는 조건은 남아 있었습니다.

본인확인 도입을 설득하고, 선결제와 미결제 고객의 이용 제한·취소 규칙을 설계했습니다. 미수를 회수하는 일과 함께, 미결제 상태로 서비스를 계속 이용하는 조건을 바꿨습니다.

Before결제 실패 후에도 이용 가능

서비스 이용 후 미수 발생
본사관리자가 회수 전화

After결제 여부를 이용 조건에 반영

선결제·미결제 시 이용 제한과 취소
반복 미수 예방

잔존 미수 건수 28.2% 감소
848건 → 609건

2024.07.29 → 2025.04.01 · 회수·취소·신규 발생을 반영한 미수현황 보고서 기준. 정책 변경의 단독 효과를 측정한 수치는 아닙니다.

수요·공급과 가격

다이나믹 프라이싱

지역별 공급 · 예약 수요 · 요금 체계

2단계 → 8레벨 — 지역별 수요·공급에 맞춘 가격 기준

서울·경기·인천의 가격을 크게 두 단계로 나누던 방식에서, 청소 매니저 공급과 지역별 수요를 보고 동 단위로 가격을 세분화했습니다. 지역 7레벨과 대형 평수 1레벨을 더한 8레벨 체계로 바꿨습니다.

변화가격 2단계 → 수요·공급을 반영한 8레벨
고객 문의에서 상품으로

원룸·임박 예약

VOC 분석 · 상품 초기 기획 · 출시

13,043건 완료 — 원룸 청소
약 1억 2,500만 원 — 수수료

2024년 4~12월 · 8평 이하 집계

“작은 집에도 기본 요금을 내야 한다”는 고객 문의에서 원룸 청소를 기획했습니다. 예약 마감 이후에도 이용하고 싶다는 수요는 임박 예약 상품으로 연결했습니다.

원룸 청소2024.04 출시
임박 예약2025.03 출시2주간 1,914건 · 2025년 4월 초 작성 자료
서비스·지역 확장주방 부분 청소 · 레거시 요금 개편 · 신규 지역 오픈

기존 가격 유지 고객의 요금을 개편했고, 주방 부분 청소의 서비스 구성과 가격을 기획했습니다. 강원·전남·경남의 신규 서비스 지역 오픈과 지역별 수요에 맞춘 요금 체계도 맡았습니다.

운영 리포트상담 인입·고위험 이슈 집계와 알림

상담 인입과 고위험 이슈를 주간 단위로 집계하고, 이상 징후를 놓치지 않도록 알림과 보고 절차를 만들었습니다.

리스크 관리고객 보상 협의 · 소비자기관 대응 · 재배정 중단 판단

화재·분실 등 고위험 이슈의 사실관계를 확인하고 고객과 직접 협의했습니다. 고객의 피해와 회사의 지급 근거를 검토해, 경영진·법률 자문과 보상안 및 대응 방향을 조율했습니다.

  • 보상 동의와 재이용 예약까지협의가 멈춘 분실 사건에서 고객과 직접 통화해 우려를 확인하고 설명한 뒤 보상 동의를 받았습니다. 이후 재이용 예약에 맞춰 대체 인력의 매칭과 사전 안내까지 챙겼습니다.
  • 거래 데이터를 재검증해 분쟁 회신 근거 정정요금 분쟁에서는 예약·결제·정산 내역을 재검증해 회신의 금액 근거를 정정하고, 경영지원 검토를 반영해 소비자기관에 회신했습니다.
  • 반복 이슈가 있는 인력의 재배정 중단반복된 분실 의심 이력을 근거로 기존 정기 고객의 배정도 중단해야 한다고 판단했습니다. 이후 담당자가 배정을 중단하고, 기존 고객에게 대체 매칭을 안내했습니다.