예약·매칭 플랫폼은 양쪽 화면을 따로 그립니다

반려동물 돌봄 예약 앱을 준비하던 스타트업 대표님이 계셨습니다. 기획 회의 자료에는 고객이 쓰는 화면이 스무 장 넘게 정리되어 있었습니다. 검색, 상세, 예약, 결제, 후기까지 꼼꼼했습니다.

그런데 돌봄 선생님이 쓰는 화면은 「선생님 앱도 비슷하게」라는 한 줄이 전부였습니다. 예약 요청은 선생님이 어디서 받는지, 거절하면 고객에게 무엇이 보이는지, 일정은 누가 막아 두는지 아무도 정하지 않은 상태였습니다.

이런 플랫폼은 겉으로는 앱 하나지만, 실제로는 서로 다른 두 서비스가 한 데이터를 나눠 쓰는 구조입니다.

핵심은 고객 화면과 공급자 화면을 처음부터 따로 그리는 것입니다. 두 쪽은 하는 일과 보는 정보가 다르기 때문에 메뉴 구조도 따로 잡아야 합니다. 그다음 두 화면이 만나는 순간을 한 표로 맞춰 두면 빠지는 기능이 거의 없어집니다.

양쪽은 같은 예약을 다르게 봅니다

고객에게 예약은 「내가 신청한 일정」입니다. 공급자에게 예약은 「처리해야 할 요청」입니다. 같은 예약 한 건인데, 화면에서 보여 줄 내용과 누를 버튼이 다릅니다.

고객은 언제 확정되는지가 궁금합니다. 공급자는 이 요청을 받을지, 다른 일정과 겹치지 않는지가 궁금합니다. 그래서 고객 화면은 찾기와 신청이 중심이고, 공급자 화면은 받은 요청함과 일정 관리가 중심이 됩니다. 메뉴 구조를 하나로 합쳐 그리면 이 차이가 지워집니다.

공급자 쪽에서 빠지기 쉬운 화면

고객 화면은 대표님이 직접 써 보는 상상을 하기 쉬워서 잘 정리됩니다. 빠지는 쪽은 거의 항상 공급자 화면입니다. 아래 목록으로 한 번 점검해 보시기를 권합니다.

• 가입과 심사. 공급자는 바로 활동하지 않고 확인을 거치는 경우가 많습니다. 서류 제출, 심사 대기, 반려 화면이 필요합니다.
• 일정과 가능 시간 설정. 쉬는 날, 이미 잡힌 일정, 하루 최대 건수를 정하는 화면입니다.
• 요청 수락과 거절. 거절 사유를 고르게 할지, 일정 시간 안에 답하지 않으면 어떻게 할지 정해야 합니다.
• 정산 내역. 언제 얼마가 들어오는지 보는 화면입니다. 공급자가 가장 자주 묻는 부분입니다.
• 프로필과 소개 관리. 고객이 보는 상세 화면의 내용을 공급자가 직접 고치는 곳입니다.

두 화면이 만나는 순간을 표로 맞춥니다

따로 그린 두 화면은 예약 상태가 바뀌는 순간에 서로 연결됩니다. 이 연결을 표 하나로 정리해 두면 개발사도 흐름을 바로 이해합니다.

표를 채우다 보면 비어 있는 칸이 보입니다. 예를 들어 고객이 확정 뒤에 취소하면 공급자 화면에는 무엇이 남는지 같은 질문입니다. 이런 빈칸이 개발 중에 터지는 문제의 대부분입니다.

관리자 화면은 세 번째 서비스입니다

양쪽을 나누고 나면 운영하는 사람의 화면도 따로 있어야 한다는 것이 보입니다. 공급자 심사, 분쟁 처리, 정산 확인은 고객도 공급자도 아닌 운영자가 합니다. 이 화면들까지 적어 두어야 견적과 일정이 현실에 맞게 나옵니다.

예약·매칭 플랫폼은 화면 수보다 화면 사이의 관계가 어렵습니다. 고객, 공급자, 관리자의 메뉴 구조를 따로 세우고 상태별로 맞춰 둔 화면설계와 기획서가 있으면, 개발은 다른 곳에 맡기셔도 직접 하셔도 같은 그림을 보고 시작할 수 있습니다.

자주 묻는 질문

예약 앱을 만들 때 공급자용 앱을 따로 만들어야 하나요?

꼭 앱을 두 개로 나눌 필요는 없습니다. 한 앱 안에서 역할에 따라 다른 메뉴를 보여 줄 수도 있습니다. 다만 어느 방식이든 화면설계는 양쪽을 따로 그려야 빠지는 기능이 없습니다.

공급자 화면을 처음에는 웹으로만 만들어도 되나요?

공급자 수가 적고 하는 일이 단순하다면 웹으로 먼저 시작하는 경우도 많습니다. 요청 알림을 얼마나 빨리 받아야 하는지가 기준입니다. 바로 답해야 하는 서비스라면 알림 방식까지 함께 정해야 합니다.

매칭 플랫폼 기획서에는 무엇이 꼭 들어가야 하나요?

고객, 공급자, 관리자 각각의 메뉴 구조와 화면 목록이 들어가야 합니다. 그리고 예약이나 매칭 상태가 바뀔 때 세 화면이 각각 어떻게 변하는지 적은 표가 있어야 합니다. 이 표가 있으면 개발사와의 대화가 훨씬 짧아집니다.