예약·문의 기록 시트 만드는 법

제작·검수 근거: 최소 수집 열, 상태 전환표, 보관 종료 점검과 가상 데이터 8건을 직접 구성하고 연락처가 예시값인지 검수했습니다.

최종 검수: 2026.07.27 · SOPBiz 운영자

먼저 확인할 핵심

희망일과 인원만 들어오고 회신 수단이 없는 문의를 가정합니다. 상태는 “확인 필요”로 두고, 일정표에는 자리를 확정하지 않습니다. 담당자는 접수 채널에서 연락처 제공을 요청합니다.

정보가 보완되면 담당자와 회신 기한을 기록한 뒤 확정 단계로 이동합니다. 예시의 이름과 연락처는 실제 고객 정보가 아닌 설명용 값입니다.

접수 채널, 희망일, 상태, 담당자, 다음 행동은 운영에 필요한 열입니다. 이름·연락처·요청 내용은 서비스 제공에 필요한 범위에서만 받습니다.

생년월일, 상세 주소처럼 예약 처리에 필요하지 않은 정보는 “나중에 쓸 수 있다”는 이유로 미리 수집하지 않습니다.

접수는 기록만 생긴 상태, 확인 필요는 정보나 판단이 부족한 상태, 확정은 고객과 일정이 합의된 상태로 정의합니다. 완료와 취소도 결과 이유를 남깁니다.

상태가 바뀔 때 변경일과 담당자를 기록하면 중복 예약이나 회신 누락이 생겼을 때 흐름을 되짚을 수 있습니다.

메모에는 다음 행동에 필요한 내용만 적고 건강 정보, 가족 정보, 결제 정보처럼 목적을 벗어난 내용을 복사하지 않습니다.

민감한 내용이 별도 시스템에 있다면 시트에는 원문을 옮기지 않고 접근 권한이 있는 기록 위치만 남깁니다.

취소 사유는 고객 요청, 일정 불일치, 정보 미확인처럼 운영 분류로 적습니다. 감정적인 평가나 불필요한 고객 특성은 기록하지 않습니다.

두 차례 확인 후 답이 없는 문의를 언제 닫을지 정합니다. 닫힌 기록은 활성 예약 화면에서 분리하고 보관 필요성을 검토합니다.

보기 권한이 필요한 사람만 남아 있는지, 공유 링크가 외부에 열리지 않았는지, 처리 목적이 끝난 행이 남아 있지 않은지 확인합니다.

삭제 기준은 업종과 계약·법적 의무에 따라 달라질 수 있으므로 임의 기간을 법적 기준처럼 쓰지 않습니다. 실제 운영 기준은 개인정보처리방침과 관련 법령을 확인합니다.

예약 상태 전환 기준
현재 상태	다음 상태	필수 확인	멈춤 조건
접수	확인 필요	접수 채널·희망일	회신 수단 없음
확인 필요	확정	시간·인원·조건 합의	중복 일정
확정	완료	서비스 제공 확인	변경 요청 미처리
확정	취소	취소 의사와 일시	환불 판단 필요
완료·취소	보관 종료	보관 근거 검토	분쟁·법적 보관 필요

표의 숫자는 계산과 판정 방식을 보여주기 위한 설명용 예시입니다. 실제 기준은 사용량·공간·계약 조건에 맞게 다시 정합니다.

13개 열, 예시 8행을 넣었고 UTF-8 한글 인코딩과 파일 열림을 2026.07.27에 확인했습니다. 예시 값은 실제 사업 데이터가 아닙니다.

고객 이름 대신 번호를 써도 되나요?

운영상 이름이 꼭 필요하지 않다면 접수번호를 중심으로 관리할 수 있습니다. 연락이 필요할 때만 제한된 원본에서 정보를 확인합니다.

취소 기록은 바로 지워야 하나요?

계약·분쟁·회계 등 보관 근거가 있는지 먼저 확인합니다. 근거 없이 영구 보관하는 것도 피합니다.

직원 모두에게 편집 권한을 줘도 되나요?

업무 역할에 따라 보기와 편집 권한을 나누고 정기적으로 접근자를 점검하는 편이 안전합니다.

연결 자료는 2026.07.27에 주소와 운영 주체를 확인했습니다. 최신 메뉴·법령·안전 기준은 해당 운영 기관의 현재 원문이 우선합니다.