Air India의 Agentforce 확대 소식: 여러 요청이 담긴 고객 메일은 어떻게 처리할까

2026년 9월 15일 Salesforce는 Air India가 고객 서비스 전반으로 Agentforce 사용을 확대한다고 발표했습니다. 이번 소식에서 눈여겨볼 부분은 한 이메일에 여러 의도가 담겨 있을 때의 처리와, 상담 직원이 운영 지식을 찾는 방식입니다. “AI가 답변한다”는 표현을 넘어 실제 업무가 어떤 단계로 이어지는지 살펴보면 다른 업종에서도 참고할 지점을 찾을 수 있습니다.

공식 발표의 핵심과 숫자의 의미

Salesforce는 Air India의 환불 처리 소요 시간이 약 14일에서 4시간으로, 승객 이름 수정은 약 3일에서 30분으로 바뀌었다고 발표했습니다. 이 수치는 해당 기업 사례에 대한 발표값이며, 이 블로그의 독립 실측 결과나 다른 조직에서 보장되는 처리 시간이 아닙니다. 기존 환불 업무에서 더 넓은 서비스 업무로 활용 범위를 확대한다는 점이 이번 소식의 핵심입니다.

출처: https://www.salesforce.com/in/news/press-releases/2026/09/15/air-india-accelerates-customer-service-transformation-with-agentforce/

한 메일에 요청이 세 개라면

다음은 실제 승객 메일이 아닌 설명용 예시입니다. “예약자 이름 표기를 확인하고 싶습니다. 일정 변경 가능 여부도 알려 주세요. 관련 안내문을 받을 수 있을까요?” 이 문장에는 이름 확인, 일정 변경 조건 확인, 안내문 제공이라는 서로 다른 일이 들어 있습니다. 담당 업무와 필요한 자료가 다를 수 있으므로 하나의 답변 문장으로 묶기 전에 요청을 항목별로 나누는 과정이 필요합니다.

업무를 설계할 때는 고객이 원하는 결과와 시스템에서 수행할 행동을 따로 적어 보세요. “일정을 알고 싶다”는 조회 요청일 수 있고 “예약을 변경해 달라”는 실제 변경 요청일 수 있습니다. 표현이 비슷해 보여도 실행할 작업은 달라집니다. 확인이 필요한 부분은 고객이나 담당자에게 질문으로 돌려주는 경로를 두면 업무 흐름을 명확하게 설명할 수 있습니다.

요청 분해표를 먼저 만들어 보세요

요청	먼저 필요한 자료	결과를 확인할 기준
이름 표기 확인	예약 정보와 해당 절차	어떤 항목을 확인했는지
일정 조건 확인	현재 예약과 적용 조건	조회한 기준 시점이 있는지
안내문 제공	해당 업무의 공식 안내	실제 안내 내용과 맞는지

이 표는 Air India 내부 시스템을 재현한 것이 아닙니다. 공개 발표를 읽고 고객 서비스 흐름을 이해하기 위해 만든 일반적인 예시입니다. 회사별 처리 절차와 승인 조건은 각 조직에서 정해야 합니다. 독자가 쇼핑몰이나 예약 서비스를 운영한다면 자신의 요청 유형으로 행을 바꾸어 사용할 수 있습니다.

지식 검색과 실행을 나눠 보는 이유

공식 발표에는 상담 직원을 돕는 Knowledge Agent도 소개됩니다. 직원이 정책, 절차, 운임 규칙과 운영 안내에 접근하는 데 사용하는 방식입니다. 여기서 지식을 찾아 보여주는 일과 예약 기록을 변경하는 일은 서로 다른 역할입니다. 먼저 정확한 안내를 찾고, 해당 안내가 적용되는 조건을 확인하고, 필요한 절차로 연결하는 흐름을 그려보면 어떤 데이터와 권한이 필요한지 보입니다.

예를 들어 배송 안내를 제공하는 가상 서비스라면 배송 정책 문서, 개별 주문 상태, 상담 답변이 연결됩니다. 정책 문서의 일반 규칙과 특정 주문의 현재 상태를 같은 것으로 취급하지 않는 것이 중요합니다. 답변에는 “일반 정책”과 “이번 주문에서 확인된 상태”를 각각 적을 수 있습니다. 독자가 답변을 읽고 자신의 상황에 해당하는 부분을 찾기 쉬워집니다.

우리 팀에서 측정한다면 무엇을 볼까요

도입 검토용으로 가상의 문의 열 개를 준비해 보세요. 한 가지 요청만 있는 문의와 여러 요청이 섞인 문의를 함께 넣습니다. 각 문의의 기대 처리 항목을 먼저 작성하고, 결과에서 빠진 항목이 있는지 확인합니다. 측정표에는 최초 접수부터 최종 확인까지의 시간, 담당자 검토 시간, 추가 질문 횟수를 따로 적습니다. 이 항목은 자체 검토를 위한 예시이며 공식 발표 수치의 산출 방법을 설명하는 것은 아닙니다.

처리 속도와 함께 완료의 의미도 정해야 합니다. 초안이 생성된 시점, 고객에게 답변한 시점, 실제 요청 처리가 끝난 시점은 같지 않을 수 있습니다. 팀에서 쓰는 “완료”가 무엇인지 통일해야 전후 비교가 읽는 사람에게 의미 있게 전달됩니다.

자주 묻는 질문

발표된 처리 시간을 우리 서비스 목표로 바로 써도 되나요? 참고 사례로 볼 수 있지만, 목표는 자신의 업무 종류와 자료 연결 상태, 사람의 검토 과정에 맞춰 정하는 편이 좋습니다.

작은 팀도 참고할 수 있나요? 특정 제품 도입을 결정하지 않아도 요청 분해표와 완료 기준을 정리하는 방법은 활용할 수 있습니다.

오늘 해볼 일은 무엇인가요? 자주 받는 문의 하나를 골라 “조회할 정보, 확인할 조건, 실행할 일, 고객에게 알려줄 결과” 네 줄로 나누어 보세요. 이 구조를 만들면 고객 메일을 처리하는 과정이 훨씬 구체적으로 보입니다.