접수와 확정 사이의 세 기록 맞추기
설명용 예약 R-01의 희망 시간은 14시입니다. 고객에게 답한 시간과 내부 표가 같아야 확정으로 닫습니다.
| 기록 | 첫 상태 | 확인 후 |
|---|---|---|
| 접수표 | 희망 14시 | 확정 15시 |
| 일정표 | 15시 가능 | 15시 반영 |
| 회신 | 15시 제안 | 고객 확인 위치 기록 |
제안한 것과 동의받은 것은 다릅니다. 회신 확인 전에는 접수표를 확정으로 바꾸지 않습니다. 시간 충돌 검사와 고객 동의는 별개의 확인이며, 개인정보 원문은 권한이 있는 원본에만 보관합니다.
필수 열과 선택 열을 구분하기
접수 채널, 희망일, 상태, 담당자, 다음 행동은 운영에 필요한 열입니다. 이름·연락처·요청 내용은 서비스 제공에 필요한 범위에서만 받습니다. 확인 기준: 개인정보보호위원회 개인정보 포털.
생년월일, 상세 주소처럼 예약 처리에 필요하지 않은 정보는 “나중에 쓸 수 있다”는 이유로 미리 수집하지 않습니다.
상태를 예약 단계에 맞추기
접수는 기록만 생긴 상태, 확인 필요는 정보나 판단이 부족한 상태, 확정은 고객과 일정이 합의된 상태로 정의합니다. 완료와 취소도 결과 이유를 남깁니다.
상태가 바뀔 때 변경일과 담당자를 기록하면 중복 예약이나 회신 누락이 생겼을 때 흐름을 되짚을 수 있습니다.
자유 메모에 개인정보를 쌓지 않기
메모에는 다음 행동에 필요한 내용만 적고 건강 정보, 가족 정보, 결제 정보처럼 목적을 벗어난 내용을 복사하지 않습니다. 확인 기준: 개인정보보호위원회 개인정보 포털.
민감한 내용이 별도 시스템에 있다면 시트에는 원문을 옮기지 않고 접근 권한이 있는 기록 위치만 남깁니다.
취소와 미응답 기준 정하기
취소 사유는 고객 요청, 일정 불일치, 정보 미확인처럼 운영 분류로 적습니다. 감정적인 평가나 불필요한 고객 특성은 기록하지 않습니다.
두 차례 확인 후 답이 없는 문의를 언제 닫을지 정합니다. 닫힌 기록은 활성 예약 화면에서 분리하고 보관 필요성을 검토합니다.
주간 개인정보 점검하기
보기 권한이 필요한 사람만 남아 있는지, 공유 링크가 외부에 열리지 않았는지, 처리 목적이 끝난 행이 남아 있지 않은지 확인합니다.
삭제 기준은 업종과 계약·법적 의무에 따라 달라질 수 있으므로 임의 기간을 법적 기준처럼 쓰지 않습니다. 실제 운영 기준은 개인정보처리방침과 관련 법령을 확인합니다.
예약 진행표는 처리 흐름에만 집중하기
예약표의 역할은 접수, 확인 필요, 확정, 완료, 취소의 다음 행동을 보여주는 것입니다. 개인정보의 법적 보유기간을 이 표에서 임의로 정하지 않고 별도 보유·파기 기록으로 연결합니다. 이렇게 나누면 예약 담당자가 필요한 연락 경로만 보고 불필요한 상세 정보를 반복 복사하지 않게 됩니다.
현황판에는 문의 ID, 희망 시각, 담당, 상태, 다음 행동을 우선 남깁니다. 연락처가 필요한 경우 권한이 제한된 원본을 확인하고, 공개 대시보드나 화면 공유에 원문 연락처가 노출되지 않는지 시험합니다.
중복 예약과 미응답을 다른 상태로 처리하기
같은 사람이 여러 채널로 문의했다는 이유만으로 자동 병합하지 않습니다. 희망일, 서비스, 기대 결과가 같은지 확인한 뒤 대표 ID와 연결 ID를 남깁니다. 불확실한 기록은 확인 필요로 두고 원본을 지우지 않습니다.
미응답은 취소와 다릅니다. 마지막 확인 시각, 다음 연락 예정, 닫을 조건을 정하고 일정을 실제로 확정했는지 별도로 표시합니다. 상태 이름마다 다음 행동을 한 문장으로 정의해야 담당자가 바뀌어도 같은 기준을 적용할 수 있습니다.
예약 완료를 일정표와 회신 기록으로 대조하기
확정 상태에는 고객과 합의한 일시, 내부 일정표 반영 시각, 담당자, 회신 위치가 함께 있어야 합니다. 접수표만 확정으로 바뀌고 일정표가 비어 있거나 반대 상태라면 완료로 닫지 않습니다. 확인 기준: Google Drive 파일 공유 도움말.
취소·변경 뒤에는 기존 시간이 실제로 해제됐는지, 새 일정이 중복되지 않는지, 고객에게 전달한 문장과 내부 기록이 같은지 확인합니다. 결과가 다른 두 시스템을 한쪽 숫자로 덮지 않고 불일치 행으로 남겨 책임자가 판정합니다.
연락처가 빠진 예약 문의를 멈추는 예시
희망일과 인원만 들어오고 회신 수단이 없는 문의를 가정합니다. 상태는 “확인 필요”로 두고, 일정표에는 자리를 확정하지 않습니다. 담당자는 접수 채널에서 연락처 제공을 요청합니다.
정보가 보완되면 담당자와 회신 기한을 기록한 뒤 확정 단계로 이동합니다. 예시의 이름과 연락처는 실제 고객 정보가 아닌 설명용 값입니다.
예약 상태 전환 기준
| 현재 상태 | 다음 상태 | 필수 확인 | 멈춤 조건 |
|---|---|---|---|
| 접수 | 확인 필요 | 접수 채널·희망일 | 회신 수단 없음 |
| 확인 필요 | 확정 | 시간·인원·조건 합의 | 중복 일정 |
| 확정 | 완료 | 서비스 제공 확인 | 변경 요청 미처리 |
| 확정 | 취소 | 취소 의사와 일시 | 환불 판단 필요 |
| 완료·취소 | 보관 종료 | 보관 근거 검토 | 분쟁·법적 보관 필요 |
표의 값은 양식과 판정 순서를 검토하기 위한 설명용 예시입니다. 실제 운영값으로 교체한 뒤 사용합니다.
수정해서 쓰는 작업표
13개 열과 설명용 예시 8행입니다. 실제 고객·거래·성과 정보를 포함하지 않으며 UTF-8 한글 표시와 열 수를 검수했습니다.
판단에 사용한 1차 자료
- 개인정보보호위원회 개인정보 포털
개인정보 처리 원칙과 사업자 안내를 확인합니다.
- Google Drive 파일 공유 도움말
시트 접근 권한의 최신 설정을 확인합니다.
적용 전에 자주 막히는 지점
고객 이름 대신 번호를 써도 되나요?
운영상 이름이 꼭 필요하지 않다면 접수번호를 중심으로 관리할 수 있습니다. 연락이 필요할 때만 제한된 원본에서 정보를 확인합니다.
취소 기록은 바로 지워야 하나요?
계약·분쟁·회계 등 보관 근거가 있는지 먼저 확인합니다. 근거 없이 영구 보관하는 것도 피합니다.
직원 모두에게 편집 권한을 줘도 되나요?
업무 역할에 따라 보기와 편집 권한을 나누고 정기적으로 접근자를 점검하는 편이 안전합니다.