Bigcommerce 배송 통합: 요금, 라벨 및 추적 옵션

BigCommerce 배송 통합은 결제 시 배송 요금 계산, 주문 처리를 위한 라벨 구매, 발송 후 소포 추적이라는 세 가지 업무를 수행합니다. 판매자에게 적합한 설정이 반드시 모든 기능을 제공한다고 약속하는 하나의 앱일 필요는 없습니다. 결제 방법, 창고 작업, 배송 기록, 고객 업데이트가 일관되게 유지되는 연결된 워크플로가 중요합니다.

현재 문제가 발생하고 있는 배송 영역부터 시작하세요. 예상치 못한 결제 요금이 발생한다면 요금 검토가 필요합니다. 포장 및 발송이 느리다면 라벨 워크플로를 검토해야 합니다. 배송 업데이트가 누락된다면 더 나은 추적 기능이 필요합니다. 이러한 문제는 주문 데이터를 공유할 수 있지만, 하나를 해결한다고 해서 다른 문제가 자동으로 해결되지는 않습니다.

각 배송 통합이 실제로 하는 일

통합을 선택하기 전에 고객에게 보이는 배송 혜택과 이를 이행하는 데 필요한 운영 업무를 구분하세요. 결제 시 부과되는 배송 요금이 나중에 라벨에 지불할 금액과 반드시 같은 것은 아니며, 추적 번호가 있다고 해서 운송업체가 소포를 인수했다는 의미도 아닙니다.

BigCommerce의 공식 앱 마켓플레이스는 패키지형 통합을 찾는 출발점입니다. 개발자 문서는 맞춤형 연결을 검증하는 출발점입니다. 마켓플레이스 등록 정보만으로 해당 앱이 사용 중인 모든 국가, 운송업체 서비스, 결제 구성 또는 주문 처리 워크플로를 지원한다고 판단해서는 안 됩니다.

워크플로를 중심으로 통합 경로를 선택하세요

규칙이 단순하다면 플랫폼 배송 설정을 사용하세요

배송 혜택이 단순하다면 먼저 스토어에서 이미 사용할 수 있는 배송 구성을 검토하세요. 다른 시스템을 추가하기 전에 서비스 지역, 구매자에게 표시할 방법, 해당 방법에 적용되는 상업적 규칙을 정의하세요.

예를 들어 표준 국내 배송 요금을 제공하는 스토어라면 외부 요금 엔진보다 더 명확한 배송 지역과 제외 규칙이 필요할 수 있습니다. 여러 위치에서 대형 상품을 배송하는 스토어는 다른 문제를 안고 있습니다. 단순한 요금이 주문 처리 비용의 중요한 차이를 가릴 수 있기 때문입니다.

가장 적합한 경우: 예측 가능한 소포, 제한적인 주문 처리 복잡성, 기존 구성으로 표현할 수 있는 배송 규칙을 가진 판매자. 필요한 로직을 안정적으로 표현할 수 없을 때 이 경로를 넘어가세요. 단순히 다른 앱에 설정이 더 많다는 이유만으로 변경할 필요는 없습니다.

반복적인 주문 처리 업무에는 패키지형 통합을 사용하세요

직원이 주소를 반복해서 복사하거나 서비스를 선택하고, 라벨을 구매하거나, 추적 번호를 입력한다면 패키지형 배송 통합을 검토할 가치가 있습니다. 그 가치는 인계 작업을 줄이고 주문 기록을 실제 발송 내용과 일치시키는 데서 나옵니다.

모든 라벨 통합이 결제 배송 요금도 제공한다고 가정하지 마세요. 마찬가지로 주문을 가져오는 앱이 배송 세부 정보를 BigCommerce에 다시 기록할 수 있다고 가정하지 마세요. 제공업체에 귀사의 워크플로를 사용해 필요한 각 데이터 이동 방향을 시연해 달라고 요청하세요.

가장 적합한 경우: 자체 통합을 유지 관리하지 않고 검증된 운영 인터페이스를 원하는 팀. 필수 창고 규칙에 수작업 우회가 필요해 절약되는 시간을 상쇄한다면 적합하지 않습니다.

