한정 수량만으로 입고 뒤 예약 주문을 왜 맞추기 어려울까요?
상품이 창고에 들어오기 전부터 주문을 받아야 하는 경우가 있습니다. 신상품 출시 일정을 먼저 알렸거나, 생산 중인 상품의 수요를 미리 확인해야 할 때입니다. 판매 기간과 한정 수량을 정하고 품절 표시와 안내 문구를 넣으면 사전예약 자체는 운영할 수 있습니다. 입고 수량이 예약 수량보다 넉넉하고 선택 항목도 단순하다면 이 방식만으로도 충분합니다.
문제는 실제 입고가 예상과 다를 때 시작됩니다. 전체 수량은 맞아도 색이나 사이즈별 수량이 달라질 수 있습니다. 검정 중형은 부족하고 흰색 대형은 남는 식입니다. 이때 전체 예약 건을 한꺼번에 출고 가능으로 바꾸면, 재고가 없는 선택 항목까지 출고 대상으로 넘어갑니다. 반대로 주문을 한 건씩 확인하면 같은 엑셀 대조를 반복해야 합니다. 거의 동시에 여러 주문이 들어오면 예약 한도를 넘겨 결제가 끝나는 상황도 생길 수 있습니다.
- 예약 한도는 전체 상품 수량이 아니라 색·사이즈 같은 선택 항목별로 확인해야 했습니다.
- 실제 입고 수량이 확정되기 전에는 어떤 주문까지 출고할 수 있는지 판단하기 어려웠습니다.
- 한 주문에 여러 선택 항목이 담기면 일부만 출고하고 나머지는 기다리거나 취소해야 했습니다.
- 여러 고객이 거의 동시에 주문하면 화면에 남은 수량과 실제 접수 수량이 어긋날 수 있었습니다.
예약 한도와 실제 입고는 어떻게 따로 관리했을까요?
먼저 예약 주문과 바로 출고할 수 있는 일반 재고 주문을 구분했습니다. 상품이 같더라도 사전예약으로 받은 수량과 창고에 있는 수량은 의미가 다르기 때문입니다. 예약을 받는 동안에는 선택 항목별 예약 한도를 기준으로 접수하고, 실제 재고가 있는 것처럼 출고 단계로 넘기지 않았습니다.
입고가 확정되면 입고 수량을 예약 주문에 나누어 주는 일을 별도로 진행했습니다. 기준은 운영자가 미리 정했습니다. 먼저 주문한 고객부터 처리할지, 한 주문을 모두 준비할 수 있을 때만 출고할지, 준비된 상품만 먼저 보낼지를 정한 뒤 화면의 처리 순서에 반영했습니다. 그래야 담당자가 바뀌어도 같은 기준으로 판단할 수 있습니다.
예약 한도를 확인하는 과정도 주문 완료 뒤에만 두지 않았습니다. 고객이 주문을 진행하는 사이 다른 주문이 먼저 들어올 수 있으므로, 최종 접수 시점에 해당 선택 항목의 남은 예약 자리를 다시 확인했습니다. 한도를 넘긴 주문을 그대로 쌓기보다 결제 상태와 취소 가능 범위를 확인해 예외 처리 대상으로 분리했습니다.
실제 입고 수량은 예약 주문에 어떤 순서로 나눴을까요?
입고 확인 화면에는 선택 항목별 예약 수량, 실제 입고 수량, 이미 출고 대상으로 정한 수량, 남은 수량을 함께 보이도록 구성했습니다. 운영자가 입고 수량을 확정하면 정해 둔 순서에 따라 예약 건부터 확인했습니다. 수량이 충분한 주문은 출고 가능 상태로 넘기고, 부족한 주문은 대기 대상으로 남겼습니다. 선택 항목이 여러 개인 주문은 전부 준비된 경우와 일부만 준비된 경우를 구분해 보이도록 했습니다.
부족한 선택 항목만 취소하거나 기다리게 할 수 있었을까요?
부족분을 처리하는 방식은 결제 수단과 쇼핑몰의 부분 취소 정책에 따라 달라집니다. 일부 상품만 취소할 수 있는 주문은 부족한 항목을 골라 취소 대상으로 표시했습니다. 부분 취소가 어렵거나 묶음 조건이 있는 주문은 임의로 나누지 않고 담당자가 확인하도록 남겼습니다. 입고 예정일이 바뀐 경우에는 대기 유지, 전체 취소, 준비된 상품 우선 출고 가운데 고객에게 안내한 기준을 적용했습니다.
- 사전예약 주문과 일반 재고 판매를 나누어 출고 가능한 수량이 섞이지 않게 했습니다.
- 선택 항목별 예약 한도를 두고 최종 주문 접수 때 남은 자리를 다시 확인했습니다.
- 입고 확정 뒤에는 먼저 주문한 순서 등 미리 정한 기준으로 예약 건에 수량을 나누었습니다.
- 부족한 건은 대기·부분 취소·전체 확인 대상으로 구분하고 준비된 건만 출고 가능 상태로 넘겼습니다.
입고 수량이 달라져도 운영 판단이 쉬워졌을까요?
담당자는 전체 주문 목록과 입고 엑셀을 번갈아 보며 한 건씩 표시하는 대신, 어떤 선택 항목이 부족하고 어느 주문까지 준비됐는지 한 화면에서 확인할 수 있게 됐습니다. 남은 입고 수량도 예약 건에 반영한 뒤의 값으로 보여, 예약 고객에게 먼저 줄 수량과 이후 일반 판매로 돌릴 수량을 구분하기 쉬워졌습니다.
다만 모든 쇼핑몰에 별도 화면이 필요한 것은 아닙니다. 한 품목만 소량으로 받고 입고 수량이 늘 충분하다면 기본 기능과 엑셀로 처리하는 쪽이 간단합니다. 입고 지연 자체를 개발로 막을 수도 없습니다. 결제 수단마다 부분 취소 조건이 다르고, 입력 실수나 외부 처리 지연도 있어 무오차를 약속할 수는 없습니다. 테스트몰에서 입고 수량을 늘리거나 줄이고, 특정 선택 항목만 부족하게 만든 뒤 주문 상태와 취소 흐름을 검수해야 합니다.
- 선택 항목별 부족 수량과 출고 가능한 예약 주문을 찾는 시간이 줄었습니다.
- 소량 예약은 기본 기능과 엑셀로 운영하고, 반복 대조가 커질 때 별도 화면을 검토할 수 있습니다.
- 입고 지연과 결제 정책은 별도 운영 기준이 필요하며 실제와 비슷한 부족 상황으로 테스트해야 합니다.
옴니어스24는 왜 화면보다 운영 규칙을 먼저 물을까요?
옴니어스24는 사전예약 화면부터 만들기보다 입고와 예약을 맞추는 규칙을 먼저 정리합니다. 예약 한도를 전체 상품에 둘지 선택 항목마다 둘지, 먼저 주문한 고객부터 처리할지, 일부만 준비된 주문을 나눠 보낼지에 따라 필요한 기능이 달라집니다. 취소 권한과 결제 처리 범위도 함께 확인해야 실제 운영에서 멈추는 구간을 줄일 수 있습니다.
상담 전에는 사전예약 상품 예시, 색·사이즈 같은 선택 항목 목록, 예상 입고 자료, 실제 사용하는 주문 상태, 부족 시 고객 안내 기준을 준비하면 좋습니다. 부분 출고와 부분 취소를 사용한다면 현재 적용 중인 결제 정책도 필요합니다. 이 자료를 바탕으로 기본 기능과 엑셀로 충분한 구간, 반복 작업을 줄이기 위해 별도 화면이 필요한 구간을 나눌 수 있습니다.
사전예약·재고 맞춤 사례 다음에 보면 좋은 글·페이지
캠페인 참여 인원에 따라 진행 여부를 정하는 체험단·공동구매형 주문 사례는 입고 수량을 예약 고객에게 나누는 이번 사례와 목적이 다릅니다. 실제 보유 수량의 흐름을 넓게 살펴보려면 오프라인 매장과 재고를 거의 실시간으로 맞추는 글, 상품이 많은 운영이라면 API로 대량 상품·재고 일괄 수정과 옵션 조합이 많을 때 등록·운영 사례를 이어서 볼 수 있습니다.
고객에게 남은 수량을 보여 주는 방식이 궁금하다면 품절 임박 수량 상세 노출을, 출고 이후 흐름이 궁금하다면 물류대행·송장 연동 사례를 참고할 수 있습니다. 예약 주문을 별도 기준으로 처리해야 하는 이유를 기술 구성까지 넓혀 보려면 API·별도 서버가 필요한 이유도 함께 살펴보세요.