시나리오: 이커머스 스토어 구현하기

개요

e-commerce라는 용어는 판매자 및 구매자가 온라인 시장을 사용하여 상품 및 서비스를 구매하고 판매하는 데 동의하는 비즈니스 모델을 의미합니다. 일반적으로 트랜잭션은 컴퓨터, 태블릿, 스마트폰 및 기타 디바이스와 같은 전자 매체를 사용하여 수행됩니다. 온라인 쇼핑 세그먼트는 새로운 개념이 아닙니다. 이는 계속해서 인기를 끌고 있으며, 이제는 쇼핑을 하는 방법 중 하나입니다.

이 시장에서 사용할 수 있는 상품 및 서비스의 유형은 무한합니다. 전자, 서적, 식료품, 패션, 가구 및 기타 모든 소비재를 포함하여 오프라인 상점에서 찾을 수 있는 거의 모든 상품이 온라인에서 발견될 수 있습니다. 서비스는 이제 구매자가 학습, 상담을 예약하거나 e-commerce 트랜잭션의 일부로 추가 서비스를 배치할 수 있는 일반적인 온라인 쇼핑 경험이기도 합니다.

e-commerce의 장점

판매자는 온라인 시장 공간을 호스트하기 위해 서버 클러스터를 구성하기 위해 더 많은 자원에 투자해야 합니다. 그러나 오프라인 상점에 필요한 투자와 비교하여 온라인 공간은 서버 사이트가 호스트되는 위치에 물리적 제한조건을 부과하지 않습니다. 또한 판매자는 구매자를 위한 충분한 물리적 공간을 확보하는 것에 대해 걱정할 필요가 없습니다. 구매자가 판매자의 온라인 마켓플레이스를 쉽게 찾을 수 있는 경우, 실제로 온라인 마켓플레이스에 진입할 수 있는 구매자의 수는 제한이 없으며 확장성이 매우 높습니다.

운영 비용을 고려할 때, 서버 하드웨어 유지보수 비용은 물리적 오프라인 상점을 설치하는 것과 비교하여 매우 최적화되어 있습니다. 어떤 상점 위치에서도 성공 여부가 확실하지 않은 경우 온라인 상점 첫화면을 호스팅하기 위한 선크 비용은 분명히 경제적이며 확장성 면에서 매우 유연합니다.

전자상거래의 과제

새로운 온라인 상점 첫화면에 온라인 구매자가 대량으로 유입되는 것은 확실히 장점이지만, 두 가지 비즈니스 과제가 존재합니다. 먼저, 구매자가 쇼핑 사이트가 있음을 인식하도록 해야 합니다. 둘째, 구매자를 위한 완벽한 제품 검색 경험을 촉진해야 합니다. 동종 상품 검색의 경우, 대부분의 온라인 쇼핑객들은 자신들이 원하는 상품을 찾기 위해 웹 사이트로 뛰어들 수 있는 인내심이 부족합니다. 이러한 구매자는 검색의 처음 30초동안 상품을 찾을 수 없는 경우 실망합니다. 특수 제품 또는 브랜드 제품의 경우 구매자는 일반적으로 좀 더 지속성이 있습니다. 이 구매자는 필요한 항목을 검색하는 데 더 많은 시간이 소요되며 다른 온라인 상점 사이트로 이동하여 대안을 찾기만 하면 됩니다.

온라인 구매자 감소 비율은 상품 검색에서 시작하여 상품 정보 페이지, 장바구니 페이지, 주문 시작 페이지 및 판매 주문을 통해 이동하여 온라인 마케팅 퍼널 전체에 걸쳐 확장됩니다.

이 도표는 전자상거래 전환 퍼널의 개념을 보여줍니다. 이 퍼널은 온라인 구매자가 보고 싶은 것을 신속하게 표시하여 구매자 보유의 중요성을 강조표시합니다.

앞의 도표에 표시된 판매 전환율은 방정식의 절반에 불과합니다. 또한 전자상거래 판매자는 상품을 이행할 수 있는지 여부를 처리해야 합니다. 이행을 보장하기 위해 판매자는 이행 네트워크에 충분한 재고 또는 용량이 있는 경우에만 오더가 수락되는지 확인해야 합니다. 그렇지 않으면 주문이 이행되지 않을 수 있으며, 이로 인해 판매자의 브랜드 평판이 손상되고 구매자의 신뢰 레벨이 저하됩니다. 판매자가 해당 날짜에 이행할 수 있는 항목으로만 표시를 제한하고 상품 제공 날짜에 대한 투명성을 제공하는 경우 긍정적인 쇼핑 경험을 추가로 개선할 수 있습니다. 판매자는 사전 구매 캡처 프로세스에서 초기에 제품의 소스 위치 및 구매자가 선택한 운송업체 서비스를 알고 있을 때 더 큰 통찰력을 얻을 수 있습니다.

