고객에게 보이는 일
9월 12일 오후 2시를 선택하고 연락처와 상담 목적을 입력합니다.
서비스 기획 · 더 알아보기 · 직접 체험형
앱 사용자 흐름과 관리자 업무는 어떻게 연결해 설계할까요?
고객이 버튼을 누른 뒤 무엇이 저장되고, 관리자는 어떤 일을 하며, 결과가 고객에게 어떻게 돌아오는지 하나의 흐름으로 연결합니다.
약 10~12분쉽게 보는 핵심 기준
USER → ADMIN FLOW하나의 상태로 연결
고객 신청
시간·정보 입력
서버 접수
접수 상태 저장
관리자 처리
승인·보완 요청
고객에게 결과 안내승인 결과와 다음 행동을 같은 상태로 표시
먼저 이해할 내용
고객 화면과 관리자 화면은 같은 상태를 보고 움직여야 합니다
고객 화면과 관리자 화면을 따로 기획하면 같은 신청을 서로 다른 상태로 이해할 수 있습니다. 고객의 한 행동마다 서버에 저장할 상태, 관리자에게 생기는 업무와 고객에게 돌아갈 결과를 한 줄로 연결해야 실제 운영 가능한 흐름이 됩니다.
- 01
고객 입력
- 02
서버 접수
- 03
관리자 처리
- 04
결과 안내
- 05
완료·기록
고객 행동부터 운영 결과까지
한 단계씩 눌러 실제로 무슨 일이 생기는지 확인하세요
서비스 유형을 고른 뒤 다섯 단계를 직접 이동해보세요. 고객이 보는 화면과 서버에 남는 상태, 관리자의 다음 업무가 같은 신청 안에서 어떻게 이어지는지 보여드립니다.
고객이 하려는 일
고객이 가능한 시간을 골라 상담을 신청합니다.
업무가 끝난 기준
관리자가 시간을 승인하고 고객이 확정 내용을 확인합니다.
지금 무슨 일이 벌어졌나요? · 1단계
고객이 상담 시간과 필요한 정보를 입력합니다.
아직 신청이 접수된 것은 아닙니다. 입력값과 선택한 시간이 신청 가능한지만 먼저 확인합니다.
서버에서 처리하는 일
필수 입력과 시간 형식을 확인하고, 현재 예약 가능한 시간인지 다시 조회합니다.
관리자에게 생기는 일
아직 처리 업무를 만들지 않습니다. 미완성 입력은 신청 목록에 노출하지 않습니다.
이 단계가 끝나면
고객은 입력 오류나 이미 마감된 시간을 제출 전에 바로 확인합니다.
자동으로 넘어가지 않습니다 · 원하는 단계를 직접 확인하세요
정상 흐름 밖의 상황
실패했을 때 다시 이어지는 방법까지 기획합니다
오류 문구만 정하는 것이 아니라 고객이 무엇을 보고, 서버가 어떤 상태를 유지하며, 관리자가 어떻게 복구할지 함께 정해야 합니다.
선택한 예외 상황
선택한 시간을 다른 고객이 먼저 예약함
입력할 때 가능했던 시간도 제출하는 순간에는 마감될 수 있습니다.
- 고객 안내
- “방금 마감된 시간이에요”라는 설명과 다시 고를 수 있는 시간을 보여줍니다.
- 서버 상태
- 최종 저장 직전에 가능 여부를 다시 확인하고, 이미 사용된 시간은 접수하지 않습니다.
- 관리자 후속 업무
- 실패한 신청을 승인 대기 업무로 만들지 않아 이중 예약을 막습니다.
다시 이어지는 방법
고객이 입력한 나머지 정보는 유지한 채 시간만 다시 선택하게 합니다.
실제 기획 결과물
화면 설명을 개발과 운영이 확인할 수 있는 기준으로 바꿉니다
같은 흐름을 사용자 화면, 상태, 관리자 업무와 검수 문장으로 나눠 남기면 개발 중 해석 차이와 출시 후 운영 혼선을 줄일 수 있습니다.
01
사용자 흐름도
고객이 시작해서 목적을 완료할 때까지 필요한 화면과 행동을 순서대로 정리합니다.
02
상태 전환표
접수·처리·완료·실패 상태와 각 상태로 바뀔 수 있는 조건을 정합니다.
03
관리자 업무표
상태마다 운영자가 확인할 정보, 가능한 행동과 처리 기한을 구분합니다.
04
기능 검수 조건
정상 상황과 중복·실패·권한 없음 상황에서 보여야 할 결과를 문장으로 남깁니다.
고객과 함께 정하는 운영 기준
- 누가 어떤 상황에서 요청하는가
- 접수와 확정을 같은 상태로 볼 것인가
- 관리자가 언제 승인·보완·거절할 수 있는가
- 취소·마감·알림 실패 때 고객에게 무엇을 안내할 것인가
데브크래프트가 구현 기준으로 바꾸는 내용
- 입력 확인과 중복 요청 방지 규칙
- 고객·서버·관리자가 공유할 상태 이름과 전환 조건
- 관리자 목록·처리 버튼·변경 기록의 연결 방식
- 알림 실패와 보완 요청 이후 다시 이어지는 복구 흐름
확인할 내용
이 내용을 보면 알 수 있습니다
- 고객 행동 뒤에 이어지는 서버 상태와 관리자 업무를 한 흐름으로 연결하기
- 접수·처리·안내·완료 상태를 고객과 운영자가 같은 뜻으로 사용하기
- 중복 요청·마감·보완 요청·알림 실패 상황의 복구 방법까지 정하기
판단 기준
실제 구현에서는 이렇게 확인합니다
- 01고객이 행동한 직후 현재 상태와 다음 행동을 이해할 수 있는가
- 02관리자가 처리해야 할 업무와 처리 기한이 상태별로 구분되어 있는가
- 03실패나 중복이 발생해도 같은 요청을 확인하고 안전하게 이어갈 수 있는가
우리 서비스의 고객·관리자 흐름을 함께 정리해보세요
만들려는 서비스와 현재 운영 방식을 알려주세요. 고객 행동 뒤에 필요한 서버 상태와 관리자 업무, 예외 상황을 30분 상담에서 함께 정리합니다.