다른 시스템이 주문 처리를 담당한다면 맞춤형 연결을 사용하세요

주문 관리 시스템, 창고 플랫폼 또는 제3자 물류 제공업체가 이미 발송을 통제하고 있다면 맞춤형 통합이 적합할 수 있습니다. 이러한 방식에서는 BigCommerce가 모든 배송 작업의 운영상 기준 시스템이라기보다 판매 채널 역할을 할 수 있습니다.

주소, 포장 결정, 라벨 구매, 배송 생성 및 추적 업데이트를 어느 시스템이 관리할지 정의하세요. 그런 다음 관련 문서에서 필요한 API 작업, 인증 요건, 권한 및 플랫폼 제약을 확인하세요.

가장 적합한 경우: 실제 워크플로 요건과 이를 유지 관리할 기술 역량을 갖춘 판매자. 모니터링, 지원 및 향후 변경 사항까지 포함하면 맞춤형 개발이 항상 가장 저렴한 경로는 아닙니다.

요금: 결제 시 약속과 배송 운영을 일치시키세요

요금 통합은 단순히 숫자를 반환하는 것이 아니라 실제로 처리할 수 있는 배송 혜택을 제공해야 합니다. 제공업체를 테스트하기 전에 서비스 이용 가능 여부와 비용을 결정하는 출발지, 목적지, 상품 및 포장 입력값을 문서화하세요.

• 출발지: 어느 창고 또는 주문 처리 파트너가 주문을 발송합니까?
• 상품 데이터: 중량과 치수가 정확하며 단위가 일관됩니까?
• 포장: 계산 시 개별 상품, 선택한 상자 또는 예상 포장을 사용합니까?
• 목적지: 외딴 지역, 우편 사서함 및 서비스 지역 밖의 장소는 어떻게 처리합니까?
• 상업적 규칙: 계산된 금액을 청구합니까, 배송비를 보조합니까, 아니면 프로모션 기준을 적용합니까?

주문 처리 시 사용하는 포장, 서비스, 출발지 또는 계정이 결제 시 가정과 다르기 때문에 결제 요금과 라벨 비용이 다를 수 있습니다. 요금 계산이 잘못되었다고 결론 내리기 전에 테스트 주문의 양쪽을 비교하세요.

실패 동작도 정의하세요. 요금 요청이 실패하면 결제 화면에 구성된 대안을 표시할지, 영향을 받은 방법을 제거할지, 주문을 중단할지 결정해야 합니다. 적절한 선택은 팀이 대안을 이행할 수 있는지에 달려 있습니다. 배송할 수 없는 주문을 승인하는 대체 요금은 성공적인 복구가 아닙니다.

국제 주문의 경우 운송 요금과 관세 및 세금을 구분하세요. 담당 서비스가 관련 요금을 명시적으로 계산하고 주문 처리 과정이 명시된 결제 방식을 지원하지 않는 한, 요금을 모든 비용이 포함된 도착 원가라고 설명하지 마세요.

라벨: 전체 발송 주기를 평가하세요

라벨 구매는 첫 번째 출력 성공만이 아니라 주문 가져오기부터 취소까지 테스트해야 합니다. 운영상의 핵심 질문은 통합이 창고 작업과 스토어 기록을 동기화된 상태로 유지하는지 여부입니다.

다음 승인 확인 항목을 사용하세요.

1. 주문 가져오기: 올바른 주문이 주문 처리에 사용할 수 있게 되는지, 수정 사항이 예측 가능하게 처리되는지 확인합니다.
2. 포장 생성: 단일 소포, 여러 소포 및 일부 상품만 배송되는 주문을 테스트합니다.
3. 서비스 선택: 구매자가 결제 시 선택한 방법이 창고 직원이 구매하는 서비스와 어떻게 매핑되는지 확인합니다.
4. 인쇄: 라벨 크기, 파일 형식 및 인쇄 설정이 실제 창고 장비에서 작동하는지 확인합니다.
5. 배송 정보 기록 반영: 올바른 추적 정보와 배송된 상품이 BigCommerce 주문에 전달되는지 확인합니다.
6. 재인쇄 및 무효화: 직원이 중복 구매를 방지하는 방법과 사용하지 않은 라벨을 해당 제공업체 규정에 따라 처리하는 방법을 정합니다.