전달 옵션 환경 설정

전자상거래 판매의 초기 단계에서 대부분의 쇼핑 경험에는 구매자의 문으로 직접 배송된 제품이 포함되었습니다. 구매자가 차세대 e-commerce 경험으로 관심을 이동함에 따라 선호하는 이행 방법을 개발합니다. 이러한 선호하는 이행 방법에는 쉽먼트, 상점에서 오더 픽업, 큐브사이드 픽업 및 키오스크에서 픽업이 포함될 수 있습니다. 이러한 각 이행 방법은 판매자에게 복잡도를 추가합니다. 판매자는 단순히 상품을 운송하는 것이 아니라 구매자 픽업에 상품을 사용할 수 있도록 하는 이행 비용을 고려해야 합니다.

긍정적인 쇼핑 경험을 위한 주요 요소

긍정적인 구매자 경험을 구축하는 데 필요한 몇 가지 주요 요인은 다음과 같습니다.

Sterling Intelligent Promising 가 e-commerce 성공을 가속화하는 방법

전자 상거래의 인기가 높아지면서 Sterling Intelligent Promising 의 기본 목표는 판매자의 전자 상거래 변환을 가속화하는 것입니다. 이 변환은 두 가지 주요 제품 측면에서 용이합니다. 구성 시간을 최소화하고 전자상거래 이행 워크플로우를 지원하기 위한 유연한 도구를 제공하는 것입니다. Sterling Intelligent Promising 는 프론트 엔드 상점 캡처 애플리케이션이 아니라 항목을 판매할 수 있는 시기 및 위치에 대한 키 이행 판별자입니다. 이 정보를 통해 구매자는 이월 주문 이벤트의 위험이 최소화되기 때문에 상점 사이트에서 자신 있게 주문을 제출할 수 있습니다.

Sterling Intelligent Promising 는 다음 요인을 사용하여 실시간 이행 예상을 제공할 수 있습니다.

Sterling Intelligent Promising 는 또한 다음 단계로 구성된 엔드-투-엔드 e-commerce 사전 및 사후 주문 캡처 워크플로우를 지원할 수 있습니다.

Sterling Intelligent Promising 를 사용하여 e-commerce 쇼핑 경험 향상

e-commerce 워크플로우를 구현하는 많은 방법이 있지만 Sterling Intelligent Promising 은 온라인 MarketPlace에서 구매자 경험을 개선하기 위해 확약 API를 사용할 수 있는 방법에 대한 다음 지침을 제공합니다.

제품 검색

판매자가 제공하는 상품 카탈로그의 크기에 따라 다양한 방법으로 상품 검색을 구현할 수 있습니다. 이를 구현하는 가장 간단한 방법은 구매자가 Jeans와 같은 상품 카테고리를 선택하고 이를 상품 목록 페이지로 경로 재지정하여 상품 목록을 표시할 수 있도록 하는 것입니다. 반대로, 대규모 조직은 종종 여러 판매자 또는 대형 카탈로그를 포함합니다. 이 시나리오에서는 구매자가 표시된 상품 목록의 범위를 좁히는 데 도움을 주기 위해 온라인 마켓플레이스에서 복잡한 검색 기능이 필요할 수 있습니다.

접근 방식에 상관없이 판매자에게 가장 어려운 태스크는 즉시 사용 가능하거나 가까운 시일 내에 제공되는 제품으로만 제품 범위를 좁히는 기능입니다. 구매자가 제품을 검색하고 처음 몇 개의 검색 결과에 나열된 각 제품을 사용할 수 없음을 인식하는 것은 좋지 않은 경험입니다. 이 필터링되지 않은 동작은 전체 브랜딩 및 쇼핑 경험을 저하시킵니다. 따라서 첫 번째 나열된 항목이 가장 높은 우선순위인 다음과 같은 순차 기준을 기반으로 제품 목록의 우선순위를 지정해야 합니다.

