판매자 입점 모듈이란?
판매자 또는 매입처의 입점 및 계약 방식, 판매자 정보(이름, 사업자번호, 가게명 등)를 관리하는 모듈을 말한다.
오픈마켓은 파트너사가 직접 자신이 판매할 상품을 등록하거나 주문, 배송을 관리하는 등 직접 이용 가능한 파트너 센터가 존재한다.
판매자 입점 모듈에서는 이러한 파트너 센터의 이용 방식을 정의하는 역할을 한다.
아래 이미지는 네이버 스마트스토어센터의 메인이다. 이런 식으로 상품관리, 판매관리, 정산관리, 문의/리뷰 관리, 톡톡 상담관리, 전시관리 등 다양한 기능을 제공해주는 것을 확인할 수 있다.
판매자 입점 모듈 기획 시 체크 리스트
그렇다면 판매자 입점 모듈 기획 시에 체크해야 할 항목은 무엇이 있는지 살펴보자.
1. 판매자와 일반 회원의 관계는 어떻게 설정할 것인가?
일반 회원 ID를 판매자 회원 ID로 전환 가능하게 할 것인지 혹은 일반 회원 ID와 판매자 회원 ID를 별개로 둘 것인지 결정해야 한다.
1) 일반 회원 ID를 판매자 회원 ID로 전환하는 경우
네이버 스마트스토어는 일반 회원 ID와 판매자 회원 ID가 동일하다.
즉, 회원 시스템을 공유하고, 판매자를 신청한 사람에게만 판매자의 권한을 부여하는 구조로 되어있다.
백단 시스템을 유추해본다면 회원 테이블에 '판매자 여부' 컬럼을 주어 체크하는 형태(Y/N or 1/0)로 들어가 있을 것이다.
2) 일반 회원 ID와 판매자 회원 ID를 별개로 두는 경우
롯데ON은 일반 회원 ID와 판매자 회원 ID를 별개로 두어 회원 시스템 따로, 판매자 시스템 따로 가져가는 구조로 되어있다.
백단 시스템을 유추해본다면 '회원 테이블', '판매자 테이블'이 따로 존재하여 필요할 때마다 각각 참조하는 구조일 것이다.
2. 판매자 계약의 종류와 자격에는 무엇이 있는가?
1) 판매자 계약의 종류
기본 계약 조건과 별도 계약 조건을 정하여 판매자에게 선택할 수 있도록 해야 한다.
- 기본 계약 : 중개, 위탁, 직매입
중개 판매자만, 위탁 판매자만, 직매입 판매자만 받을 것인지, 혹은 혼합된 형태의 판매자를 받을 것인지 결정해야 한다.
- 별도 계약 : 풀필먼트 부가 서비스 계약, 광고 계약 (기간 단위 별도)
오픈마켓 재량에 따른 선택 사항으로 우리가 판매자에게 어떤 서비스를 제공해줄 수 있는지 판단하여 계약 조건을 결정해야 한다.
2) 판매자 자격
사업자 번호를 가진 사업자, 사업자 번호가 없는 개인 중 어느 범위까지 판매자의 자격을 줄 것인지 결정해야 한다.
- 사업자
- 사업자 + 개인
- 개인
3. 판매자와 계약 간의 관계를 데이터적으로 어떻게 설정할 것인가?
A 판매자가 중개, 위탁, 직매입 세 가지 방식으로 계약했다고 가정해보자.
1) 하나의 판매자 ID로 세 가지 계약 방식을 모두 관리하는 경우
- 판매자 관점
하나의 판매자 ID로 파트너 센터에 로그인해서 세 가지 계약을 한꺼번에 관리하니까 편하다.
- 시스템 관점
위탁, 직매입은 CS에 대한 책임이 이커머스사에게 있고, 중개는 CS에 대한 책임이 판매자에게 있다. 따라서, CS를 처리할 때 복잡해진다.
또한, 중개, 위탁, 직매입 계약은 각각 수수료가 다르기 때문에 정산할 때 계약 단위로 정산해야 하므로 시스템이 복잡해진다.
- 구매자 관점
하나의 판매자 ID로 중개, 위탁, 직매입 상품을 업로드했기 때문에 고객은 상품을 보면서 같은 판매자라고 인식한다.
예를 들어, A 판매자가 '스킨'은 중개 상품, '로션'은 위탁 상품, '크림'은 직매입 상품으로 업로드했다고 가정하자.
이 경우, B 구매자가 스킨, 로션, 크림을 장바구니에 담고 결제를 하려고 하니 합배송을 해주는 것이 아니라 스킨 배송비 따로, 로션/크림
배송비 따로 부과되는 이상한 경험을 할 수 있다. B 구매자가 보기에는 세 상품 모두 A 판매자가 판매하는 상품인데 말이다.
이는 계약 조건마다 정산 방식이 다르기 때문이라 구매자는 배송비 손해를 볼 수밖에 없다.
- 해결 방안
1) 상품 등록 시에 '계약 방식'을 선택할 수 있도록 한다.
→ 고객은 여전히 프론트에서 같은 판매자로 보기 때문에 CS 문제가 발생한다.
2) 파트너 센터에 진입할 때, 계약 종류를 선택하여 진입할 수 있도록 한다.
→ 계약 방식마다 따로 관리되어 정산은 편리해지지만, 고객은 여전히 프론트에서 같은 판매자로 보기 때문에 CS 문제가 발생한다.
2) 세 개의 판매자 ID로 세 가지 계약 방식을 따로 관리하는 경우
- 판매자 관점
하나의 판매자 ID로 관리할 수 없어서 불편하다.
- 시스템 관점
각각의 ID로 계약을 구분하기 때문에 정산에 편리하다.
- 구매자 관점
합배송에 대한 오해를 풀 수 있다.
두 가지 방법에 장단점이 있으므로 우리 오픈마켓 판매자의 계약 형태를 참고하여 합리적인 방향으로 정책을 결정하면 된다.
4. 판매자 승인의 처리 방법과 온보딩 프로그램
1) 입점 신청 시, 판매자 승인 처리 방법
- 승인 시점 : 자동 승인 vs 수기 승인
입점 신청 시에 사업자 번호와 통신판매업자 등록증을 제출한다. 빨리 입점시켜 판매하고 싶은 경우 해당 서류가 문제없다면 자동 승인을 해주고, 철저한 검증을 거쳐 품질 좋은 상품만을 판매하고 싶은 경우에는 담당자 확인 후 수기 승인을 거치면 된다.
- ID 생성 시점 : 입점 승인 전 vs 입점 승인 후
아직 입점 승인이 나지는 않았지만, 입점 신청을 했다면 그 순간 판매자 ID를 생성하여 로그인을 해서 파트너 센터에 접속할 수 있도록 할 것인지, 입점 승인이 완료되어야만 ID를 생성하여 로그인이 가능하도록 할 것인지 선택해야 한다.
- 상품 등록 시점 : 입점 승인 전 vs 입점 승인 후
입점 승인 전에 ID가 생성되었다고 가정했을 때, 상품 등록을 아예 못하게 할 것인지 혹은 상품 등록은 가능하지만 나중에 승인이 나야 전시로 돌릴 수 있게 할 것인지 선택해야 한다.
2) 온보딩 프로그램
가이드 매뉴얼, 동영상 교육, 필수 교육을 포함할 것인지 결정해야 한다.
5. 판매자 마스터 ID에 서브 관리자 ID 추가 (개인정보 보호 이슈)
1) 판매자 마스터 ID 하위에 최대 몇 개의 서브 관리자 ID를 생성하게 할 것인가?
A 회사를 운영하는 직원이 총 10명이라고 가정해보자. 만약, 판매자 마스터 ID 하나만 있다면 10명이 같은 ID를 돌아가면서 접속해야 하는 불편함이 있을 것이다. ID를 돌려쓰게 되면 개인정보 보호 이슈도 있기 때문에 대부분 서브 관리자 ID를 생성한다. 이때, 최대 몇 개의 서브 관리자 ID를 생성하게 할지 결정해야 한다.
2) 서브 관리자 ID는 본인인증을 통해서 중복 관리를 할 것인가? (서브 ID가 개인 이메일인 경우 서브 ID가 겹칠 가능성)
A 회사 직원인 '홍길동'씨가 B 회사로 이직을 하게 되었다고 가정해보자. 홍길동씨는 A 회사에서 hong@gmail.com으로 서브 ID를 발급받았었는데, 이직을 하게 되면서 B 회사의 서브 ID를 hong@gmail.com로 발급받을 수 있게 할 것인지에 대한 결정이 필요하다.
이게 왜 중요하냐면, 홍길동씨의 서브 ID가 A 회사에서 주 업무 수단으로 이용된 계정이라고 가정해보자. 만약 본인 인증을 통해 중복을 허용하지 않게 정책을 세웠다면, 홍길동씨가 B 회사로 이직함과 동시에 A 회사의 계정은 삭제되어야 한다. 하지만, hong@gmail.com 계정은 아주 중요한 역할을 해오던 계정이기에 이직한다고 해서 바로 삭제할 수 없는 상황이 온다.
3) 대행사를 통한 운영을 할 경우 판매자 마스터 ID 하위에 서브 ID를 만들 것인가, 아니면 대행사 마스터 ID에 서브 ID를 만들 것인가?
만약 대행사에게 운영을 맡길 경우 판매자는 대행사에게 서브 ID를 지급해야 한다. 첫 번째 구조는 판매자 마스터 ID의 서브 ID를 지급하는 방법, 두 번째 구조는 대행사 마스터 ID를 따로 파서 거래처마다 ID를 따로 지급하는 방법이다.
6. 일반적으로 포함하는 항목
1) 기본 정보
거래처 기본 정보, 사업자번호, 사업자명, 주소지, CS 전화번호, 정산 계좌
2) 권한 설정 및 알림 설정
판매자 ID별로 부여되는 화면 권한 및 알림 설정 정보
3) 상품 공통 정보
배송 관련 정보 (가능 배송 유형, 배송비 코드 리스트, 출고지 / 반품지 주소 정보)
7. 퇴점 관련 프로세스
1) 퇴점 불가 정책 설정
- 미정산 금액에 대한 처리 필요
- 남아있는 클레임에 대한 처리 필요
2) 거래처 간 양수도 정책
양수도 정책이란, 한 거래처의 주요 정보 및 상품 데이터를 다른 거래처에 그대로 양도하는 것을 말한다. 소규모 거래처들은 쇼핑몰을 통째로
사고파는 경우가 많기 때문에 이러한 케이스에 대한 처리가 필요하다.
'이커머스 시스템과 정책' 카테고리의 다른 글
| 회원 모듈 : 포인트 (0) | 2022.01.06 |
|---|---|
| 회원 모듈 : 회원 약관 (0) | 2022.01.06 |
| MSA(마이크로 서비스 아키텍쳐)와 MA(모놀로식 아키텍쳐) (0) | 2022.01.03 |
| 카드 할인 : 카드 BIN 코드, 가맹점 번호, MID (0) | 2021.12.30 |
| 결제 시스템 : VAN, PG, 간편 결제 서비스 (7) | 2021.12.29 |