특히 유용한 테스트는 라벨 구매는 성공했지만 이후 주문 업데이트가 실패하는 경우입니다. 직원에게는 다른 라벨을 구매하지 않고 주문을 업데이트할 수 있는 복구 경로가 필요합니다. 세련된 시연과 신뢰할 수 있는 실제 운영 워크플로가 달라질 수 있는 지점이 바로 여기입니다.

고객 알림을 누가 관리하는지도 확인하세요. 배송 통합과 다른 연결 시스템이 모두 발송 메시지를 보내면 고객이 중복되거나 서로 충돌하는 업데이트를 받을 수 있습니다.

추적: 배송 기록과 배송 가시성을 구분하세요

주문에 추적 번호를 기록하는 것은 기록 관리 문제를 해결합니다. 이후 운송업체 이벤트를 수집하는 것은 가시성 문제를 해결합니다. 비즈니스에는 둘 다 필요할 수 있지만 각각 별도로 평가해야 합니다.

유용한 추적 워크플로는 주문, 배송, 소포, 운송업체 및 추적 번호 사이의 관계를 유지합니다. 하나의 주문에 여러 소포가 있거나 소포가 둘 이상의 배송 사업자를 거치는 경우 이 관계가 중요합니다.

개발자가 주도하는 추적 계층이라면 17TRACK Tracking API를 검토할 수 있습니다. 공식 API 문서는 맞춤형 워크플로에서 추적 등록과 이벤트 전달을 평가하는 기반을 제공합니다. 이는 추적 사용 사례이며 결제 요금 계산이나 라벨 구매를 대체하지 않습니다.

API를 사용할 수 있다고 해서 즉시 사용할 수 있는 BigCommerce 커넥터가 포함된다고 가정하지 마세요. 스토어 또는 주문 처리 시스템에서 추적 서비스로 배송 세부 정보가 어떻게 이동하는지, 업데이트가 목적지에 어떻게 전달되는지, 연결을 누가 유지 관리할지 정하세요.

구현 전에 실제 운송업체와 서비스에 대한 지원 여부, 관련 구독 조건 및 업데이트 전달 구성을 확인하세요. 그런 다음 지연된 스캔, 인식되지 않는 번호, 중복 업데이트 및 배송 예외를 테스트하세요. 추적 통합은 발생하지 않은 실제 운송업체 스캔을 생성할 수 없습니다.

비즈니스 내부에서 추적 담당자도 지정하세요. 배송 정체를 조사하고 운송업체 또는 고객에게 연락할 시점을 결정할 책임자가 없다면 예외 대시보드의 운영 가치는 제한적입니다.

표면적인 가격에 의존하지 않고 총비용을 비교하세요

이러한 통합 계층은 서로 다른 업무를 수행하므로 단일 광고 구독료가 아니라 필요한 워크플로를 기준으로 비용을 비교하세요.

• 소프트웨어 요금: 구독, 사용량 한도, 초과 요금 및 별도 청구 기능을 파악합니다.
• 배송 요금: 우편 요금과 운송업체 조정 비용을 소프트웨어 요금과 분리합니다.
• 구현: 설정, 데이터 정리, 서비스 매핑, 테스트 및 직원 교육을 포함합니다.
• 지속적인 운영: 수동 수정, 동기화 실패 및 지원 담당 비용을 고려합니다.
• 종료 요건: 진행 중인 주문을 방해하지 않고 배송 기록을 가져오고 연결을 제거할 수 있는 방법을 확인합니다.

각 제공업체에 어떤 이벤트가 과금 대상 사용량에 포함되는지 설명해 달라고 요청하세요. 주문, 라벨, 소포, 등록된 추적 번호 및 API 요청은 서로 대체할 수 있는 단위가 아닙니다. 비용을 추정할 때는 자체 운영의 대표적인 기간을 사용하세요.

