고객에게 답하는 일과 고객의 상태를 바꾸는 일
공개 문서에 있는 이용 방법을 안내하는 것과 특정 주문의 환불을 확정하는 것은 고객에게 미치는 영향이 다릅니다. 같은 상담 화면에서도 ‘정책상 가능성이 있습니다’, ‘환불 심사를 요청했습니다’, ‘환불이 승인됐습니다’, ‘환불이 처리됐습니다’는 각각 다른 상태입니다. 화면에 그럴듯한 문장이 나오더라도 결제나 접수 시스템에 실제 작업이 생겼는지 별도로 확인합니다. AI 도구에 조회와 변경 권한을 분리하고 영향이 큰 작업을 실행 전 승인에 연결하는 방법은 OWASP의 AI Agent Security Cheat Sheet[1]에서 확인할 수 있습니다.
업무 영역을 정할 때 담당자가 고객 문제의 결과를 정의하는 것부터 시작합니다. 이용 방법을 몰랐던 고객은 안내를 따라 기능을 사용할 수 있어야 합니다. 연결 장애를 겪는 고객이 해결되지 않은 문제를 상담원에게 넘겨 달라고 하면 같은 설명을 처음부터 반복하지 않으면서 지원을 이어가야 합니다. 금전 처리를 요청했다면 고객에게 해당 요청이 어디까지 진행됐는지 사실에 맞는 안내가 필요합니다. 사용자 문제에서 성공을 정의하고 인간의 작업을 보조할 지점을 찾는 방법은 Google PAIR의 사용자 요구와 성공 정의[2]를 참고할 수 있습니다.
상담 유형에 따라 안내·승인·이관을 정합니다
아래 표는 온라인 서비스의 일반적인 상담을 구분한 예입니다. 실제 적용 시 상담 유형별 정책 소유자와 원천 시스템을 추가합니다. 고객 인증이 되더라도 그 고객의 모든 주문에 같은 조건이 적용되는지는 현재 상태와 승인 권한으로 판단합니다.
| 상담 유형 | AI에 맡길 범위 | 승인 또는 이관 조건 | 확인할 증거 |
|---|---|---|---|
| 공개 이용 방법·장애 안내 | 승인된 도움말과 현재 상태 안내 | 근거 문서가 없거나 서비스별 안내가 충돌하면 담당 큐로 보냄 | 문서 버전, 상태 조회 시각, 표시한 안내 |
| 인증된 고객의 주문 조회 | 자기 주문의 필요한 필드만 읽고 현재 상태를 설명 | 로그인이나 주문 소유권을 확인하지 못하면 인증 안내 | 고객·주문 연결 검증, 사용한 필드, 조회 결과 |
| 일반 정책 내 환불 검토 | 적용 가능한 조항과 부족한 증거를 찾아 제안 | 실행 권한이 있는 시스템 또는 담당자가 주문·정책·잔액 확인 | 주문 상태, 적용 버전, 계산 근거, 미확인 항목 |
| 예외 환불·보상 | 접수하고 사실 관계와 가능한 선택지를 정리 | 정책 재량, 사고 영향, 복수 사유는 지정 승인자에게 이관 | 예외 근거, 결정 권한, 고객의 요구와 증거 |
| 환불·쿠폰 지급 등 상태 변경 | 정책 엔진이나 사람에게 승인된 동일 작업의 제한된 실행 | 승인 만료, 상태 불명, 중복·충돌 또는 실행값 변경 시 보류 | 승인 값, 거래·작업 ID, 원천 시스템 처리 결과 |
| 반복 문의·고객의 사람 상담 요청 | 기존 케이스를 찾고 중요 내용을 요약해 넘김 | 큐를 찾지 못하거나 담당자가 인수하지 않으면 별도 처리 | 이전 케이스 연결, 큐 접수, 인수·다음 안내 시각 |
공개 안내에는 로그인 없이 접근할 수 있는 정보만 사용합니다. “이 지역의 문제가 해결됐나요?”라는 질문에 고객 이름과 이전 결제 내역을 함께 가져올 필요는 없습니다. 인증된 고객에게 특정 주문 상태를 알려 줄 때는 서버가 현재 계정과 주문 소유권을 확인하고 답변에 필요한 필드만 보냅니다. 상담 문장에 고객이 자기 이름을 적었다고 주문 접근을 허용할 수 없습니다. 다른 정보를 조회해 답변하지 않는 조건과, 주소·결제 수단의 불필요한 노출도 상담 QA에 포함합니다.
정책 내 제안은 환불 자격의 근거를 모으되 실제 확정에는 유효한 주문 상태와 정책 버전이 필요합니다. 구입 당시 조건이 적용되는지, 현재 정책의 예외가 있는지, 판매 채널이나 적용 지역의 기준이 함께 걸리는지 책임자가 먼저 규정합니다. 문서 두 개의 우선순위를 알 수 없는 건은 담당자가 확인해야 합니다. 남은 금액은 거래 시스템이 계산한 값과 대조합니다. 부분 취소 금액의 검산은 부분 취소와 환불 금액의 정합성에 정리돼 있습니다.
거래 이상에서 대응과 결제사 협의까지 — 증상별 확인 순서로 거래 상태를 확인하고 장애와 환불, 반복 문제를 같은 운영 절차로 처리합니다.
가상 연결 장애 상담을 처음부터 따라갑니다
가상의 온라인 연결 서비스에서 고객이 “요금은 냈는데 앱이 연결되지 않으니 바로 환불해 달라”고 말합니다. 고객 지원 문서에는 확인된 장애 공지, 일반 연결 안내, 판매 채널별 환불 문의 창구가 있다고 가정합니다. 연결 장애 자체가 무엇인지 판단할 수 없어도 사용자가 어떤 상태에서 문의했는지 확인할 수도 있습니다. 공개 도움말을 먼저 제공하되 고객이 이미 시도한 조치를 반복시키지 않고, 개인 상태를 조회할 필요가 있으면 인증 경로를 열어 줍니다.
인증 후에는 주문 결제 상태와 사용 개시 상태를 찾습니다. 앱이 ‘연결 실패’라고 표시한 경우도 첫 이용 이력이 존재하거나 확인 서비스의 응답이 없을 수 있습니다. 사용 이력이 조회되지 않았다는 이유만으로 “한 번도 사용하지 않았습니다”라고 결론 내리면 이후 승인 근거를 왜곡합니다. 조회 실패는 확인 불가로 기록합니다. 환불 정책 적용에 필요한 사실을 모두 얻지 못했다면 해당 단계까지의 증거를 케이스에 연결하고 담당자에게 보냅니다.
정책상 승인 가능한 사례에서 시스템이 환불 요청을 전송해도 결제 서비스가 결과를 반환하지 않을 수 있습니다. 상담 화면에는 당시 단계에 맞춰 “환불 요청 접수, 처리 상태 확인 중”과 같은 내용을 표시하고 완료를 두 번 통지하지 않습니다. 담당자는 같은 작업을 새로 생성하기 전에 기존 거래 ID로 상태를 대조합니다. 주문·제공과 결제 상태를 독립적으로 관리하는 방법은 결제와 주문 상태 정합성을 참고할 수도 있습니다.
예외 보상은 근거와 재량의 주체를 드러냅니다
예외 보상을 판단하려면 고객이 겪은 문제, 적용 가능한 정책, 이전 지급 내역, 같은 사고로 영향을 받은 주문을 검토할 수 있어야 합니다. 모델이 고객 불만을 잘 요약하더라도 정책 사각지대에서 자동으로 사과 쿠폰이나 현금을 약속하게 할 필요는 없습니다. 승인자가 보상 형태, 대상, 조건, 금액을 확정할 수 있도록 증거를 정리해 줍니다. 예외를 승인하지 않으면 승인 거절 여부와 별도로 고객에게 줄 다음 조치를 정합니다. 그 안내는 해당 계정의 실제 조건을 포함하되 처리되지 않은 작업을 확정 표시하지 않습니다.
다국어 상담에서는 고객이 사용하는 언어와 승인 문서에서 해석을 책임지는 언어가 다를 수 있습니다. 번역한 요약만으로 정책 용어의 범위나 시한을 바꾸지 않게 하고 원문과 고객 전달 문구를 함께 연결합니다. 접수일, 서비스 지역, 상담 운영시간의 시간대도 따로 기록합니다. 예를 들어 고객의 ‘어제’와 담당자가 보는 업무 날짜가 일치하지 않을 수 있습니다. 보상 자격이나 연락 시각이 날짜에 의존하면 승인 전에 기준 시간대와 시각을 대조합니다.
이관은 상담원이 이어받을 수 있을 때 성공입니다
상담 화면의 ‘담당자에게 연결합니다’라는 답이 나왔다고 작업 큐도 정상 접수된 것은 아닙니다. 고객에게 접수 ID와 다음 확인 경로를 알려 주려면 실제 케이스가 생성됐는지 확인합니다. 처음에는 케이스가 대기 중일 수 있고, 교대 이후 담당자가 인수하거나 추가 증거를 요청할 수도 있습니다. 대기, 인수, 고객 응답 대기, 최종 조치, 상태 불명 같은 구분을 운영과 화면이 공통으로 사용합니다. 오류 뒤에도 사용자가 진행할 수 있는 경로를 설계하는 근거는 Google PAIR의 Errors + Graceful Failure[3]를 참고할 수도 있습니다.
| 필수 인계 필드 | 예시와 사용 이유 |
|---|---|
| 케이스 ID와 접수 시각 | 기존 문의와 재접수를 연결하고 상태 변경의 순서를 대조 |
| 고객 요청과 현재 인증 상태 | 문제 해결·환불·직원 연결 중 실제 요청과 추가 인증 필요 여부 |
| 주문·거래 참조 | 권한 있는 화면에서 확인할 참조 ID와 확인 시각 |
| 적용 정책과 증거 | 정책 버전, 주문 상태, 이미 시도한 진단과 결과 |
| 알 수 없는 항목과 진행 중 작업 | 사용 기록 조회 실패, 환불 요청 전송 여부 등 실행·상태 확인에 필요한 정보 |
| 고객에게 전달한 문구와 다음 약속 | 어떤 상태를 말했는지, 다음 확인 채널과 확인 가능한 시각 |
| 인계 담당 큐와 인수 기록 | 담당자 또는 그룹, 배정 및 인수 시각, 기한 초과 시 책임자 |
고객이 상담 내역 전체를 설명해야 하는 상황을 줄일 만큼의 정보를 넘기고, 누구나 필요 없이 결제 수단이나 전체 고객 기록을 열 수 있게 복사할 필요는 없습니다. 인계 요약은 담당자의 결정이 필요한 사실을 두드러지게 보여 주고 원문과 확인 근거를 조회할 수 있어야 합니다. 고객의 언어와 희망 연락 수단도 확인하되, 민감한 인증 정보는 정책이 정한 경로로만 처리합니다.
상담원이 부재할 때는 실제 운영되는 접수 방식과 운영 시간을 안내합니다. 접수 큐가 실패하면 대체 폼이나 승인된 연락 경로로 이동할 수 있도록 알려 주고, 생성되지 않은 케이스의 번호를 만들어 내지 않습니다. 고객이 재접수했을 때 기존 케이스가 있다면 연결하고 주문이나 문제 유형이 다르면 별도 해결 항목으로 구분합니다. 같은 이슈의 중복 접수는 늘었는데 최초 응답 시간이 줄었다면, 자동 응답이 사람의 업무를 얼마나 줄였는지 다시 확인할 필요가 있습니다.
상담 기준을 검수할 사례와 분모
시험에서는 모델 답변과 시스템 결과를 함께 봅니다. 실제 운영의 개인정보나 결제 거래 대신 승인된 시험 계정과 테스트 시스템을 사용하면 다른 고객의 주문 조회, 같은 거래의 재요청, 환불 결과 통지 누락을 재현할 수도 있습니다. 평가 결과에서 텍스트 뉘앙스를 판단하는 부분과 주문·지급 상태를 코드나 원천 시스템으로 확인하는 부분을 구분하는 방법은 Anthropic의 에이전트 평가 안내[4]를 참고할 수도 있습니다.
| 시험 사례 | 기대 결과 |
|---|---|
| 고객이 다른 주문 ID를 제시 | 주문 상태와 고객 정보가 표시되지 않음 |
| 이력 조회가 실패 | ‘확인 불가’가 남고 정책 판단에 ‘사용 없음’으로 전환되지 않음 |
| 정책이 채널별로 다르고 판매 채널을 확정할 수 없음 | 임의 환불 확정 없이 자료 확인이나 사람 이관 |
| 환불 요청은 전송됐으나 응답이 끊김 | 지급 완료로 표시하지 않고 기존 거래 상태를 확인 |
| 상담 큐가 접수 요청을 거부 | 실제 접수 불가를 알리고 가능한 다음 경로 제공 |
| 교대 뒤 인계가 수락됨 | 담당자가 동일 케이스에서 증거와 고객에게 전달된 내용을 확인 |
운영 지표는 범위에 맞게 다르게 해석합니다. 최초 응답률은 접수한 문의 중 초기 답을 받은 비율입니다. 인수율은 사람에게 넘겨야 한다고 판정한 건 중 정해진 기간 안에 담당자가 인수한 비율입니다. 해결률은 조직이 미리 정한 기준에 따라 업무 결과가 확인된 문의를 접수 건과 비교합니다. 가상으로 문의 100건 중 90건이 답변을 받았으나 확인된 해결이 55건이었다면 최초 응답률은 90%, 확인된 해결률은 55%입니다. 관측 기간 안에 고객이 응답하지 않았거나 결제 결과를 확인하지 못한 건은 별도 상태로 남깁니다.
자동 응답 적용 범위를 늘릴 때는 조회 권한, 정책 충돌의 보류, 최종 상태의 일치, 사람 인계 정상 여부를 함께 판단합니다. 예외 조건에서 고객의 금전 상태가 잘못 바뀌었거나 담당자가 접수 정보를 찾을 수 없는 문제가 있다면 확인된 유형으로 범위를 제한하고 해당 경로를 수정합니다. 고객이 처음부터 사람과 상담을 원할 때의 경로도 호출 성공률과 별도로 검수합니다.
