사이트 운영에 필요한 서비스를 순서대로 도입하는 방법

사이트에 결제를 붙이고 고객 알림도 보내려는데, 여러 서비스가 한꺼번에 필요해 보일 수 있습니다. 이럴 때는 서비스 목록보다 지금 고객과 담당자에게 필요한 일을 먼저 살펴보면 도입 순서를 정하기 쉽습니다.

온라인 결제가 없어 판매를 시작하지 못한다면 결제 준비가 먼저입니다. 판매는 되고 있지만 배송 상태를 묻는 문의가 반복된다면 안내를 개선할 수 있습니다. 한편 현재 방식으로 누락 없이 처리하고 있다면 서둘러 바꾸지 않아도 됩니다. 고객이 주문이나 신청을 마칠 수 있도록 막힌 부분을 해결한 뒤, 담당자의 반복 작업을 줄이는 순서로 시작해 볼 수 있습니다.

필요한 업무에 맞는 서비스 찾기

SIR 운영서비스를 살펴볼 때 아래 표에서 가까운 상황을 찾으면 검토할 범위를 좁힐 수 있습니다.

표에서 배송 안내를 선택했더라도 곧바로 메시징 서비스를 신청할 필요는 없습니다. 문의의 원인이 안내 누락인지, 메시지를 보낼 수 없어서인지에 따라 할 일이 달라지기 때문입니다. 출고 전에 “언제 보내나요?”라는 질문이 반복되는데 상품 준비 기간을 안내하지 않은 경우를 가정해 보겠습니다. 이때는 출고 일정과 다음 안내 시점을 설명하는 일이 먼저입니다. 상품을 보낸 뒤의 알림만 추가하면 기다리는 동안의 궁금증은 그대로 남습니다.

반대로 출고한 주문의 조회 방법을 묻는 문의가 많다면 발송 알림과 연결 화면을 손볼 이유가 있습니다. 같은 배송 문의라도 어느 단계에서 발생하는지에 따라 문구만 고쳐도 되는지, 메시징 서비스를 연동해야 하는지 판단할 수 있습니다.

여러 일이 겹치면 먼저 해결할 범위를 좁힙니다

문제가 하나라면 선택이 비교적 쉽지만, 오픈을 준비할 때는 결제와 인증, 고객 안내를 함께 검토하게 됩니다. 이때 모든 서비스를 동시에 신청하기보다, 예정한 판매나 신청을 시작하는 데 꼭 필요한 것부터 가려보면 좋습니다. 온라인 결제가 필요한 판매 방식이라면 결제 준비가 오픈 일정에 영향을 줍니다. 본인 확인이 필요한 신청이라면 고객이 인증을 마친 뒤 신청까지 완료할 수 있도록 준비해야 합니다. 어느 서비스든 이름만 보고 필수라고 정할 수는 없습니다. 고객이 실제로 이용할 과정을 기준으로 판단하는 것입니다.

이미 판매 중인 사이트라면 반복 작업의 횟수뿐 아니라 그 작업을 빠뜨렸을 때 고객에게 생기는 불편도 살펴볼 만합니다. 배송 안내를 직접 보내는 일이 조금 번거로워도 빠짐없이 처리되고 있다면 당장 자동화하지 않을 수 있습니다. 반면 출고가 몰릴 때 안내가 자주 누락되고 고객이 같은 내용을 다시 묻는다면, 담당자가 기억해서 보내는 방식부터 바꿀 이유가 생깁니다. 단순히 일이 많다는 설명보다 언제 누락되는지까지 알아야 필요한 기능을 좁힐 수 있습니다.

앞의 배송 사례라면 첫 도입 범위를 ‘모든 고객 안내 자동화’가 아니라 ‘출고가 끝난 주문의 배송 조회 안내’로 잡을 수 있습니다. 상품 준비 중의 안내는 문구와 운영 방식부터 고치고, 출고 후 안내는 연동이 필요한지 따로 판단하는 식입니다. 이렇게 나누면 지금 필요한 작업과 나중에 추가할 작업이 분명해집니다. 다만 현재 접속 장애로 주문 자체가 불가능한 상황이라면, 알림 개선보다 서비스 복구가 먼저입니다.

서비스 신청과 사이트 연동을 함께 준비합니다

서비스를 골랐다면 사이트에서 실제로 이용할 수 있도록 연결하는 과정을 준비합니다. 주문 알림을 보내려면 사이트에 주문 상태가 기록되고 그 상태에 맞춰 메시지가 나가야 합니다. 본인인증은 고객이 인증을 마친 뒤 작성하던 신청을 계속할 수 있어야 합니다. 이런 연결이 아직 없다면 서비스 신청과 함께 사이트 설정이나 개발도 필요합니다.

필요한 작업은 사용 중인 제품에 따라서도 달라집니다. KG이니시스 인증은 제품별로 지원 범위가 다르므로 제품과 버전, 원하는 인증 방식을 함께 알려야 연결할 수 있는지 답변받을 수 있습니다.

