수업이나 서비스의 예약을 받는 앱을 개발할 때는 고객이 신청하는 화면부터 정하기 쉽습니다. 신청 내역을 보여주고 운영자가 명단을 확인하면 첫 버전은 충분해 보입니다. 변경과 취소는 고객이 직접 연락하면 처리하고, 앱 기능은 나중에 만들기로 할 수도 있습니다.

이 방식으로 시작할 수는 있습니다. 다만 고객이 연락한 뒤 누가 어떤 기록을 바꾸고, 처리 결과를 어디서 확인하는지까지 정해야 합니다. 자동으로 처리하는 범위와, 첫날부터 운영할 수 있어야 하는 범위를 함께 나누는 일입니다.

첫 버전에서 어디까지 직접 처리할지 고르세요

예를 들어 체험 수업의 신청을 받는 앱을 준비한다고 해보겠습니다. 첫 버전에서는 고객이 수업을 신청하고, 운영자가 신청 명단을 확인합니다. 수업을 바꾸거나 취소하고 싶을 때는 고객이 안내된 연락 방법으로 요청하기로 정했습니다.

고객이 앱에서 다른 날짜를 골라 즉시 변경하는 화면은 뒤로 미룰 수 있습니다. 빈자리가 나면 대기자에게 순서대로 안내하는 기능도 이번 범위에서 뺄 수 있습니다.

대신 연락을 받은 운영자가 신청 내역을 찾아 변경·취소를 반영하고, 고객이 최종 결과를 확인하는 방법은 있어야 합니다. 고객용 자동 처리 화면을 만들지 않더라도 운영자에게 필요한 처리 기능과 기록은 개발 범위에 남습니다.

수업 한 건을 바꾸고 취소하는 과정을 적어보세요

토요일 오전 수업을 신청한 고객이 일요일 오후 수업으로 바꾸고 싶다고 연락했습니다. 운영자는 기존 신청과 옮겨갈 수업의 남은 자리를 함께 확인합니다.

이번 예시에서는 운영자가 변경을 확정하기 전까지 기존 신청을 유지하기로 정합니다. 자리가 있으면 새 수업으로 옮기고, 기존 수업과 새 수업의 명단·남은 자리를 함께 반영합니다. 자리가 없으면 기존 신청을 유지한 채 변경할 수 없다는 결과와 다음 선택 방법을 안내합니다. 연락을 받았다는 답만 하고 고객이 어느 수업에 신청돼 있는지 알 수 없게 두지 않습니다.

취소를 요청했다면 처리 결과가 달라집니다. 운영자가 취소를 확정한 신청은 취소 상태로 남기고, 해당 고객을 참석 예정 명단에서 제외합니다. 취소로 생긴 자리를 다시 신청받을지도 정해야 합니다. 이 예시에서는 새 신청을 받을 수 있도록 남은 자리에 반영합니다.

변경·취소 요청을 받는 일이 곧 신청 내역을 지우는 일은 아닙니다. 어떤 수업에서 어떤 처리가 있었는지 남겨야 고객의 연락과 명단이 달라졌을 때 확인할 수 있습니다.

조건·담당·기록·안내를 한 묶음으로 정합니다

개발 요청서에는 ‘변경·취소 기능’이라는 이름과 함께 다음 네 가지를 적어보세요.

1. 조건: 고객이 언제까지 요청할 수 있는지, 수업이 시작된 뒤의 요청은 어떻게 확인할지, 다른 수업에 자리가 없으면 무엇을 유지할지 정합니다. 실제 서비스의 운영 기준을 먼저 맞춘 뒤 앱에 반영합니다.
2. 담당: 연락을 받는 사람과 신청 내역을 변경하는 사람을 정합니다. 담당자가 여러 명이라면 이미 처리한 건인지 확인할 수 있어야 합니다. 같은 요청을 두 번 처리해 남은 자리가 잘못 늘어나지 않는지도 확인합니다.
3. 기록: 원래 수업, 변경할 수업 또는 취소 요청, 처리 결과와 처리한 사람·시각을 남깁니다. 변경 전 내용을 덮어써 나중에 찾을 수 없게 만들지 않습니다.
4. 안내: 요청을 받았을 때와 실제 처리가 끝났을 때 무엇을 알려줄지 정합니다. 고객이 확정된 수업이나 취소 결과를 확인할 곳도 정합니다. 문자나 전화를 사용한다면 안내를 맡을 사람과 누락을 확인하는 방법을 함께 적습니다.

첫 버전에서 모든 알림을 자동으로 보낼 필요는 없습니다. 운영자가 직접 안내하는 방식을 고르면, 그 업무를 실제로 맡을 사람과 확인 방법을 개발 범위·운영 계획에 함께 남기면 됩니다.

고객과 운영자가 같은 결과를 보는지 확인하세요

검수할 때는 신청 버튼이 눌리는 장면에서 한 걸음 더 이어가 보세요. 앞의 수업 신청 한 건으로 다음 결과를 확인할 수 있습니다.

• 변경 확정 후: 고객의 신청 내역은 새 수업을 보여주고, 운영자의 두 수업 명단과 남은 자리도 같은 결과를 반영합니다.
• 변경할 자리가 없을 때: 기존 신청이 유지되고, 고객은 변경되지 않은 이유와 다음 행동을 안내받습니다.
• 취소 확정 후: 고객에게 취소 결과가 보이고, 참석 예정 명단과 다시 신청받을 수 있는 자리가 정한 규칙대로 바뀝니다.
• 처리한 요청을 다시 열었을 때: 최종 결과와 처리 기록을 찾을 수 있고, 같은 요청을 다시 처리해 명단이나 정원이 중복 변경되지 않습니다.

고객용 앱과 운영자 화면에 각각 메뉴가 있다는 것만으로 이 흐름이 연결되지는 않습니다. 담당자가 실제로 연락을 받고 한 건을 마무리하는 순서로 확인해야 빠진 기능과 운영 업무를 찾을 수 있습니다.

개발업체에는 처리 방법과 남길 결과를 함께 전달하세요

앞의 예시를 개발 요청서로 옮기면 이렇게 적을 수 있습니다.

첫 버전에서는 수업 변경·취소 요청을 안내된 연락 방법으로 받습니다. 운영자는 기존 신청을 찾아 정해진 조건과 남은 자리를 확인하고 처리합니다. 변경을 확정하면 두 수업의 명단·남은 자리를 함께 반영하고, 취소를 확정하면 취소 기록과 다시 신청받을 자리를 반영합니다. 처리 전후와 담당자·시각을 남기며, 고객은 앱에서 최종 신청 결과를 확인합니다. 결과 안내는 운영자가 직접 맡습니다.

이렇게 적으면 고객용 변경 화면을 나중에 만들더라도 이번에 필요한 관리자 기능, 저장할 정보와 운영 업무를 함께 논의할 수 있습니다. 결제가 있는 서비스라면 취소와 별도로 환불의 처리 단계·담당·확인할 결과도 개발 범위에 추가해야 합니다. 위 수업 예시만으로 그 범위까지 정해졌다고 보지 않습니다.

첫 버전의 범위를 줄일 때는 기능 이름을 지운 다음, 그 일이 생기면 실제로 어떻게 끝낼지 다시 적어보세요. 변경·취소의 자동화는 단계적으로 넓히되, 고객 한 건을 마무리할 기준은 첫 버전부터 정하는 것이 좋습니다.

예약 시간·정원·승인 방식까지 함께 정리하고 싶다면 데브크래프트의 예약 앱 운영 규칙 가이드를 참고할 수 있습니다.