전환 전에 소규모 엔드투엔드 파일럿을 실행하세요

가장 효과적인 선택 방법은 실제와 유사한 주문을 사용한 통제된 파일럿입니다. 일반적인 국내 소포, 여러 상품이 포함된 주문, 분할 배송, 그리고 비즈니스에 중요한 국제 또는 특수 배송 유형을 포함하세요.

각 테스트에서 결제 시 제공된 배송 방법, 선택된 서비스, 라벨 결과, 배송 기록, 추적 목적지 및 고객 알림을 기록하세요. 주소 거부 또는 동기화 중단과 같은 실패 사례도 최소 하나 추가하세요.

책임을 명확히 배정하세요. 전자상거래 팀은 결제 동작을 승인하고, 창고 직원은 포장 및 인쇄를 승인하며, 고객 지원팀은 배송 가시성을 승인하고, 기술 담당자는 권한 및 복구 절차를 승인해야 합니다. 각 연결이 어떤 고객 데이터를 받는지 검토하고 업무에 필요한 접근 권한만 부여하세요.

실용적인 권장 사항: 운영이 허용하는 범위에서 설정을 최대한 단순하게 유지하세요. 기존 배송 구성이 요구 사항을 충족한다면 이를 사용하고, 반복 작업을 줄여 주는 주문 처리 통합을 추가하며, 배송 가시성에 별도 워크플로가 필요할 때 전용 추적 계층을 도입하세요. 기본적으로 중복 기능을 구매하기보다 각 계층을 신중하게 연결하세요.

FAQ

요금, 라벨 및 추적에 별도의 통합이 필요합니까?

반드시 그렇지는 않습니다. 하나의 통합이 여러 기능을 담당할 수도 있고 다른 통합은 한 가지 기능만 처리할 수도 있습니다. 주문을 읽고 배송 정보를 다시 기록하며 이후 추적 업데이트를 전달하는지 여부를 포함하여 필요한 각 기능을 독립적으로 확인하세요.

라벨 통합이 결제 배송 요금을 자동으로 변경합니까?

그렇게 가정하지 마세요. 라벨 구매는 주문 처리 중에 이루어지는 반면 결제 배송 요금은 주문이 접수되기 전에 표시됩니다. 통합이 결제 요금 기능을 제공하는지, 그리고 스토어 구성에서 작동하는지 확인하세요.

자체 운송업체 계정을 연결할 수 있습니까?

통합, 운송업체, 계정 자격 및 배송 지역에 따라 다릅니다. 어떤 계정과 서비스가 지원되는지, 계정 요금을 사용할 수 있는지, 우편 요금과 이후 조정 비용을 누가 청구하는지 문의하세요.

17TRACK이 BigCommerce 라벨 도구를 대체할 수 있습니까?

Tracking API는 라벨 구매의 대체 수단이 아니라 추적 가시성을 위한 도구로 평가해야 합니다. 맞춤형 워크플로는 배송 정보를 추적 서비스에 연결하면서 결제 계산과 라벨 생성을 해당 업무를 담당하는 시스템에 맡길 수 있습니다.

추적 번호를 받은 후 고객에게 배송 진행 상황이 표시되지 않는 이유는 무엇입니까?

소포가 최초 운송업체 스캔을 받기 전에 추적 번호가 존재할 수 있습니다. 잘못된 번호, 운송업체 식별 문제 또는 이벤트 제공 지연도 원인일 수 있습니다. 업데이트가 없는 것을 소프트웨어 장애로 판단하기 전에 주문 처리 인계와 운송업체 정보를 확인하세요.

출처

• BigCommerce 앱 마켓플레이스 — 패키지형 통합을 식별하고 개별 등록 정보를 확인하기 위한 공식 출발점.
• BigCommerce 개발자 문서 — 플랫폼 통합 요건과 API 구현 세부 정보를 검증하기 위한 공식 참고 자료.
• 17TRACK Tracking API — 이 가이드에서 설명한 추적 API 옵션에 대한 공식 제품 참고 자료.
• 17TRACK API Documentation — 맞춤형 추적 워크플로를 평가하기 위한 기술 참고 자료.