주문은 접수됐는데 출고가 안 됐다면, 누구의 책임일까?
주문은 접수됐는데 출고가 안 된 일은 한 사람의 실수보다, 확인·출고·알림의 담당이 비어 있을 때 납니다. 상태와 인수인계를 나누는 방법을 정리했습니다.
Qnector

AI 요약
- 접수와 확정, 출고 준비는 같은 상태가 아닙니다. 다음 단계로 넘기는 사람과 확인 시점을 정해 두세요.
- 알림을 보낸 것과 업무가 끝난 것은 다릅니다. 누구에게, 무엇을, 확인 후 무엇을 할지를 같이 정합니다.
- 재고가 주문 수량보다 적을 때는 자동 결정이 아니라, 누가 협의하고 합의 내용을 남길지입니다.
“어제 주문했는데 아직 출고가 안 됐다고요?” 전화 한 통에 영업이 내역을 엽니다. 주문은 접수돼 있습니다. 물류에 물으면 출고 준비도 시작되지 않았습니다. 영업은 접수됐으니 물류가 하고 있을 거라 생각했고, 물류는 확정 안내를 받지 못했고, 거래처는 주문을 냈으니 출고 중일 거라 기대했습니다. 세 곳 모두 자기 일은 했다고 느낍니다.
먼저 볼 것은 누구의 실수인가가 아닙니다. 접수 이후 누가 확인하고, 언제 출고하며, 문제가 나면 누구에게 알릴지가 있었는가입니다. B2B 주문관리는 빨리 받는 일만이 아닙니다. 출고·배송까지 상태와 담당이 이어져야 합니다.