상품 제공 날짜 및 상품 가용성 날짜는 가장 중요한 기준입니다. 상품의 등급이 100%인 경우에도 배송 및 가능한 날짜가 구매자의 예상과 일치하지 않으면 판매자는 구매자가 원하는 날짜에 배송을 보장할 수 없습니다. 따라서 차선의 검색 결과는 검색 시스템에 의해 필터링되어야 합니다.

전자상거래 판매자는 상품 카탈로그를 기반으로 일별 검색 색인을 빌드하여 필요한 시간 범위 내에 전달할 수 있는 사용 가능한 항목만 포함되도록 할 수 있습니다. 이 필터링을 사용하면 구매자가 항상 즉시 구매할 수 있는 항목을 볼 수 있습니다. 이 동작을 지원하기 위해 판매자는 Calculate item delivery date API를 이용하여 가장 빠른 배송 날짜 또는 날짜별 오더 목록을 미리 계산할 수 있습니다. 그런 다음 판매자는 일일 검색 색인이 빌드될 때 해당 정보를 필터 기준으로 사용할 수 있습니다. 검색 색인이 미리 컴파일되기 때문에 Calculate item delivery date API는 향후 시간 수평을 기반으로 배송 날짜를 추정하기 위한 참조 시간 개념을 제공합니다. 예를 들어, 내일 검색 색인을 구현하려는 경우 시스템은 색인을 미리 빌드할 수 있도록 내일의 참조 시간으로 Calculate item delivery date API를 호출해야 합니다.

Calculate item delivery date API에 대한 자세한 정보는 예상 아이템 배송 날짜를 참조하십시오.

Calculate item delivery date API에는 빠른 응답 시간이 있지만 페이지가 로드될 때 판매자가 배송 날짜를 검색하는 것은 권장되지 않습니다. 웹 서버는 잠재적으로 구매자의 경험에 영향을 줄 수 있는 추가 필터링 및 순위 지정 로직을 수행해야 합니다. 원활한 쇼핑 경험을 제공하려면 예상 배송 날짜 사전 계산을 수행하여 전체 상품 검색 응답 시간을 개선하십시오.

확장성 및 성능을 더 향상시키려면 판매자가 분산 상점 웹 서버를 사용하고 각 웹 서버가 중앙 서버를 사용하는 대신 로컬 검색 색인을 처리하는 것이 좋습니다. Sterling Intelligent Promising 가 많은 수의 동시 트랜잭션 및 대부분의 이행 요청 전용 조회를 지원하지만 로컬 색인 캐시를 배치하면 예상 요청 수가 최소화됩니다. 또한 로컬 색인 캐시는 장바구니에 항목 추가, 수량 변경 및 트랜잭션 체크아웃과 같은 필수 트랜잭션으로만 요청을 제한합니다.

이 도표는 구매자 검색 색인 워크플로우의 단순 구성을 보여줍니다.

검색 페이지 컴포넌트

이 구성요소는 검색 페이지를 빌드하는 데 사용됩니다.

제품 목록 페이지

상품 목록 페이지는 상품 검색 결과를 기반으로 기획 상품 목록을 표시합니다. 페이지는 목록 보기 또는 격자 보기에 제품을 표시할 수 있습니다. 일반적으로 전자상거래 상점 사이트에서 동일한 유형의 보기가 사용됩니다. 구매자가 온라인으로 상품과 상호작용할 수 없으므로 판매자는 목록에 있는 각 항목의 배송 날짜를 표시하여 이를 보상할 수 있습니다. 예상 운송 날짜는 구매자가 상품을 기다리는 것이 허용 가능하다는 것을 확신시키는 데 도움이 될 수 있습니다.

상품 목록 페이지의 각 항목에 대해 판매자는 가장 빠른 예상 배송 날짜를 표시하고 해당 배송 날짜를 충족하기 위해 상품을 주문해야 하는 시기를 표시할 수 있습니다. 이러한 날짜를 표시하면 구매자가 상품을 구매해야 하는 긴급성이 생성됩니다. 예상 배송 날짜가 표시되면 판매자는 여러 운송 그룹 (예: 표준 운송 및 경제 (무료) 운송) 에 대한 배송 날짜를 표시할 수 있습니다.

