원본과 대상의 계약
폼 필드, 전송 키, CRM 필드와 보고서 분류를 연결합니다. 화면의 한국어 문구를 바꾸면 코드도 달라지는 구조인지 확인합니다. 이름·이메일 같은 고객 입력과 서비스 선택 코드를 다른 규칙으로 다뤄야 불필요한 개인정보 복사와 분류 오류를 줄일 수 있습니다.
가정한 매핑표
다음은 실제 CRM 제품의 규격이 아닌 논의용 예시입니다. 대상 시스템의 자료형과 복수 선택 지원을 확인해 구현합니다.
source service_code=analytics -> target service_category=DATA_SETUP
source billing_period=monthly -> target period_unit=MONTH
source selected_services=[seo,geo] -> approved multi-value mapping
source missing_service -> target review_required, not arbitrary default
source unknown_code -> validation issue with original safe reference
display_label -> presentation only, never silently replace stable code
빈값과 복수 선택
가정한 예로 서비스 두 개를 선택했는데 대상 필드가 단일 선택이면 하나를 버릴지 별도 항목으로 남길지 업무 판단이 필요합니다. 쉼표로 붙이면 자동으로 복수값이 된다고 추측하지 않습니다. 숫자 문자열·통화·기간과 줄바꿈도 대상의 실제 저장 형식으로 확인합니다.
시험 순서
- 허용한 각 코드의 대응값을 검수합니다.
- 빈값·미지원·복수 선택·특수문자를 시험합니다.
- 외부 원장에 저장된 실제 필드를 읽습니다.
- 보고서와 후속 배정이 같은 뜻을 사용하는지 봅니다.
연동 화면의 미리보기만 보고 실제 저장까지 완료됐다고 보지 않습니다. 공급자가 필드를 추가하거나 값을 바꾸면 매핑 버전과 미지원 처리의 영향을 확인합니다. 잘못된 매핑을 고친 뒤 과거 항목의 보정은 별도 범위로 기록합니다.
완료 기준
원본 선택과 최종 업무 분류가 일치하고 누락된 정보의 처리 이유를 설명할 수 있어야 합니다. 기본값이 오류를 가리지 않는지 관찰합니다. 단순 연결 성공률보다 잘못 배정된 요청과 확인 대기 항목을 함께 관리하고 담당자가 매핑표를 찾아 현재 기준을 이해할 수 있게 유지합니다.
자주 묻는 질문
- 필드 이름이 같으면 그대로 연결해도 되나요?
- 원본과 대상의 뜻·단위·허용값이 다를 수 있습니다. 금액의 기간이나 상태 정의까지 확인하고 실제 저장 결과를 검수해야 합니다.
- 알 수 없는 값은 기타로 넣으면 되나요?
- 기타가 업무상 의미 있는 분류인지 정해야 합니다. 잘못된 코드와 정당한 기타 요청을 섞으면 오류를 숨길 수 있어 미지원 값의 검토 상태를 구분합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.