1. 접수는 됐는데, 왜 출고가 안 됐나
유통 한 곳을 가정합니다. 영업은 주문을 받고, 물류는 재고를 본 뒤 출고합니다. 월요일 오후 거래처 A가 100개를 주문했고 시스템에는 등록됐습니다. 영업은 접수만 확인하고 다른 일로 넘어갔습니다. 물류는 출고 가능 여부를 보지 못했습니다. 다음 날 오전, 배송 일정 문의에서 드러납니다. 주문은 있고 출고는 없습니다.
원인은 한 가지가 아닙니다.
- 접수는 됐는데 담당자가 확인하지 않음
- 재고가 부족해 보류
- 거래 조건·결제 조건을 더 봐야 함
- 출고 담당자에게 일이 넘어가지 않음
- 수정됐는데 변경이 공유되지 않음
- 출고는 했는데 화면 상태가 안 바뀜
출고 지연은 주문 누락과 다를 수 있습니다. 어느 단계에서 멈췄는지부터 보세요.
2. 접수와 확정은 같은 말이 아닙니다
구매자가 주문서를 냈다고 판매자가 승인했거나 바로 출고할 수 있다는 뜻은 아닙니다. 재고, 거래 조건, 결제, 납기를 봐야 하는 주문이 있습니다. 100개를 주문했는데 출고 가능 재고가 70개라면, 부분 출고를 협의하거나 납기를 다시 잡아야 합니다. 접수와 출고 확정을 한 상태로 두면 기대가 갈립니다.
운영 기준으로는 이렇게 나누는 편이 명확합니다. 상태를 많이 만드는 것이 목적이 아닙니다. 각 상태가 무엇이고, 다음으로 넘기려면 누가 무엇을 하는지를 정하는 일입니다.
| 상태 | 의미 | 주요 담당 |
|---|---|---|
| 주문 접수 | 구매자 요청이 등록됨 | 영업·주문관리 |
| 확인 대기 | 품목·수량·단가·조건 확인 필요 | 영업·주문관리 |
| 주문 확정 | 처리 가능한 주문으로 확정 | 영업·주문관리 |
| 출고 준비 | 창고에서 출고 작업 준비 | 물류·창고 |
| 출고 완료 | 출고 처리가 끝남 | 물류·창고 |
| 배송 중 | 운송사 인계 후 이동 | 물류·배송 |
| 배송 완료 | 도착이 확인됨 | 물류·배송 |
이 표는 내부 업무 모델입니다. 큐넥터 화면의 상태명(대기·처리중·배송중·완료·취소 등)이나 자동 전환 단계와 1:1로 같지 않습니다. 화면에서 보는 진행과 송장은 주문 관리에서 확인할 수 있습니다.
3. 지연됐을 때, 누가 먼저 보나
여기서 책임은 법적 책임을 단정하는 말이 아닙니다. 그 단계에서 확인하고 처리할 운영상 담당입니다.
| 상황 | 1차 확인 | 필요한 조치 |
|---|---|---|
| 신규 주문 미확인 | 영업·주문관리 | 확인 후 처리 여부 결정 |
| 단가 불일치 | 영업·주문관리 | 단가 확인, 거래처 협의 |
| 재고 부족 | 물류·재고 | 가능 수량·납기 확인 |
| 출고 준비 지연 | 물류·창고 | 작업 순서·일정 확인 |
| 변경 미반영 | 변경을 받은 담당 | 내용 확인 후 관련 부서 공유 |
| 배송 지연 | 물류·배송 | 운송 상태 확인, 거래처 안내 |
한 사람이 여러 역할을 맡아도 됩니다. 부서 수가 아니라, 멈췄을 때 누가 보는가입니다. 영업이 확정하면 물류는 어디서 그 주문을 보는지, 재고가 부족하면 영업과 거래처에는 누가 말하는지를 정해 두지 않으면 시스템이 있어도 확인 전화는 남습니다.
4. 알림을 보낸 것과 처리한 것은 다릅니다
신규 주문을 담당 채널로 보내면, 화면을 새로고침하며 기다리는 시간은 줄어듭니다. 알림이 도착했다고 일이 끝난 것은 아닙니다. 물류에 출고 요청이 갔어도 다른 일에 묻히면 주문은 대기입니다.
- 무엇을 알리나 — 모든 상태 변화가 아니라, 신규·변경·출고 지연·취소처럼 조치가 필요한 사건.
- 누구에게 알리나 — 신규는 영업, 출고 준비는 물류, 거래 조건은 해당 관리자. 전원에게 같은 알림을 보내면 중요한 건이 묻힙니다.
- 알림 다음 행동 — 볼 주문, 할 일, 언제까지인지를 같이 적습니다.
카카오톡·Slack·이메일로 넘기는 구조는 데이터 연결 글과 맞닿아 있습니다.
5. 지연을 보려면 처리 기한이 있어야 합니다
상태만 있고 기한이 없으면 지연인지 판단하기 어렵습니다. 접수 후 30분 안에 확인할 회사와, 당일 마감까지면 되는 회사는 기준이 다릅니다. 내부 목표로 이렇게 잡을 수 있습니다.
| 업무 | 목표 시간 예시 | 넘기면 |
|---|---|---|
| 신규 주문 확인 | 접수 후 30분 | 주문 담당 확인 요청 |
| 재고·거래 조건 | 접수 후 1시간 | 영업·재고 협의 |
| 출고 준비 착수 | 확정 후 2시간 | 물류 확인 |
| 출고 완료 | 약정 출고일 | 사유와 예상 일정 안내 |
| 배송 정보 등록 | 운송사 인계 후 | 송장·배송 상태 확인 |
이 시간은 예시입니다. 큐넥터의 기본 설정이나 보장 시간이 아닙니다. 업종, 주문 마감, 창고 운영, 거래처와 정한 납기에 맞게 바꾸세요. ‘출고 대기’인지만 보지 말고, 얼마나 오래 대기인지, 목표를 넘겼는지를 같이 봅니다.
6. 100개 중 70개만 나갈 수 있을 때
주문 수량과 출고 가능 수량이 다를 수 있습니다. 100개를 주문했는데 창고에 70개뿐이라면, 상태를 ‘접수 완료’만 두면 거래처는 100개가 나갈 거라 생각합니다. 무조건 취소하면, 70개라도 먼저 받고 싶은 거래처와는 어긋납니다.
- 물류가 실제 출고 가능 수량을 확인합니다.
- 영업에 “100개 중 70개”를 전달합니다.
- 거래처와 정합니다. 70개를 먼저 보내고 30개는 나중에 할지, 수량을 모은 뒤 한 번에 보낼지.
- 합의한 수량, 예정일, 담당을 남깁니다.
- 출고 결과와 남은 수량을 이어서 봅니다.
프로그램이 이 결정을 대신하지 않습니다. 누가 부족을 보고, 누구와 협의하고, 무엇을 기준으로 처리할지를 정하는 일입니다. 부분 출고·잔여 수량 기능은 ERP와 주문 시스템의 지원 범위에 맞춰 따로 설계해야 합니다. 재고를 주문 화면에 맞추는 순서는 이카운트 연동 가이드를 참고하세요.

