고객 온보딩 자동화

고객 온보딩 자동화는 합의된 고객 요구사항을 담당 책임과 의존 관계가 지정된 반복 가능한 설정 체크리스트로 정리합니다. 승인된 작업 라이브러리에서 시작해 제공된 요구사항과 연결하고, 체크리스트에 따라 누군가 실행하기 전에 누락된 입력을 검토합니다.

아래 예시는 사람이 승인할 온보딩 계획을 준비합니다. 출력은 담당이 지정된 체크리스트입니다. 계정 프로비저닝, 일정 예약, 환영 메시지 발송은 여기서 다루지 않습니다.

작성: Ai Flowi · 게시일 2026-10-10

구성 예시이며, 기록된 테스트가 아닙니다
카탈로그에 문서화되어 있으나 Ai Flowi가 실운영 환경에서 테스트하지 않았습니다

1. 합의된 범위와 요청된 범위 구분하기

승인된 범위, 고객이 제공한 요구사항, 현재 설정 상태를 수집합니다. 고객이 요청한 연동은 담당 팀이 포함 여부를 확인할 때까지 계획에서 요청으로 남겨야 합니다. 초안이 의도치 않게 작업을 약속하지 않도록 출력에서도 이 차이를 보존합니다.

작업 식별자, 적용 규칙, 필수 입력, 선행 작업, 담당 역할, 완료 근거가 포함된 작업 라이브러리를 만듭니다. 역할과 실명 담당자를 구분합니다. 모델은 승인된 역할을 선택할 수 있지만 담당자는 팀장이 정해야 합니다. 기한은 누군가 이를 수락한 뒤에야 약속이 됩니다.

2. 사용이 허가된 입력과 접근 권한 준비하기

작업 공간과 승인된 온보딩 작업 라이브러리를 준비합니다. 제공업체 계정과 API 키는 모델 자격 증명 참조 문서에 따라 설정합니다. 제공업체는 작업 선택 호출에 요금을 청구합니다. 첫 초안을 위해 사용이 허가된 요구사항 묶음을 Chat Input에 붙여 넣습니다. 범위 버전과 출처 식별자를 포함하되 자격 증명이나 비공개 접근 링크는 제외합니다.

라이브러리가 Knowledge Base에 있다면 초안 작성 전에 검색된 작업 식별자를 승인된 라이브러리와 비교합니다. 선택된 knowledge_base와 반환된 출처를 점검합니다. 검색 결과에서 필수 작업이 누락될 수 있으므로 출처의 관련성만으로 온보딩 체크리스트가 모든 필수 활동을 포함한다고 판단할 수는 없습니다.

체크리스트 승인과 자격 증명 준비 상태를 구분합니다. 대상 시스템의 접근 권한이 미해결인 상태에서도 팀은 작업 순서를 승인할 수 있습니다. 고객 설정 작업을 완료로 표시하지 말고, 그 접근 문제를 게시 인계 항목에 기록합니다.

3. 요구사항과 작업을 연결하는 묶음 만들기

Knowledge Base의 search_query를 구성해 승인된 제품과 고객 요구사항에 관련된 작업을 찾고, include_metadata를 활성화하여 출처 참조를 포함합니다. 작업 라이브러리에 적합하도록 top_k를 신중하게 정한 뒤 어떤 항목이 누락되었는지 점검합니다. 승인된 라이브러리의 공통 필수 작업은 별도로 포함하여, 검색이 필수 요구사항의 존재 여부를 결정하지 않게 합니다.

검색된 작업 기록을 온보딩 묶음으로 구성하려면 Parser 필드 참조 문서를 사용합니다.

가상 설정 요청에서 승인된 작업에 고객이 제공할 리소스 식별자가 필요하고 접근 권한 검토가 선행되어야 한다고 가정합니다. 요구사항 묶음에는 식별자가 있지만 완료된 접근 권한 검토는 없습니다. 의존 관계를 유지한 채 설정 작업을 포함하고, 접근 근거가 없어 진행이 막힌 상태로 표시합니다. 아직 시작할 수 없다는 이유로 제외하지 마세요. 검색 결과가 선행 조건 없이 설정 작업만 반환하면, 순서 초안을 작성하기 전에 라이브러리에서 그 선행 조건을 찾습니다. 이렇게 하면 불완전한 검색과 누락된 고객 정보를 구분할 수 있습니다.