운송 그룹은 구매자가 사용할 수 있는 운송 옵션이며 예상 운송 날짜를 제공합니다. 판매자는 e-commerce웹 사이트에서 옵션으로 제공될 수 있는 하나 이상의 운송 그룹을 구성할 수 있습니다. 일반적으로 선적 그룹은 배송까지 지정된 일 수를 충족하는 하나 이상의 운송업체 서비스로 구성됩니다. 판매자는 운송 속도 또는 계약된 운송 비용별로 운송 회사 서비스를 구성할 수 있습니다. 운송서비스상품에 대한 자세한 정보는 운송서비스상품을 참조하십시오. 운송 그룹에 대한 추가 정보는 운송 그룹을 참조하십시오.

이 이미지는 시간별 주문 및 픽업 옵션과 함께 운송 그룹 운송 날짜를 표시하는 상품 목록 페이지의 섹션을 표시합니다.

판매자는 Calculate item delivery date API를 사용하여 두 개의 견본 운송 그룹 (Standard및 Economy Plus) 에 대한 예상 운송 정보를 가져올 수 있습니다. 예상 운송 날짜는 각 운송 그룹 및 항목에 대해 두 개의 키 값, 가장 빠른 운송 날짜 및 주문을 제출해야 하는 날짜를 리턴합니다.

판매자는 각 아이템의 운송 지속 기간을 표시할 수도 있습니다. 이 대안은 아이템 배송 날짜 계산 API에 포함되어 있습니다.

예

두 개의 드레스를 여러 크기로 사용할 수 있는 경우 이러한 드레스를 변형된 항목이라고도 합니다. 각 변형에는 고유 SKU (Stock Keeping Unit) ID가 있습니다. 변형이 있는 아이템은 하나 이상의 모델 또는 크기로 구성된 판매 불가능한 상위 아이템입니다. 각 하위 항목은 자체 재고가 있는 판매 가능한 단위입니다. 상위 항목을 사용하면 판매자가 동일한 디자인 또는 모델을 사용하여 SKU 콜렉션을 더 쉽게 추적할 수 있습니다. 예를 들어, 작은 크기의 빨간색 드레스와 중간 크기의 빨간색 드레스는 각각 다른 SKU를 가집니다. 운송 정보를 올바르게 표시하려면 판매자는 각 SKU에 대해 가장 빠른 운송 날짜 및 가장 빠른 날짜순 주문을 포함하여 여러 가지 정보가 필요합니다.

이 예에서 빨간색 드레스의 크기는 두 개이며 판매자는 두 개의 운송 속도를 제공합니다. 표시된 정보를 얻으려면 판매자가 각 하위 SKU및 운송 그룹에 대해 네 개의 API 요청을 작성해야 합니다.

그런 다음 결과 세트는 판매자의 웹 서버에 의해 정제되어 드레스 크기 중 가장 빠른 날짜를 도출합니다. 반대로 변형이 없는 아이템의 경우 판매자는 선적 그룹당 하나의 API 요청만 작성해야 합니다.

차이가 있는 항목의 수에 따라 복잡도가 증가합니다. 실시간 예상 호출 수를 최소화하기 위해 판매자는 웹 색인 캐시의 일부로 전달 정보를 저장하는 것이 좋습니다. 이러한 방식으로 모든 페이지 로드에 대해 정보를 다시 계산하지 않고 정보를 쉽게 사용할 수 있습니다. 대부분의 구매자는 상품 목록 페이지에서 대략적인 운송 예상만 필요합니다. 구매자가 상품 정보 페이지에 도달하면 더 정확한 예상을 표시할 수 있습니다. 이 전략은 판매자의 웹 서비스 로드와 구매자의 경험 모두에 이익이 됩니다.

자세한 정보는 Calculate estimated item delivery API를 참조하십시오.

제품 세부사항 페이지

이 이미지는 운송 그룹 예상 및 사용 가능한 픽업 옵션을 표시하는 상품 정보 페이지의 섹션을 표시합니다.

장바구니에 추가

구매자는 나중에 항목을 체크아웃하거나 구매할 수 있도록 장바구니에 항목을 추가합니다. 장바구니에 추가하는 것은 확약되지 않은 구매이므로 판매자는 일반적으로 비즈니스 규칙을 사용하여 주문 시작 프로세스가 끝날 때까지 항목이 사용 가능하도록 보장합니다. 이러한 규칙은 단기간 동안 아이템에 대한 "소프트 예약" 을 보장하지만, 해당 기간이 지나면 장바구니 포기로 간주되고 아이템 예약이 릴리스됩니다. 다른 판매자는 이 단계를 생략하고 체크아웃 단계 전에만 아이템 예약을 캡처하도록 선택할 수 있습니다.

