계약은 늘었는데 도입 일정은 밀리는 B2B SaaS가 많습니다. 고객마다 들고 오는 엑셀의 열 이름, 입력 방식, 중복 기준이 다르기 때문입니다. 이때 “파일을 직접 올리게 할 수 있는가”만 묻기보다, 우리 서비스의 기본 항목에 고객 데이터를 무리 없이 맞출 수 있는지부터 봐야 합니다.
판단의 핵심은 두 가지입니다. 고객이 업로드 결과를 이해할 수 있는가, 오류가 나면 고객이 스스로 고쳐 다시 올릴 수 있는가입니다. 이 두 조건이 갖춰진 고객은 셀프서비스로 안내할 수 있고, 그렇지 않다면 먼저 데이터를 함께 정리하는 지원형 온보딩이 더 적합합니다.
열 이름보다 데이터의 뜻이 안정적인 고객은 셀프서비스에 맞는다
셀프서비스에 적합한 파일은 보기 좋게 정리된 파일만을 뜻하지 않습니다. 고객사마다 열 이름이 달라도, 그 열이 가리키는 업무상 의미와 입력 규칙이 서비스의 기본 항목과 같으면 충분히 처리할 수 있습니다. 예를 들어 고객명, 담당자 이메일, 계약 시작일이 각각 한 가지 뜻으로 쓰이고, 서비스 안에도 대응하는 항목이 있다면 고객이 직접 연결해 볼 수 있습니다.
이 경우 제품이 해야 할 일은 표준 양식만 강요하는 데 그치지 않습니다. 고객은 업로드 전에 자기 파일의 어느 열이 어떤 항목으로 들어가는지 확인할 수 있어야 합니다. 누락된 필수값, 날짜 형식 오류, 중복 가능성이 있는 행도 반영 전에 보여 주는 편이 좋습니다. 오류가 생겼을 때 전체 파일을 처음부터 만들게 하면 셀프서비스의 장점이 사라집니다. 오류 난 행을 따로 확인하고, 수정한 파일을 다시 올릴 수 있어야 고객이 다음 온보딩도 혼자 처리할 수 있습니다.
가령 영업 관리 서비스에 거래처 목록을 넣는 상황을 생각해 볼 수 있습니다. 회사명, 사업자번호, 담당자 이메일이 구분되어 있고 중복 판단 기준도 합의되어 있다면, 고객은 시험 반영 화면에서 신규 거래처와 변경 예정 항목을 확인한 뒤 직접 등록할 수 있습니다. 파일 형식이 조금 달라도 데이터의 뜻이 흔들리지 않는 경우입니다.
같은 ‘상태’ 열이 다른 뜻이라면 먼저 함께 정리해야 한다
지원형 온보딩은 고객의 파일을 운영팀이 대신 입력하는 서비스가 아닙니다. 데이터 의미를 확인하고, 어떤 변환을 허용할지 고객과 합의하는 과정입니다. 특히 같은 열 이름이 고객마다 다른 뜻으로 쓰이면 자동 연결이 그럴듯해 보여도 결과를 신뢰하기 어렵습니다.
예를 들어 한 고객의 ‘상태’ 열에는 계약 단계가 들어 있고, 다른 고객에게는 청구 여부나 담당자 메모가 섞여 있을 수 있습니다. 한 행에 여러 담당자가 쉼표로 들어가거나, 거래 중단 업체와 활성 고객이 구분되지 않는 경우도 마찬가지입니다. 이런 파일은 열을 서비스 항목에 억지로 맞추기보다, 어떤 정보를 나눌지와 무엇을 남길지를 먼저 결정해야 합니다.
지원형으로 분류할 신호는 다음 정도면 충분합니다.
- 기존 데이터에서 신규 등록과 기존 항목 갱신을 구분할 식별 기준이 없다.
- 중복 항목이 많지만 어느 쪽을 기준으로 남길지 정해지지 않았다.
- 잘못 반영하면 정산, 권한, 계약 이력처럼 이후 업무 판단에 영향을 준다.
- 고객 내부에서도 각 열의 의미를 설명하거나 확인할 담당자가 없다.
여기서 고객 확인은 빠질 수 없습니다. 운영팀이 파일을 정리해도 원본의 업무 의미를 가장 잘 아는 사람은 고객 쪽 담당자일 수 있습니다. 따라서 원본을 보존하고, 항목을 어떻게 대응했는지 보여 주고, 시험 반영 결과를 함께 검토한 뒤 실제 반영을 승인받는 흐름이 필요합니다. 지원형이 셀프서비스보다 자동으로 정확해지는 것은 아닙니다.
요구사항 단계에서는 업로드 기능보다 두 개의 진입로를 설계한다
새 고객을 모두 같은 화면으로 보내면 준비된 고객에게는 불필요한 지원 비용이 생기고, 준비되지 않은 고객에게는 해결하기 어려운 오류를 떠넘기게 됩니다. 요구사항 단계에서는 처음부터 두 경로를 두는 편이 낫습니다. 데이터 의미가 안정적인 고객은 안내형 업로드로 시작하고, 의미와 기준이 불분명한 고객은 샘플 파일 진단과 항목 정리로 시작하는 방식입니다.
두 경로를 나누는 기준은 고객 규모나 행 수가 아닙니다. 행이 적어도 계약 이력과 권한 정보가 얽혀 있으면 지원이 필요할 수 있습니다. 반대로 행이 많아도 항목 정의와 중복 기준이 명확하면 고객이 직접 처리할 수 있습니다. 고객에게 작은 표본 파일로 먼저 올려 보게 하는 방식은 이 판단을 빨리 돕습니다. 한 번의 시험에서 항목 연결, 오류 수정, 결과 확인이 가능하다면 셀프서비스 경로로 옮길 근거가 생깁니다.
제품팀은 모든 고객의 특수 양식을 처음부터 지원하려 하기보다, 지원 과정에서 반복되는 변환 규칙만 업로드 기능에 추가하는 편이 좋습니다. 한 고객을 위해 만든 예외 규칙이 다음 고객의 화면을 복잡하게 만들 수 있기 때문입니다. 먼저 고객의 샘플 파일을 받아 서비스 기본 항목과 맞춰 보고, 고객이 오류를 고쳐 재업로드할 수 있는지 확인해 보십시오. 그 결과가 셀프서비스의 범위와 지원형 온보딩의 범위를 나누는 가장 현실적인 출발점입니다.
