이 글의 순서
핵심 내용
청소 예약 앱을 준비할 때 ‘날짜를 고르고 매니저를 예약한다’고 설명할 수 있습니다. 그런데 매주 방문하는 서비스라면 정기 이용 조건을 한 번 신청한 뒤에도 방문할 때마다 확인할 일이 남습니다. 이번에는 누가 방문하는지, 현장에서 무엇을 확인해야 하는지, 어느 방문의 청소가 끝났는지를 구분해야 합니다.
먼저 정기 이용에 공통으로 적용할 조건과 실제 방문 한 건의 일정·담당자·진행 상태를 나누어 적어보세요. 고객의 신청 내용이 매니저의 방문 업무로 이어지고 운영자가 같은 방문을 확인할 수 있도록 개발 범위를 정하는 방법을 살펴보겠습니다.
날짜와 함께 방문에 필요한 청소 조건을 받습니다
같은 날짜에 신청해도 청소할 공간과 요청은 다를 수 있습니다. 주거 공간인지 사무실인지, 방과 화장실이 몇 개인지, 반려동물이 있는지에 따라 매니저가 방문 전에 확인할 내용도 달라집니다.
예약 입력 항목은 그 정보가 청소 업무에 어떻게 쓰이는지를 기준으로 골라보세요. 주거 공간의 방 개수가 필요한 서비스도 있고, 사무실의 청소 구역과 이용 가능 시간을 먼저 확인해야 하는 서비스도 있습니다. 모든 청소 종류에 같은 항목을 필수로 받을 필요는 없습니다.
요청사항에 적힌 내용을 매니저가 어디서 보는지도 함께 정합니다. 고객이 ‘욕실 바닥을 먼저 확인해 주세요’라고 남겼다면, 신청 화면에만 저장되는 것이 아니라 해당 방문의 업무 상세에서도 확인할 수 있어야 합니다. 출입방법과 도구 위치처럼 현장에서 필요한 정보는 무엇이며 누가 확인할지도 정해두세요.
정기 이용 조건과 방문 한 건을 나누어 봅니다
‘매주 월요일에 방문해 주세요’는 반복해서 적용할 정기 이용 조건입니다. ‘이번 월요일에는 누가 몇 시에 방문하며 청소를 시작했는가’는 실제 방문 한 건의 정보입니다. 둘을 한 상태로 합치면 한 번 청소를 마친 뒤 다음 방문까지 완료된 것처럼 보일 수 있습니다.
예를 들어 공통 조건에는 매주 월요일·주거 공간·반려동물 없음을 두고, 방문 목록에는 각 방문의 날짜와 시간·담당자·진행 상태를 따로 보여주는 방식으로 설계할 수 있습니다. 담당자가 정해진 방문과 확인이 필요한 다음 방문을 구분해 볼 수 있습니다.
정기 이용을 신청했다고 해서 모든 방문의 일정과 담당자가 한꺼번에 확정된 것은 아닙니다. 앞으로의 일정을 언제 얼마나 만들지, 담당자를 방문마다 정할지, 정해진 담당자를 이어갈지는 서비스의 운영 방식에 맞춰 선택하세요. 달력에 반복 표시하는 기능과 실제 방문 업무를 확정하는 기능도 같은 범위로 보지 않습니다.
이번 방문의 시간만 바꾸는 경우와 이후 방문에도 새 시간을 적용하는 경우도 구분해야 합니다. 처음부터 복잡한 일괄 변경을 넣을 필요는 없지만, 첫 버전에서 어디까지 바꿀 수 있고 나머지는 운영자가 어떻게 처리할지는 요청서에 남겨두세요.

방문할 담당자를 누가 결정할지 고릅니다
요청에 지원한 매니저 중 고객이 한 명을 선택하는 서비스와 운영자가 가능한 담당자를 배정하는 서비스는 필요한 화면과 확인 절차가 다릅니다. 첫 개발에서는 어떤 방식으로 담당자를 정하고, 그 결과를 어느 방문에 연결할지부터 고르세요.
고객 선택 방식이라면 지원 매니저의 정보와 선택 결과가 필요합니다. 운영자 배정 방식이라면 운영자가 일정과 조건을 확인하고 담당자를 지정할 수 있어야 합니다. 고객의 선택이 끝나기 전 지원한 상태와 방문 담당자로 정해진 상태를 구분해야 매니저도 어떤 업무를 수행할지 알 수 있습니다.
정기 이용에서는 이번 방문의 담당자가 정해졌는지, 다음 방문도 같은 조건으로 이어지는지를 따로 정합니다. 자동 추천이나 자동 배정은 첫 버전의 필수 조건으로 묶지 말고, 실제 담당자 결정 방식을 설명한 뒤 필요한 범위를 선택하세요.
방문 업무에서 현장 정보와 시작·완료를 연결합니다
담당 매니저는 자신의 방문 목록에서 일정과 진행 상태를 보고, 업무 상세에서 공간 정보·요청사항·출입방법·도구 위치를 확인하는 흐름으로 구성할 수 있습니다. 고객이 입력한 조건을 매니저가 다시 찾아 묻지 않도록 해당 방문과 연결하는 것이 핵심입니다.
청소를 시작하거나 마칠 때도 어느 방문을 처리하는지가 분명해야 합니다. 정기 이용 전체에 ‘완료’를 표시하기보다 이번 방문의 진행 상태를 바꾸도록 범위를 정하세요. 시작·완료에 필요한 입력과 완료 뒤 수정할 수 있는 범위, 잘못 처리했을 때 운영자가 확인할 방법도 함께 정할 수 있습니다.
청소 완료와 결제·정산 완료는 서로 다른 결과입니다. 청소를 마쳤다는 표시만으로 요금이 결제됐거나 매니저 정산까지 끝났다고 안내하지 않습니다. 결제와 정산을 함께 개발한다면 각각 확인할 상태와 담당 업무를 구분하세요.
운영자는 날짜와 진행 상태를 기준으로 방문 업무를 찾아 담당자 미정, 방문 변경, 취소 요청처럼 확인이 필요한 건을 처리하도록 범위를 정할 수 있습니다. 현장 사진 제출이나 위치 추적은 이 흐름에 반드시 포함되는 기능이 아닙니다. 서비스에 필요한 이유와 처리 방법을 확인한 뒤 따로 선택합니다.