서버 관리를 맡기는 경우에는 연결할 기능 대신 맡길 업무를 구분합니다. 디딤 클라우드·호스팅을 이용할 때는 서버 구성과 백업·매니지드 지원 범위를 각각 정해야 합니다. 서버 요금 외에 필요한 백업과 관리 지원까지 포함했는지 보아야 예상 비용을 알 수 있습니다.

필요한 작업을 상담할 때도 서비스 이름만 말하기보다 해결하려는 일을 함께 설명하면 좋습니다. 앞에서 살펴본 출고 후 배송 조회 문의라면 이렇게 요청할 수 있습니다.

출고 후에도 배송 조회 문의가 반복됩니다. 고객이 해당 주문의 상태를 직접 확인할 수 있게 안내하고 싶습니다.

여기에 사용 제품과 버전, 대략적인 처리 건수와 현재 안내 방식을 더하면 필요한 연동과 비용을 논의할 수 있습니다. 특히 누가 어느 시점에 주문 상태를 바꾸는지 설명하면 좋습니다. 담당자가 출고 상태를 입력한 뒤 알림이 나가야 하는데 그 입력 자체가 늦어진다면, 발송 기능을 연결하더라도 고객은 여전히 안내를 기다리게 되기 때문입니다.

상담 내용으로 도입 후 업무를 그려봅니다

상담에서 연동 가능한 범위를 확인했다면, 이를 적용한 뒤 담당자의 업무가 어떻게 바뀌는지 구체적으로 살펴볼 수 있습니다. 배송 사례라면 출고 상태 변경만으로 안내가 나가는지, 담당자가 발송 대상을 다시 골라야 하는지에 따라 남는 작업이 다릅니다. 발송되지 않은 주문을 어디에서 확인하고 누가 다시 안내할지도 알아야 도입 후 업무를 예상할 수 있습니다. 이런 기능이 모든 서비스에 있다는 뜻은 아닙니다. 상담할 때 어디까지 지원하는지 확인할 항목입니다.

가령 한 제안은 발송 기능 연결까지만 포함하고, 다른 제안은 주문 상태와의 연결 및 발송 결과 확인까지 포함한다고 가정해 보겠습니다. 두 제안의 금액만 비교하면 첫 번째가 유리해 보일 수 있지만, 담당자가 주문별로 다시 발송해야 한다면 줄이려던 일이 남을 수 있습니다. 반대로 처리 건수가 적고 현재 수동 안내에 문제가 없다면, 더 넓은 범위의 연동이 아직 필요하지 않을 수도 있습니다. 견적에서는 처음 설정하는 비용과 계속 사용하는 비용을 나눠 보고, 그 금액으로 어떤 작업까지 처리되는지 함께 비교하는 편이 좋습니다.

여기까지 확인했는데도 주문 상태를 어떻게 기록할지 정해지지 않았거나, 안내 문구만 바꿔도 문제가 해결될 가능성이 크다면 신청을 잠시 미뤄도 됩니다. 먼저 현재 방식에서 고칠 수 있는 부분을 바꿔보고 남는 문제를 좁히면, 이후 상담에서도 필요한 작업을 더 정확하게 설명할 수 있습니다.

도입 후 고객 안내가 어떻게 달라졌는지 살펴봅니다

연결 작업이 끝나면 고객이 안내를 받고 해당 주문의 배송 상태를 찾는 과정까지 직접 확인해 봅니다. 메시지가 발송됐다는 기록만으로 고객의 궁금증이 해결됐다고 보기는 어렵습니다. 연결된 화면에서 주문을 찾기 어렵거나 배송 정보가 아직 없다면, 안내 시점이나 연결 위치를 다시 조정할 필요가 있습니다.

실제 운영을 시작한 뒤에는 도입 전에 반복되던 배송 조회 문의와 안내 누락을 살펴보면 됩니다. 주문량이 달라질 수 있으므로 문의 건수만 비교하기보다 주문 수와 함께 보고, 준비 기간이나 배송 지연에 관한 문의는 구분하는 편이 좋습니다. 조회 방법을 묻는 문의는 줄었는데 출고 일정을 묻는 문의가 남았다면, 다음에 손볼 곳은 발송 기능보다 상품 준비 기간 안내일 수 있습니다. 담당자가 안내를 다시 보내는 일이 여전히 많다면 어떤 주문에서 누락되는지부터 살펴볼 수 있습니다.

운영서비스를 고를 때 처음부터 필요한 목록을 모두 완성할 필요는 없습니다. 지금 해결할 일을 하나 정하고, 서비스를 이용하면 그 일을 어디까지 처리할 수 있는지 확인하면 우선 도입할 기능이 분명해집니다. 앞의 사례에서는 ‘출고 후 고객이 배송 상태를 찾을 수 있게 하기’가 그 범위입니다. 이를 적용한 뒤에도 남는 문의와 작업을 보면, 다음 서비스를 더할지 기존 안내를 고칠지도 한결 구체적으로 판단할 수 있습니다.