유통관리그룹은 시장의 대상 지역 또는 세그먼트에 기여하는 선적 노드의 논리적 콜렉션입니다. 판매자는 단일 출하노드의 주소를 지정하는 대신 지리적 지역을 기반으로 유통관리그룹을 참조할 수 있습니다. 예를 들어, "동부 해안 그룹" 입니다. 분배 그룹은 네트워크라고도 합니다.

커미트되지 않은 상태의 항목의 경우 판매자는 보다 유연한 네트워크 레벨 (유통관리그룹) 예약을 수행할 수 있습니다. 예약이 네트워크 레벨에서 작성되면 품목은 짧은 기간 동안 예약되지만 선적 노드에 명시적으로 적용되지 않습니다. 이러한 방식으로 판매자는 유통관리그룹에 있는 하나 이상의 출하노드에서 아이템이 사용 가능한지 여전히 확인할 수 있습니다. 그러나 노드 레벨 예약은 다른 구매자에 대한 항목의 전체 가용성 레벨에 영향을 주는 노드의 사용 가능한 재고에서 공제되므로 권장되지 않습니다.

판매자는 Create Reservation API를 사용하여 네트워크 레벨 예약을 작성할 수 있습니다. 네트워크 레벨에서 항목을 예약하려면 웹 서비스가 분배 그룹 ID를 전달해야 합니다. 노드에서 예약하기 위해 판매자는 선적 노드 식별자를 전달합니다. 예약이 작성되면 판매자가 지정된 기간 (예: 5분) 후에 예약이 만기되도록 만기 시간 구성요소를 포함하는 것이 좋습니다. 예약이 만료되면 예약된 수량이 가용성 풀로 리턴되고 예약이 자동으로 취소됩니다. 판매자는 또한 웹 서버가 모든 요청에 대한 지속 기간을 하드코딩할 필요가 없도록 기본 예약 만기 지속 기간을 설정할 수 있습니다. Update settings API를 사용하여 기본 예약 만기 지속 기간을 설정할 수 있습니다.

이 이미지는 요청된 수량이 사용 가능한 재고보다 큰 경우 경고 메시지의 예를 표시합니다.

카트

구매자가 상점 사이트를 찾아볼 때 장바구니에 항목을 추가합니다. 장바구니에 추가된 항목이 서로 유사하거나 관련 항목인 경우가 많으므로 구매자는 이를 비교하고 주문 시작 전에 상품 선택 범위를 좁힐 수 있습니다. 제품 외에도 구매자는 사용 가능한 수량 및 각 장바구니 라인에 대한 납품을 얼마나 빨리 받을 수 있는지에 관심이 있을 수 있습니다. 구매자는 각 장바구니 라인의 예상 배송 날짜를 표시하여 원하는 항목을 쉽게 비교할 수 있습니다. 예를 들어, 구매자가 파란색 드레스와 빨간색 드레스 중 하나를 결정하는 유스 케이스가 있습니다. 빨간색 드레스가 내일 도착하고 파란색 드레스가 2주후에 도착하면 판매자는 스케줄된 요구에 따라 빨간색 드레스를 선택합니다.

제품 세부사항 페이지와 반대로 카트와의 한 가지 차이점은 각 카트 라인이 품목 수량으로 구성된다는 점입니다. Calculate item delivery date API 는 단일 가용성 및 유효한 용량 창을 고려하므로 카트 라인에 대한 정확한 예상을 제공할 수 없습니다. 이러한 이유로 Sterling Intelligent Promising 는 이 유스 케이스를 지원하기 위해 Calculate checkout assignments API 를 제공합니다. 이 API는 요청된 수량의 선적 속도를 기반으로 가장 빠른 배송 날짜를 판별하는 데 필요한 복잡한 계산을 처리합니다. 판매자는 동일한 카트 라인에 대한 품목 수가 증가할 때 전체 납품 날짜가 변경될 수 있음을 인식할 수 있습니다. 각 운송 위치에 요청된 수량이 모두 포함되어 있지 않거나 가능한 날짜가 다를 수 있으므로 날짜가 변경될 수 있습니다.