첫 개발 요청에는 방문 한 건의 흐름을 담습니다
개발을 의뢰할 때 ‘정기청소 예약 앱’이라는 기능명만 전달하기보다 고객이 조건을 입력한 뒤 매니저가 방문하고 운영자가 확인하는 한 건의 흐름을 적어보세요. 다음 항목이면 첫 범위를 구체적으로 논의할 수 있습니다.
확인해보세요
- 청소 조건: 어떤 공간과 요청을 받으며 매니저에게 어떤 정보를 보여줄지
- 정기 이용: 반복 주기·희망 요일과 실제 방문 일정을 어떻게 구분할지
- 담당자 결정: 고객 선택 또는 운영자 배정 중 첫 방식과 확정 시점
- 방문 업무: 목록·상세에서 볼 일정·현장 정보와 시작·완료 처리
- 운영 확인: 담당자 미정·변경·취소와 잘못 처리한 업무를 누가 확인할지
- 추가 범위: 결제·정산·채팅·사진 제출 등 처음부터 필요한 기능과 후속 기능
정기 이용 조건 한 개와 방문 업무 한 개를 실제로 적어보면 빠진 연결을 찾기 쉽습니다. 반복 일정의 자동 생성이나 일괄 변경, 복잡한 배정 규칙은 운영 방식에 꼭 필요한지 확인한 뒤 첫 범위에 넣으세요.
클린메이트는 예약 조건과 매니저 업무를 연결했습니다
클린메이트는 고객의 1회·정기 청소 예약과 매니저의 업무, 관리자 운영을 연결한 개발 사례입니다. 고객 앱에서는 청소 종류와 정기 주기·요일, 날짜와 시간, 공간 정보·요청사항을 입력하고 지원 매니저의 프로필·리뷰를 살펴본 뒤 직접 선택합니다.
매니저는 요청에 지원하고 고객이 선택하면 내 업무에서 배정된 일정을 확인해 청소 시작·완료를 처리합니다. 업무 상세에서는 공간 정보와 요청사항, 출입방법과 도구 위치를 확인합니다. 관리자는 매니저 신청의 승인·반려, 1회·정기 예약과 요청·취소 내역, 정산 상태를 관리합니다.
고객이 입력할 정보와 매니저가 처리할 업무, 운영자가 확인할 내용을 함께 정하는 범위를 살펴볼 수 있는 사례입니다. 아래 포트폴리오에서 고객·매니저 앱과 관리자 구성을 이어서 확인해보세요.
자주 묻는 질문 1 — 정기 예약이면 방문 일정도 모두 자동으로 만들어야 하나요?
운영 방식에 따라 다릅니다. 일정 생성 시점과 기간, 고객에게 확정으로 보여줄 조건을 먼저 정하세요. 운영자가 다음 방문을 확인하는 방식으로 시작할 수도 있습니다. 반복 표시와 실제 방문 확정을 구분하는 것이 먼저입니다.
자주 묻는 질문 2 — 매니저 앱과 관리자도 모두 처음부터 필요한가요?
방문자가 일정과 현장 정보를 어디서 확인하고 시작·완료를 어떻게 전달할지에 따라 정합니다. 담당자가 별도 앱을 써야 하는지, 웹으로 업무를 확인할지, 운영자가 대신 처리할 범위가 있는지를 첫 업무 흐름과 함께 결정하세요.
예약 시간과 변경·취소 규칙도 정해야 한다면
출시·운영 가이드 「예약 앱을 만들 때 화면보다 먼저 정해야 하는 운영 규칙 6가지」는 예약 가능 시간·승인·수용 인원과 변경·취소·알림을 설명합니다. 방문 업무를 나눈 뒤 공통 예약 규칙을 정할 때 함께 확인하세요. 예약 앱 운영 규칙 가이드 보기
고객과 담당자가 볼 정보가 다르다면
기획·MVP 가이드 「매칭 앱을 만들 때 고객·전문가·관리자 역할은 어떻게 나눌까요?」는 요청 상태와 역할별 정보·행동 범위를 설명합니다. 지원자와 확정된 방문 담당자의 권한을 나누고 운영자 확인 범위를 정할 때 참고하세요. 매칭 앱 역할 설계 가이드 보기
상담 전에는 청소 조건 한 가지, 정기 이용 방식, 방문 당일의 담당 업무를 적어오세요. 고객의 신청부터 매니저의 업무와 운영자 확인까지 첫 버전에 필요한 개발 범위를 함께 정리할 수 있습니다.


