소비자 구매와 거래처 발주를 구분하고, 상품·가격·주문·배송 정보를 운영자가 관리할 수 있는 쇼핑몰을 설계합니다.
유통·커머스 구축은 상품을 보여주는 화면보다 판매 단위와 주문 조건을 정리하는 일에서 시작합니다. 같은 상품도 낱개와 박스의 재고를 따로 관리하는지, 색상·규격 조합마다 가격이 다른지, 주문 후 공급처 확인이 필요한지에 따라 상품 구조가 달라집니다. 기존 상품표와 실제 주문서를 함께 보면 구매 화면에 필요한 선택 항목과 운영자가 처리해야 할 예외를 구체적으로 구분할 수 있습니다.
소비자 쇼핑몰과 거래처 발주 사이트를 함께 운영하더라도 모든 고객에게 같은 가격과 주문 절차를 적용할 필요는 없습니다. 기업 간 거래인 B2B에서는 회원 승인, 거래처별 품목, 최소 주문 단위와 견적 확인이 중요할 수 있습니다. 소비자 판매에서는 가격·배송·교환 안내가 구매 전에 명확해야 합니다. 두 방식을 한 사이트에 넣을 경우 공통 상품 데이터와 고객 유형별 판매 조건을 분리하는 설계가 필요합니다.
가상의 생활용품 도매사가 박스 단위 상품과 개별 주문 상품을 함께 취급한다고 가정하겠습니다. 승인된 거래처는 전용 가격으로 수량을 입력하지만 주문 가능 수량과 실제 출고 가능한 수량이 다를 수 있습니다. 이 경우 주문 접수 후 공급 확인을 거쳐 확정하도록 구성할 수 있습니다. 고객 화면에는 접수된 수량, 확정된 수량과 아직 확인 중인 품목을 나눠 보여주며 접수만으로 출고가 보장된다고 표현하지 않습니다.
일부 품목만 먼저 보내는 부분 출고가 필요하면 주문 하나에 배송 기록 여러 개가 연결됩니다. 단순히 주문 전체를 배송 완료로 바꾸는 기능으로는 남은 수량을 설명하기 어렵습니다. 이는 실제 구축 성과가 아닌 요구사항을 확인하기 위한 예시입니다. 사업자가 부분 출고를 하지 않는다면 해당 구조를 만들 필요가 없으므로 최근에 처리한 정상 주문과 예외 주문을 각각 검토해 필요한 상태만 선택합니다.
기존 판매 플랫폼으로 충분한지 자체 주문 시스템이 필요한지는 디자인 선호만으로 결정하지 않습니다. 거래처 가격, 견적 승인, 묶음 단위나 출고 규칙이 기존 도구에서 지원되는지 먼저 비교합니다. 결제대행 서비스인 PG를 연결하는 것과 취소·부분 환불·실패 주문을 처리하는 것은 서로 이어진 범위입니다. 결제 성공 화면만 구현하는 것이 아니라 결제 결과가 지연되거나 중복 전달될 때 운영자가 무엇을 확인할지도 정해야 합니다.
재고를 여러 판매 채널에서 사용한다면 어느 시스템의 값을 최종 기준으로 삼을지 합의합니다. 동기화는 시스템 사이에 변경 내용을 맞추는 과정이며, 연결했다고 언제나 같은 순간에 같은 수량이 표시되는 것은 아닙니다. 상품 수와 옵션 조합, 기존 데이터 정리, 거래처 권한, 배송 정책이 제작 범위에 영향을 줍니다. 모든 기능을 한 번에 요청하기보다 실제 주문을 완료하는 데 필요한 규칙과 향후 확장 항목을 나눠 견적을 확인할 수 있습니다.
공개 전에 판매자는 상품명·가격·옵션·배송 조건을 승인하고 제작자는 장바구니, 결제 결과, 주문 알림과 관리자 처리 흐름을 시험합니다. 테스트 주문을 실제 출고 대상으로 혼동하지 않도록 시험 환경과 운영 환경을 구분해야 합니다. 판매 중지된 상품을 담아 둔 장바구니, 품절 직전 주문, 취소 후 재고 처리처럼 정상 구매 외의 상황도 실제 판매 정책에 맞춰 확인합니다.
운영자는 품절과 가격 변경, 고객 문의와 출고 상태를 관리하고 기술 담당자는 결제 연결 오류와 화면·서버 문제를 다룹니다. 상품 설명을 수정하는 권한과 환불을 실행하는 권한은 같지 않을 수 있습니다. 외부 배송 서비스나 결제사의 정책이 바뀌면 누가 영향 범위를 확인하고 변경을 승인할지도 정합니다. 상품 등록을 대신해 주는 운영 지원과 시스템 유지보수는 포함 업무가 다르므로 별도의 목록으로 합의하는 편이 명확합니다.
구매자가 개인인지 승인된 거래처인지 먼저 구분하고, 가격·재고·배송 상태를 어느 시스템에서 관리할지 결정합니다.
작은 화면에서는 표를 좌우로 움직여 확인하세요.
| 구성 방식 | 적합한 상황 | 주요 구성 | 확인할 조건 |
|---|---|---|---|
| 일반 소비자 구매형 쇼핑몰 | 공개된 상품 가격으로 고객이 직접 주문·결제할 때 | 상품·옵션 탐색, 장바구니, 결제와 주문 내역 안내 | PG 이용 조건, 재고 차감 시점과 취소·반품 절차 확인 |
| 승인 거래처 전용 발주몰 | 거래처마다 공급가·주문 단위·결제 조건이 다를 때 | 거래처 승인, 공급가별 노출, 최소 수량과 발주 관리 | 가격 열람 권한과 거래처별 예외 조건의 관리 주체 확인 |
| 재고·배송 시스템 연계형 | 여러 판매 채널의 주문을 기존 유통 업무와 연결할 때 | 상품 코드 대응, 주문 전송, 재고·송장 상태 동기화 | 재고 원본 시스템과 중복 전송·반품 예외 처리 기준 확인 |
제품 소개와 생산 공정 안내, 예약과 회원 운영처럼 필요한 업무에 맞는 상세 안내를 선택하세요.
다음 항목은 상담 시 검토할 구성입니다. 모든 기능이 기본 포함되는 것은 아니며, 실제 운영 방식과 기존 시스템을 확인해 범위를 정합니다.
옵션·판매 단위·재고·배송 유형을 정리하고 탐색부터 장바구니까지 연결합니다.
B2B 회원 승인, 거래처별 가격 공개와 발주 상태를 소비자 구매 흐름과 분리합니다.
결제·배송·취소·반품 상태의 책임 시스템을 정하고 필요한 외부 연동을 설계합니다.
완성된 기획서가 없어도 됩니다. 현재 사용하는 자료와 운영 규칙을 기준으로 필요한 기능과 제외할 기능을 함께 구분합니다.
상품의 실제 이름·사양·판매 조건을 상세 페이지에 표시합니다. 가격과 재고 구조화 데이터는 실제 판매 데이터가 있을 때만 연결합니다.
PG 계약·심사와 외부 시스템 이용료는 개발 범위와 구분합니다. 재고를 여러 시스템이 동시에 변경하면 충돌 처리 기준이 필요합니다.
가능한 구조를 검토할 수 있습니다. 거래처 승인, 공급가 노출, 최소 주문 단위와 결제 조건을 분리해 설계합니다.
내보내기 형식과 필드 대응을 확인해야 합니다. 상품부터 시험 이관하고 주문 이력·회원 정보는 권한과 보관 기준을 정한 뒤 범위를 확정합니다.
택배사와 기존 시스템의 API 지원 여부에 따라 달라집니다. 자동 처리할 상태와 사람이 확인할 예외 상황을 먼저 나눕니다.
회원 유형별 가격 정책을 설계할 수 있습니다. 목록과 상세 화면뿐 아니라 검색 결과, 장바구니와 주문 확정 단계에도 같은 정책이 적용되어야 합니다. 도매 가격을 공개하지 않는 경우 자료 다운로드나 공유 링크의 노출 범위도 확인합니다.
온라인 주문을 운영자가 쓰는 발주 양식으로 내려받는 범위부터 검토할 수 있습니다. 품목 코드, 수량 단위와 주문 식별 번호를 맞추고, 내려받은 주문을 중복 처리하지 않을 기준을 정해야 합니다. 양방향 재고 연동과 파일 내보내기는 별도 기능입니다.
새 제작과 기존 사이트 개선, 외부 연동의 범위를 나눠 확인하겠습니다.