판매자는 각 장바구니 라인의 예상 배송 날짜를 표시하는 것이 좋습니다. 그런 다음 구매자는 개별 장바구니 라인을 비교하여 납품 승인 기준을 충족하는 품목을 판별할 수 있습니다. 일부 판매자는 구매자가 처음부터 원하는 것을 정확하게 알고 있다는 가정 하에 모든 장바구니 라인을 예상에 포함시킬 수 있습니다. 이 유스 케이스는 소형 카탈로그가 있고 기본적으로 대표 항목 또는 제한된 상품 선택사항을 제공하는 판매자에게 적합합니다.

장바구니 예상의 경우, 판매자는 상품 정보 페이지에 표시할 수 있는 것과 유사한 정보를 표시하도록 선택할 수 있습니다. 이 정보에는 운송 속도 및 연관된 가장 빠른 운송 날짜와 근처 상점에서 항목을 픽업할 수 있는 가장 빠른 날짜가 포함될 수 있습니다.

이 이미지는 사용 가능한 재고를 초과하는 요청이 있는 장바구니 페이지의 예를 표시합니다.

예상 전달 정보를 얻으려면 Calculate shipment assignments API를 사용하십시오. Calculate shipment assignments API는 가장 빠른 납품 예상을 제공하며 카트 라인 품목에 대해 요청된 전체 수량을 설명합니다. 또한 API는 네트워크에서 이행할 수 없는 결품오더 또는 수량에 대한 정보를 리턴합니다. 이러한 이유로 판매자는 수량이 완료되었는지 여부를 사전에 확인하고 구매자에게 이월 주문 금액을 보고해야 합니다. 이 통신은 구매자가 주문 캡처 단계로 이동하기 전에 이행할 수 없는 수량을 인식하도록 합니다.

이 추정은 Calculate item delivery date API 및 Get node availability by dates API의 조합을 사용하여 파생될 수도 있습니다. 예상 배송 날짜는 보고된 가장 빠른 배송 날짜를 충족하는 이행하는 출하노드도 제공합니다. 이 정보를 사용하여 판매자는 Get node availability by dates API를 사용하여 대상 선적 노드에서 사용 가능한 수량을 식별할 수 있습니다. 아이템의 재고 임계값을 기반으로 판매자는 구매자가 더 빨리 구매하도록 하기 위해 아이템에 제한된 가용성만 있음을 나타내는 간단한 메시지를 표시할 수 있습니다.

주문결제

구매자가 장바구니의 항목 목록을 완료한 후 장바구니를 주문 시작 단계로 전달할 수 있습니다. 주문 시작 시 구매자는 복수 장바구니 라인 및 항목 수량으로 구성된 장바구니의 최종 검토를 수행합니다. 구매자가 항목을 구매하도록 확약될 수 있으므로 판매자는 전체 장바구니에 대한 운송 예상을 제공해야 합니다. 이 납품 예상은 구매자가 항목에 대한 전체 납품 날짜를 알고 있는지 확인합니다.

장바구니 페이지와 주문 시작 페이지 사이의 차이점은 장바구니 페이지에 이행 예상을 얻기 위해 함께 고려되는 모든 장바구니 라인이 포함되어 있다는 점입니다. 여러 개의 카트 라인과 여러 개의 수량이 함께 고려되는 경우 가용성이 낮을 때 카트에 분할 납품이 필요할 수 있습니다.

주문 시작 페이지에서 구매자는 원하는 운송 속도, 운송 방법 및 서비스 센터 환경 설정을 선택할 수 있어야 합니다. 판매자가 장바구니 항목 및 수량에 대한 정확한 배송 예상을 제공하여 구매자에게 확약을 제공하면 쇼핑 경험이 더욱 향상됩니다. 서비스 센터 환경 설정은 판매자가 사전 정의하거나 구매자에 대한 옵션으로 제공할 수 있습니다. 서비스 센터 환경 설정은 구매자가 전달된 항목 (예: 함께 전달되거나 사용 가능한 즉시 전달되는 모든 항목) 을 수신하는 방법을 표시합니다. 가장 빠른 배송은 아이템이 사용 가능하게 되는 즉시 쉽먼트가 선적 노드에서 나가는 것을 의미합니다. 배송은 모든 카트 품목이 가능한 동일한 가장 빠른 배송 날짜에 도착하도록 스케줄링하는 것을 의미합니다.