7. 시스템을 볼 때 같이 확인할 것
접수 기능만 비교하면 출고 지연은 안 줄어듭니다.
- 접수부터 출고·배송까지 진행을 볼 수 있는가
- 확인이 필요한 주문, 처리 중, 예외를 구분할 수 있는가
- 수량·품목·배송지 변경의 최신 내용이 남는가
- 필요한 사건을 담당 채널로 보낼 수 있는가
- 접수한 주문이 ERP 판매·재고·출고와 어떻게 이어지는가
데이터를 보내는 것과, 출고 결과까지 같은 기준으로 보는 것은 다릅니다.
8. 큐넥터에서 이어지는 범위
큐넥터는 거래처가 웹·모바일로 주문하고, 판매자가 접수 주문과 진행을 보는 B2B 주문 플랫폼입니다. 알림과 외부 연동으로 담당자에게 넘길 수 있습니다.
- 접수 — 거래처 주문을 판매자가 확인합니다.
- 알림 — 지원 범위에서 신규·상태 변화를 Slack, 카카오톡, 이메일 등으로 보냅니다.
- ERP — 이카운트에 주문 데이터를 넘겨 판매·재고 업무에 씁니다.
- 상태 — 주문 진행과 송장 등 배송 정보를 확인합니다.
출고 확정, 창고 작업, 재고 부족 때의 결정은 회사 프로세스입니다. 큐넥터가 모든 출고를 대신하거나 모든 지연을 자동으로 풀지는 않습니다. 주문 정보가 한곳에 있고, 담당자와 시스템으로 이어질 기반을 만드는 쪽에 가깝습니다.
9. 지연을 보려면 건수 옆에 지표를 둡니다
| 지표 | 계산 | 보는 이유 |
|---|---|---|
| 주문 확인 지연율 | 확인 목표를 넘긴 주문 ÷ 확인 대상 × 100 | 접수 직후 병목 |
| 정시 출고율 | 기한 내 출고 ÷ 기한이 된 주문 × 100 | 일정 준수 |
| 평균 확인 시간 | 접수부터 최초 확인까지 평균 | 대응 속도 |
| 출고 지연 건수 | 약정 출고일을 넘긴 미출고 | 지연 규모 |
| 주문 변경 발생률 | 변경된 주문 ÷ 전체 주문 × 100 | 변경 빈도 |
기한이 된 주문이 500건이고 475건이 기한 안에 나갔다면 정시 출고율은 95%입니다. 거래처·품목·창고·단계에서 반복되는지를 볼 수 있습니다. 이 지표가 큐넥터에서 모두 자동 계산된다는 뜻은 아닙니다. 확보되는 데이터와 별도 집계로 관리하는 운영 지표입니다.
접수됐다는 사실보다, 다음 일이 진행 중인가
접수는 시작입니다. 확인하고, 조건을 보고, 재고를 맞추고, 출고와 배송이 이어져야 거래가 끝납니다. 담당, 상태, 기한이 비어 있으면 시스템이 있어도 지연됩니다. 주문관리의 핵심은 주문을 모으는 일이 아니라, 어느 단계인지 보고 다음 담당이 필요한 정보를 받게 하는 일입니다.
지금 접수 이후 출고까지 어떻게 넘어가는지 적어 보시고, 범위가 궁금하면 상담으로 문의해 주세요. 화면 안내는 사용 가이드, 주문이 흩어지는 앞 단계는 B2B 주문관리 가이드를 참고하세요.
자주 묻는 질문
- 주문은 접수됐는데 출고가 안 됐다면 누구의 책임인가요?
- 법적으로 한 사람을 지목하는 문제가 아니라, 내부에서 그 단계를 확인할 운영 책임입니다. 확인이 안 됐으면 주문 담당, 출고 준비가 멈췄으면 물류가 먼저 봅니다. 그 전에 주문이 어느 단계에서 멈췄고 무엇이 전달됐는지를 보세요.
- 주문 접수와 주문 확정은 무엇이 다른가요?
- 접수는 구매자 요청이 등록된 상태입니다. 확정은 품목·수량·단가·거래 조건을 보고 처리하기로 한 상태입니다. 재고나 결제 조건을 확인해야 하면 둘을 같은 의미로 두면 기대가 어긋납니다.
- 주문관리 프로그램을 쓰면 출고 지연이 없어지나요?
- 상태와 알림으로 지연을 일찍 보는 데는 도움이 됩니다. 재고 부족, 창고 작업, 운송사 문제까지 프로그램만으로 막지는 못합니다.
- 출고 지연 알림은 어떻게 나누나요?
- 신규 주문, 변경, 취소처럼 조치가 필요한 사건만 고르고, 영업과 물류에 같은 알림을 보내지 않는 편이 낫습니다. 처리 기한 초과를 자동으로 알리려면 그 기능이나 별도 연동이 있는지도 확인하세요. 큐넥터 기본 알림이 모든 기한 초과를 자동 감지한다는 뜻은 아닙니다.
- 이카운트와 같이 쓰면 무엇이 달라지나요?
- 거래처 주문 접수와 ERP 판매·재고 업무를 이어 재입력을 줄일 수 있습니다. 출고 결과가 어디까지 다시 반영되는지는 연동 설정과 지원 범위에 따라 다릅니다.
- 큐넥터에서 주문 상태와 배송을 볼 수 있나요?
- 주문 진행 상태와 송장 등 배송 정보를 확인할 수 있습니다. 화면에 보이는 상태명, 갱신 방식, 외부 연동 범위는 설정에 따라 달라집니다. 이 글의 7단계 표는 내부 운영 모델이며, 화면 상태명과 1:1로 같지 않습니다.
함께 보면 좋은 글
써보면서 이해하는 게 가장 빠릅니다
현재 주문 채널·이카운트 사용 방식만 알려주셔도, 우리 회사에 맞는 수발주 흐름을 함께 잡아 드립니다.