첫 제안에서는 검토자가 이 묶음에 고객 요구사항을 합쳐 Chat Input에 붙여 넣을 수 있습니다. 이렇게 명시적으로 인계하면 호환되는 포트만으로 여러 문서가 결합되거나 의도한 순서가 보존된다고 주장할 필요가 없습니다.

4. 제약을 적용한 온보딩 체크리스트 생성하기

요구사항 묶음을 Chat Input의 message 포트에서 Structured Output 체크리스트 추출기의 input_value로 전달합니다. 해당 컴포넌트의 model 입력에는 Language Model의 model_output을 연결합니다. 입력 output_schema에는 작업 식별자, 요구사항 참조, 제안된 담당 역할, 선행 작업 식별자, 누락 입력, 완료 근거, 검토 상태를 정의합니다.

입력 system_prompt에 제공된 라이브러리에서만 작업을 선택하도록 설정합니다. 고객이 필요한 세부 정보를 제공하지 않았다면 누락 입력 항목을 작성하도록 요구합니다. 모델에 의존 관계를 유지하고 승인된 대응 작업이 없는 요구사항을 표시하도록 지시합니다. 부족한 부분을 메우려고 작업, 시스템 권한, 완료 날짜를 지어내서는 안 됩니다.

고객 온보딩 체크리스트 자동화에서는 준비된 작업과 진행이 막힌 작업을 구분해야 합니다. 선행 작업이 목록에 있다고 완료된 것은 아닙니다. 완료 근거가 확인될 때까지 후속 작업을 차단 상태로 유지하고, 고객 정보를 기다리는 작업과 내부 범위 결정을 기다리는 작업을 구분합니다.

5. 책임과 의존 관계에 따른 순서 검토하기

체크리스트 후보의 JSON을 input_value에 제공해 Chat Output에서 점검합니다. 작업 식별자를 라이브러리와 비교하고, 승인된 각 요구사항에 작업이나 기록된 미해결 항목이 있는지 확인하며, 의존 관계의 순환을 찾습니다. 책임자가 해당 범위의 충족 여부를 검토한 뒤 담당자를 배정하고 목표 날짜를 수락합니다.

검토된 체크리스트와 미해결 질문을 함께 유지합니다. 작업이 알 수 없는 접근 권한에 의존한다면 겉보기에 완성된 목록도 오해를 줄 수 있습니다. 문서가 만들어졌다는 이유만으로 작업을 완료로 표시하지 마세요. 완료에는 작업 라이브러리에서 정의한 근거가 필요합니다.

AI 고객 온보딩 챗봇은 추가 확인된 요구사항을 수집할 수 있지만, 그 답변도 이 체크리스트 검토를 거쳐야 합니다. 여기서 Chat Input으로 받는 입력과 Chat Output의 표시는 Playground 안에서 작동합니다. 고객 채널에 배포하려면 이 구성 밖에서 별도로 범위를 정한 작업이 필요합니다.

6. 승인된 문서를 별도로 준비하기

공통 문서 준비 및 실패 처리 절차를 사용합니다. 이 체크리스트에서는 승인된 작업 ID, 수락된 담당 배정, 의존 관계, 미해결 입력을 initial_text에 넣고, 승인된 범위 버전은 title에 명시합니다.

연결된 양식-문서 레시피는 검증된 양식 필드와 문서 생성에 대해 CR+LF를 LF로 변환한 뒤 42/42 통과 했다고 보고합니다. 이 결과에는 작업 검색, 의존 관계 선택, 온보딩 승인이 포함되지 않습니다.

적용 대상이 아닌 작업과 미해결 범위 결정 때문에 제외된 작업을 구분합니다. 예를 들어 고객 요구사항에 아직 승인되지 않은 서비스 옵션이 언급될 수 있습니다. 그 요구사항을 범위 확인 질문으로 보존하고, 옵션이 승인될 경우 적용할 승인된 작업을 식별합니다. 조건부 작업을 확정된 약속으로 배정하지 마세요. 검토 후 범위가 바뀌면 자유 형식 작업을 덧붙이는 대신 영향을 받는 적용 규칙과 의존 관계를 다시 살핍니다. 승인된 라이브러리는 계속 선택의 기준이 되며, 개정된 범위는 체크리스트가 바뀐 이유를 보여 줍니다.