비용 기반 약속을 통해 쇼핑 경험이 더욱 향상됩니다. 이제 판매자는 정확한 배송 견적을 제공할 수 있을 뿐만 아니라 가장 낮은 전체 서비스 비용으로 주문을 처리할 수 있습니다. 쇼핑객은 비용 최적화 적용를 주문 처리 옵션으로 선택할 수 있습니다. 구매자가 이 옵션을 선택하면 판매자는 전체 서비스 비용을 최소화하기 위해 구매별 배송 할당을 계산하여 카트 품목에 대한 배송을 약속합니다. 쇼핑객이 비용 최적화 적용 옵션을 선택하면 비용을 사용하여 결제 할당 계산 API가 카트의 배송 날짜를 도출할 때 최소 비용 대비 서비스 고려 사항을 고려합니다. 비용 기반 유망성에 대한 자세한 내용은 ' 시나리오: 사전 구매 배송 할당을 계산하고 서비스 비용 최소화하기' 을 참조하세요.

Calculate shipment assignments API는 카트의 가장 빠른 배송 날짜를 도출할 때 이러한 모든 고려 사항을 고려합니다.

장바구니 페이지와 유사하게, 판매자는 구매자가 수량미달을 인식할 수 있도록 주문 시작 주기의 초기에 Calculate shipment assignments API가 보고한 모든 이월 주문 수량을 캡처해야 합니다. 이 통신은 부정적인 이행 경험을 최소화할 수 있습니다.

이 이미지는 쉽먼트와 픽업 사이의 배송방법을 기반으로 배송 날짜 및 라인 구분이 있는 선적 그룹을 표시하는 체크아웃 페이지를 표시합니다.

Calculate shipment assignments API는 구매자가 필요로 하는 주요 정보를 지원하기 위해 다음 정보를 반환합니다.

카트 또는 카트 라인의 품목은 여러 배송으로 분할될 가능성이 높으므로 Calculate shipment assignments API 응답에는 가장 빠른 배송 날짜와 가장 최근 배송 날짜가 모두 포함됩니다. 이러한 이유로 판매자는 두 값을 모두 사용하거나 가장 빠른 배송 날짜만 사용할 수 있습니다. 후자의 시나리오에서는 납품 분류가 납품 세부사항 페이지에 표시됩니다.

픽업 옵션을 지원하려는 판매자는 카트를 두 개의 서로 다른 요청으로 분리해야 합니다. 하나는 쉽먼트 배송방법을 위한 것이고 다른 하나는 픽업 배송방법을 위한 것입니다. Calculate shipment assignments API는 동일한 요청에 픽업과 배송을 혼합하는 것을 지원하지 않습니다. 픽업의 특성은 마지막 마일 배송과 관련되지 않으므로 쉽먼트와 다릅니다. 또한 대부분의 판매자는 구매자가 선호하는 상점 위치를 기반으로 가능한 날짜를 공개합니다. 예를 들어, 구매자의 장바구니가 하나의 쉽먼트 라인과 하나의 픽업 라인으로 구성된 경우 판매자는 쉽먼트와 픽업 간에 장바구니를 명시적으로 분할해야 합니다. 이러한 방식으로 각 전달 방법에 대해 격리된 요청을 작성할 수 있습니다.

이 예에서 카트는 픽업 및 쉽먼트로 분할됩니다.

판매자가 SHIP1 카트 라인에 대해 Calculate shipment assignments API을 실행합니다. PICK1 카트 라인의 경우 판매자는 선택한 배송 노드에서 입고 가능 날짜를 검색하고 Get node availability by date API를 사용하여 정의된 스토어에 대한 재고 예약을 Create Reservation API로 요청해야 합니다. 이 단계에서 판매자는 Calculate shipment assignments API에서 제공한 대로 할당된 배송 노드에 대해 예약하여 '하드 예약'을 할 수 있습니다.

사용자가 지불을 제공하고 주문 시작 트랜잭션을 완료하면 판매자는 주문 시작 프로세스에서 Order Management System 또는 레코드 수요를 사용하여 주문을 작성할 수 있습니다. 이 예에서는 각 카트 라인 (SHIP1 및 PICK1) 에 대해 하나씩 두 개의 수요가 체크아웃 프로세스에서 작성됩니다. PICK1 시나리오의 경우 판매자는 수요 요청 시 구매자의 픽업 날짜를 선적 날짜로 사용해야 합니다. 자세한 정보는 쉽먼트 상세내역 검토를 참조하십시오.

화물출하문서 상세내역 검토

