AI FAQ 정리 프롬프트: 비슷한 질문을 합치고 다른 의도는 남기는 법

비슷한 단어보다 같은 답을 기준으로 묶습니다

“언제 보내나요?”와 “출고는 언제 되나요?”는 출고 시점이라는 같은 의도일 수 있습니다. 그러나 “금요일까지 받을 수 있나요?”는 도착 가능성에 관한 질문입니다. 세 문장에 배송이라는 단어가 있다고 하나로 합치면 출고 정책만 답하고 고객의 기한 문제는 해결하지 못할 수 있습니다.

질문을 합칠 때는 같은 조건에서 같은 답으로 해결되는지 확인합니다. 주문 제작 상품과 즉시 출고 상품은 질문 표현이 같아도 처리 기준이 다를 수 있습니다. 제품군이나 주문 상태 같은 조건이 답을 바꾸면 FAQ 안에서 분기하거나 별도 질문으로 둡니다. 질문 수를 줄이는 것 자체가 목표가 아닙니다.

문의 원문과 정책 자료를 따로 준비합니다

문의 원문은 고객이 어떻게 표현하는지 알려주고, 정책 자료는 무엇이라고 답할 수 있는지 알려줍니다. 둘을 구분하지 않으면 고객의 주장이나 추측을 상점 정책으로 받아들일 수 있습니다. 예를 들어 “다음 날 도착한다고 들었어요”라는 문의만으로 익일 배송을 약속해서는 안 됩니다.

가상 실습에서는 문의 ID와 상품 유형만 남깁니다. 이름, 주소, 주문번호처럼 FAQ 작성에 필요 없는 항목은 제거합니다. 정책은 담당자가 승인한 버전과 기준일을 붙입니다. 정책이 없는 질문은 답을 창작하지 말고 담당자 확인 목록에 넣어 실제 운영 기준을 정할 수 있게 합니다.

FAQ 통합을 위한 복사 프롬프트

첫 단계는 질문 묶음과 통합 이유를 확인하는 작업입니다. 다음 단계에서 승인된 정책으로만 답변 초안을 만듭니다. 통합 전후 질문 ID를 연결하면 어떤 고객 질문이 누락됐는지 검수하기 쉽습니다.

가상 온라인 소품점 문의를 FAQ 후보로 묶으세요. 같은 조건에서 같은 답으로 해결되는 질문만 통합합니다.
출력 열: 묶음 ID, 대표 질문, 포함 문의 ID, 공통 의도, 답을 바꾸는 조건, 통합하지 않은 유사 질문.
출고일과 도착일, 배송 가능 여부와 도착 보장을 구분하세요. 상품 유형이나 주문 상태가 다르면 표시합니다.
질문 묶음을 확인한 뒤 제공 정책만 이용해 답변 초안을 작성합니다. 정책이 없는 경우에는 내부 확인 질문으로 남기고 실제 FAQ 답처럼 쓰지 마세요.
문의 목록: [비식별 자료]
승인 정책: [확인된 자료]

대표 질문에는 실제 고객의 표현을 남깁니다

내부 직원이 쓰는 “물류 리드타임 안내”보다 “주문하면 언제 보내주나요?”가 고객에게 더 이해하기 쉬울 수 있습니다. 다만 대표 질문을 너무 넓게 쓰면 조건이 다른 문의가 한꺼번에 들어옵니다. “주문 제작 상품은 언제 출고되나요?”처럼 상품 유형이 답을 바꾼다면 제목에 포함하세요.

질문마다 답의 첫 문장에서 핵심을 말하고 다음 문장에서 예외와 확인 경로를 설명합니다. 아직 정해지지 않은 정책을 그럴듯하게 채우기보다 운영자가 확인할 사항을 적는 편이 낫습니다. 공개 FAQ에서는 실제 승인된 답만 남기고 내부 검토 메모와 고객 원문은 분리합니다.

누락과 잘못된 합침을 검수합니다

각 원문의 ID가 적어도 한 묶음에 들어갔는지 확인합니다. 두 의도가 있는 질문은 여러 묶음으로 분리할 수 있지만 같은 의도를 중복 집계하지 않도록 기준을 정합니다. “배송이 늦어 취소하고 싶다”는 배송 문의와 취소 요청이 함께 있으므로 단순 배송 FAQ 하나로 해결됐다고 보지 않습니다.

검수자는 대표 질문에 답을 읽은 뒤 원문 고객이 다음 행동을 알 수 있는지 확인합니다. FAQ를 읽고도 주문별 확인이 필요하다면 어떤 자료로 어디에 문의할지 실제 경로를 안내합니다. 개인정보를 공개 댓글에 적도록 유도하지 말고 상점이 승인한 문의 채널을 사용하세요.

질문을 합쳐도 원래 문의 횟수는 남깁니다

“언제 보내나요”가 12번, “출고일이 언제인가요”가 8번 들어왔다고 가정하면 대표 FAQ는 하나여도 연결된 문의는 20건일 수 있습니다. 대표 질문 수와 실제 문의 횟수를 혼동하지 마세요. 자주 묻는 질문의 우선 배치를 정할 때는 통합된 문의 수가 도움이 되지만 중복 수집된 같은 문의가 있는지도 먼저 확인해야 합니다.

한 고객이 같은 문제로 세 번 문의했다면 세 개의 독립 고객 의도로 볼 것인지, 해결되지 않은 한 사례로 볼 것인지 분석 목적에 따라 다릅니다. FAQ 제작용으로는 반복되는 표현과 해결되지 않은 지점을 함께 살펴볼 수 있습니다. AI에 문의 ID와 대화 묶음 ID를 제공할 수 있는 상황이라면 두 기준을 분리해 집계하도록 하세요. 개인정보는 제외하면서도 필요한 연결만 유지하면 질문의 빈도와 실제 불편을 더 신중하게 해석할 수 있습니다.

게시 후에는 조회수보다 해결 여부도 봅니다

많이 읽힌 FAQ라도 계속 같은 문의가 들어오면 답이 불명확하거나 찾기 어려운 위치에 있을 수 있습니다. 검색어, 클릭, 문의 재발을 함께 살펴 대표 질문의 표현과 배치를 조정합니다. 고객이 쓰는 말과 다른 내부 용어를 제목에 쓴 것이 원인일 수도 있습니다.

정책이 바뀌면 연결된 FAQ를 모두 찾아 갱신할 수 있도록 질문 묶음과 정책 항목의 연결을 보관합니다. 배송 정책 한 줄을 고쳤는데 여러 답변에 옛 기준이 남으면 혼란이 생깁니다. AI는 영향받는 후보를 찾는 데 활용하고, 실제 정책 해석과 게시 여부는 담당자가 최종 확인합니다.