쇼핑몰 주문은 쌓이는데, 3PL 출고·송장 입력을 엑셀로만 하면 왜 막히나요?
주문이 결제되면 쇼핑몰 관리자에 주문이 쌓입니다. 그런데 실제 포장·출고는 자사 창고가 아니라 물류대행(3PL) 업체가 맡는 몰이 많습니다. 이런 구조에서는 운영자가 매일 주문 엑셀을내려 3PL에 넘기고, 출고 뒤 송장 번호를 다시 쇼핑몰에 손으로 넣는 흐름이 흔합니다. 주문 수가 적을 때는 버틸 수 있어도, 세일·주말에는 ‘송장이 언제 올라가나요’ CS와 중복 출고 위험이 같이 커집니다.
쇼핑몰 기본 기능만으로는 결제된 주문을 3PL이 쓰는 형식으로 자동 전송하거나, 3PL이 준 송장 번호를 주문에 자동으로 붙이지 않습니다. 배송사·송장 입력 화면은 있지만, 외부 물류사와 양방향으로 맞추는 연결은 없습니다. 이번 사례의 몰도 처음에는 엑셀 업로드와 수기 송장으로 버텼고, 과제는 예쁜 대시보드가 아니라 ‘출고할 주문을 한 번만 넘기고, 나온 송장을 손님·CS가 같은 주문에서 보게’ 만드는 것이었습니다. 주문 상태만 외부 ERP에 맞추는 연동과는 방향이 다릅니다. 여기서는 주문을 물류로 보내고, 송장을 쇼핑몰로 되돌려야 합니다.
- 결제 주문 → 3PL 출고 지시를 엑셀·수작업으로 반복
- 송장 번호가 늦게 올라가 ‘배송 조회’ CS가 늘어남
- 같은 주문이 두 번 넘어가 중복 출고될 위험
- 쇼핑몰 기본만으로는 3PL 양방향 연동이 없음
쇼핑몰 주문을 3PL에 넘기고 송장을 다시 주문에 붙이려면 어떻게 맞추나요?
접근의 핵심은 스킨이나 브라우저에서 물류 API를 돌리지 않고, 별도 서버가 쇼핑몰 주문과 3PL 사이를 중계하는 것이었습니다. 서버는 결제·배송준비 같은 조건에 맞는 주문을 웹훅이나 짧은 주기 조회로 받은 뒤, 수취인·주소·품목·수량을 3PL이 요구하는 출고 요청 형식으로 바꿉니다. 전송이 성공하면 우리 쪽에 ‘이미 출고 지시함’ 기록을 남기고, 실패하면 재시도 목록에 올려 운영자가 다시 보낼 수 있게 했습니다.
3PL에서 송장이 발번되면 서버가 그 값을 받아 쇼핑몰 주문의 배송사·송장 번호 필드에 반영합니다. 쇼핑몰 쪽 송장 등록 API(또는 동등한 주문 배송 정보 갱신)를 쓰고, 토큰·시크릿은 서버에만 두었습니다. 손님 마이페이지와 관리자 주문서에 같은 송장이 보이도록, ‘송장만 먼저 넣고 상태는 나중에’인지 ‘송장과 배송중을 같이’인지도 운영 규칙으로 고정했습니다.
같은 주문이 두 번 출고되거나 취소 뒤에도 나가는 일을 어떻게 막았나요?
연동에서 가장 자주 터지는 사고는 중복 출고와 취소 타이밍입니다. 웹훅·배치가 같은 주문을 두 번 잡거나, 손님이 취소했는데 이미 3PL에 넘어간 경우가 대표적입니다. 이번 작업에서는 주문번호(필요하면 품목 단위)를 기준으로 이미 전송한 건은 건너뛰도록 했고, 쇼핑몰에서 취소·환불이 잡히면 3PL 쪽에 출고 취소 요청을 보낼 수 있는 구간과, 이미 송장이 난 뒤라 수작업 회수만 가능한 구간을 문장으로 나눴습니다.
부분 출고·합포장·도서산간 추가비가 있는 몰은 1차에서 전 규칙을 열지 않았습니다. 먼저 ‘한 주문 = 한 출고 지시 = 한 송장’이 맞는 상품군부터 열고, 복수 송장·분할 출고는 2차로 남겼습니다. 검수에서는 결제→출고 지시→송장 반영, 같은 주문을 두 번 전송해도 한 번만 나가는지, 출고 전 취소가 3PL에 전달되는지를 시나리오로 돌렸습니다.
- 별도 서버가 쇼핑몰 주문 → 3PL 출고 요청을 중계
- 3PL 송장 회신을 쇼핑몰 주문 배송 정보에 반영
- 주문번호 기준 중복 전송 방지·실패 재시도
- 출고 전 취소와 송장 후 회수 구간을 문서로 분리
- 1차는 단일 송장 흐름, 분할·합포장은 다음 단계
3PL 출고와 쇼핑몰 송장이 맞물리면 운영·CS는 어떻게 달라지나요?
결제된 주문이 정해진 조건에서 3PL로 넘어가고, 출고 후 송장이 쇼핑몰 주문에 붙으면 엑셀 왕복과 수기 송장 입력이 크게 줄어듭니다. 손님은 마이페이지에서 송장을 더 빨리 볼 수 있고, CS는 ‘아직 안 올라갔다’는 확인 전화를 줄이는 경우가 많습니다. 운영은 실패·스킵 목록만 보고 막힌 주문을 다시 보내면 됩니다.
한계도 분명합니다. 쇼핑몰 기본만으로 3PL 전용 출고·송장 양방향 연동은 되지 않으며, 물류사마다 API·엑셀 포맷·취소 가능 시점이 다릅니다. 완전 실시간 약속보다 ‘출고 지시와 송장 반영이 하루 운영 리듬에 맞게 따라간다’는 목표가 현실적입니다. 주문 상태만 외부에 맞추는 웹훅 사례나 주문 API 개요 글과 맞닿아 있지만, 이번 사례는 물류 출고 지시와 송장 회신에 초점을 두었습니다. 재고·정산·알림톡까지 한 번에 넣기보다, 출고·송장·중복 방지를 1차로 고정하는 편이 일정에 유리했습니다.
- 엑셀 출고·수기 송장 입력 부담 감소
- 손님·CS가 같은 주문에서 송장 확인
- 중복 출고·취소 타이밍을 규칙으로 관리
- 이후 분할 출고·알림 자동화로 확장 가능
옴니어스24는 이 3PL·송장 연동에서 무엇을 맡았나요?
옴니어스24는 ‘3PL 연동해 주세요’만 듣고 전 물류·전 상품을 한꺼번에 열지 않습니다. 어느 상태의 출고를 넘기는지, 3PL이 API인지 파일인지, 송장을 쇼핑몰에 언제 넣는지, 취소는 어디까지 자동인지부터 정리합니다. 주문 수가 적고 하루 한 번 엑셀로도 버틸 만하면 그쪽을 유지하고, 중복·지연 CS가 반복되면 별도 서버·멱등·재시도 범위를 나눕니다.
비슷한 요구가 있으시면 쓰는 3PL 이름(또는 파일 양식), 하루 평균 출고 건수, 최근 송장이 늦었던 주문 한 건만 알려 주셔도 상담이 빨라집니다.
3PL·송장 연동 사례 다음에 보면 좋은 글·페이지
주문 상태가 외부 화면에 늦게 따라오는 문제는 웹훅 실시간 반영 사례에서, 주문 API로 무엇을 가져오는지는 주문 데이터 개요에서, 별도 서버가 왜 필요한지는 API·서버 글에서 이어서 볼 수 있습니다. 연동 수정 중 판매를 멈출지는 판매 중단 여부 글도 참고하세요.
서비스·진행 방식·FAQ에서 범위를 나누는 이야기도 볼 수 있고, 문의 페이지에 현황만 남겨 주셔도 됩니다. 3PL 방식·출고 조건·송장 반영 시점 기준으로 안내해 드립니다.