구매자가 주문 시작 플로우의 마지막 단계 (예: 지불 캡처) 에 들어가면 판매자가 장바구니 라인에 대한 운송 분리를 표시하는 것이 좋습니다. 이 쉽먼트 분리는 구매자가 배송될 것으로 예상되는 패키지 수를 이해하는 데 도움이 됩니다. 이행 환경 설정에 따라 둘 이상의 쉽먼트가 존재할 수 있습니다.

장바구니에 각각 다양한 수량을 갖는 여러 장바구니 라인이 있는 경우 구매자는 판매자로부터 여러 패키지를 받을 수 있습니다 (특히 다른 선적 노드에서 시작되는 경우). 쉽먼트 분리의 일부 예제 시나리오는 다음과 같습니다.

• 단일 쉽먼트의 단일 선적 노드에 의해 하나의 장바구니 라인이 이행됩니다.
• 수량이 여러 개인 하나의 카트 라인을 다른 선적 노드의 다른 패키지로 선적할 수 있습니다.
• 여러 장바구니 라인이 하나의 납품을 공유할 수 있습니다.
• 여러 개의 카트 라인이 여러 개의 납품을 공유하여 전체 요청 수량을 이행할 수 있습니다. 예를 들어, Line1 및 Line2 는 가용성 스케줄을 기반으로 Shipment1 및 Shipment2 를 공유할 수 있습니다.

이 예에서 선적 노드에는 제한된 가용성이 있으므로 Sterling Intelligent Promising 는 가장 빠른 배송 이행 환경 설정을 기반으로 장바구니를 두 개의 쉽먼트로 나누어 가용성을 최적화합니다. 각 쉽먼트는 쉽먼트에 지정된 수량을 나타냅니다.

구매자가 주문을 확인하기 전에 판매자는 주문 시작이 완료될 때까지 간단한 재고 예약을 작성해야 하므로 다른 프로세스에서 재고를 이용하지 않습니다. 또한 이전 이미지는 현재 체크아웃 화면이 만기되기 전의 시간을 표시합니다. 만기되면 판매자는 새 예약을 작성하여 예약을 갱신해야 합니다. 요청 항목에 수량미달이 있는 경우 구매자에게 수량을 더 이상 사용할 수 없음을 알립니다.

오더가 확정된 후 판매자에게는 오더를 캡처하기 위한 두 가지 옵션이 있습니다.

• 약정 날짜, 배송 노드 및 배송업체 서비스를 포함하여 Calculate shipment assignments API에서 제공하는 할당을 사용합니다.
• Order Management System 를 사용하고 구매자에게 제시된 대로 표시되도록 확약된 운송 날짜를 기록해 두십시오.

Calculate shipment assignments API에서 제공하는 할당을 사용하려면 판매자는 다음 단계를 모두 수행해야 합니다:

1. 할당된 수량 및 배송 노드 할당에 대해 수요 조정 API를 사용하여 재고 수요를 생성합니다.
2. 이 API를 사용하여 예약을 이용하고 예약 ID를 전달하십시오.
3. 지정된 선적 노드에서 운송업체 서비스를 사용하여 이행 요청을 처리합니다. 판매자는 외부 통합 솔루션 또는 Order Management System 를 사용하여 선적 노드 태스크 및 오퍼레이션을 관리할 수 있습니다.

사용되는 방법에 관계없이 배송 날짜가 구매자에게 제시되었으므로 이 날짜가 약정 날짜가 됩니다. 판매자는 고객의 불만족을 방지하기 위해 이 날짜를 위반하지 않도록 해야 합니다. 이 확약 날짜가 전달 벤치마크로 사용되는 동안 판매자는 이 데이터를 사용하여 시스템에 더 많은 수요가 도착할 때 다른 이행 최적화 계층을 수행할 수도 있습니다. 이러한 방식으로 판매자는 모든 노드에서 최적의 쉽먼트 밸런싱을 달성할 수 있습니다. 장바구니 라인이 선적 노드에 지정된 경우에도 판매자는 배송 날짜가 유지되는 경우 더 낮은 비용 옵션에 대한 선적 노드 및 운송서비스상품 지정을 변경할 수 있습니다.

확약 서비스에 대한 전제조건 체크리스트

Sterling Intelligent Promising 가 올바르게 작동하는지 확인하기 위해 IBM 은 테넌트 계정에 대해 다음 구성 데이터가 모두 있는지 확인할 것을 권장합니다.