운영상의 우수성

운영 우수성 요소에는 비즈니스 가치를 제공하고 지원 프로세스 및 절차를 지속적으로 개선하기 위한 시스템 운영 및 모니터링이 포함됩니다. 이 섹션은 Amazon Connect 워크로드의 운영 우수성과 관련된 설계 원칙, 모범 사례 및 질문으로 구성되어 있습니다.

Prepare

Amazon Connect 워크로드를 준비하려면 다음 영역을 고려하십시오.

AWS 계정

AWSOrganizations를 사용하면 개발, 스테이징 및 품질 보증 환경의 각 수준에 대해 여러AWS 계정을 설정할 수 있습니다. 이를 통해 워크로드가 성장하고 확장됨에 따라 환경을 중앙에서 관리할 수AWS 있습니다. 성장 중인 스타트업이든 대기업이든 관계없이 Organizations를 사용하면 청구서를 중앙에서 관리하고, 액세스, 규정 준수 및 보안을 제어하고,AWS 계정 전체에서 리소스를 공유할 수 있습니다. 이는 클라우드 채택 프레임워크와 함께AWS 서비스를 소비하기 위한 출발점입니다.

지역 선택

Amazon Connect 지역 선택은 데이터 거버넌스 요구 사항, 사용 사례, 각 지역에서 사용할 수 있는 서비스, 각 지역의 전화 요금, 상담원, 연락처 및 외부 전송 엔드포인트 지역과 관련된 지연 시간에 따라 달라집니다.

텔레포니

• 전화번호 포팅 대기 중인 라이브 시작 날짜보다 최대한 빨리 포팅 요청을 여십시오.

  중요한 워크로드를 위한 전화번호를 포팅할 때는 출시일 몇 개월 전에 클레임/포트 번호에 모든 요구 사항 및 사용 사례 정보를 포함시키십시오. 여기에는 실시간 전환 지원 요청, 전환 전/중/후 커뮤니케이션, 모니터링 및 사용 사례와 관련된 기타 모든 사항이 포함됩니다.

  번호 포팅에 대한 자세한 내용은 을 참조하십시오현재 전화번호를 Amazon Connect 커넥트로 포팅하세요.

• 배송사 다양성 미국에서는 미국 내 무료 전화번호용 Amazon Connect 전화 서비스를 사용해야 합니다. 그러면 추가 요금 없이 여러 공급업체에 걸쳐 무료 트래픽을 액티브-액티브 방식으로 라우팅할 수 있습니다. 인바운드 트래픽을 Amazon Connect 전화번호로 전달하는 경우 여러 전화 통신 공급업체에 중복 DID 또는 무료 전화 번호를 요청해야 합니다. 미국 이외의 지역에서 여러 개의 DID 또는 무료 전화 번호를 청구하거나 포팅하는 경우 복원력을 높이기 위해 해당 번호를 다양한 전화 통신 서비스 공급업체에 요청하거나 포팅하도록 요청해야 합니다.

• 국제 무료 및 동시성이 높은 DID 기존 무료 전국 서비스를 사용하여 인바운드 트래픽을 DID로 리디렉션하는 경우 여러 전화 통신 사업자의 DID 전화 번호를 요청해야 합니다. 이 구성에 대한 일반적인 권장 사항은 DID당 100개 세션이며AWS 솔루션스 아키텍트가 용량 계산 및 설정을 도와줄 수 있습니다.

• 테스트 모든 사용 사례 시나리오를 철저하게 테스트합니다. 가급적이면 상담원 및 고객과 동일하거나 유사한 환경을 사용하여 테스트하십시오. 다양한 인바운드 및 아웃바운드 시나리오를 통해 체감 품질, 발신자 ID 기능을 테스트하고 지연 시간을 측정하여 사용 사례에 적합한 범위 내에 속하는지 확인하세요. 대상 상담원 및 고객 환경과의 모든 편차를 측정하고 고려해야 합니다. 사용 사례 테스트 지침 및 기준을 비롯한 자세한 내용은 을 참조하십시오연락처 제어판 (CCP) 관련 문제 해결.

에이전트 워크스테이션

Amazon Connect 통화 제어판 (CCP) 에는 상담원 및 연락처에 대한 최상의 서비스 품질을 보장하기 위해 충족해야 하는 특정 네트워크 및 하드웨어 요구 사항이 있습니다.

• 네트워크를 CCP용으로 설정하고 에이전트 하드웨어가 최소 요구 사항을 충족하는지 확인하십시오.

• 에이전트와 동일한 네트워크 세그먼트에서 Amazon Connect Check Amazon 연결 도구를 사용해 네트워크 및 환경이 CCP를 사용하도록 올바르게 구성되었는지 확인하십시오.

• 상담원과 연락처가 지리적으로 멀리 떨어져 있어야 하는 사용 사례의 PSTN 지연 시간 계산

• 연락처 제어판 (CCP) 관련 문제 해결섹션을 검토하여 상담원과 수퍼바이저가 문제 발생 시 따를 수 있는 런북과 플레이북을 만드세요.

• 상담원 워크스테이션에 대한 모니터링을 설정하고 통화 품질 모니터링을 위한 파트너 솔루션을 고려해 보세요. 에이전트 워크스테이션을 모니터링하는 목적은 잠재적인 네트워크 및 리소스 경합의 원인을 식별하는 능력이어야 합니다. 예를 들어 Amazon Connect Connect에 대한 일반적인 에이전트의 소프트폰 네트워크 연결 경로를 생각해 보십시오.

  

  로컬 LAN/WAN, 경로 및 상담원 워크스테이션 수준에서 모니터링을 설정하지 않으면 음성 품질 문제가 상담원의 워크스테이션, 사설 LAN/WAN, ISP 또는 연락처 자체에서 발생하는지 판단하기가 어렵고 불가능한 경우가 많습니다.AWSAWS 로깅 및 경고 메커니즘을 사전에 설정하는 것은 근본 원인을 파악하고 음성 품질을 위한 환경을 최적화하는 데 매우 중요합니다.

기존 디렉터리 구성

이미 디렉터리를 사용하여 사용자를 관리하고 있는 경우 동일한AWS Directory Service 디렉터리를 사용하여 Amazon Connect Connect에서 사용자 계정을 관리할 수 있습니다. 이는 Amazon Connect 인스턴스를 생성할 때 결정하고 구성해야 합니다. 인스턴스를 생성한 후에는 선택한 자격 증명 옵션을 변경할 수 없습니다. 예를 들어, 인스턴스에 Single Sign On (SSO) 을 활성화하도록 선택한 디렉터리를 변경하려는 경우 인스턴스를 삭제하고 새 인스턴스를 만들 수 있습니다. 인스턴스를 삭제하면 해당 인스턴스에 대한 모든 구성 설정 및 지표 데이터가 손실됩니다.

Service Quotas

워크로드와 관련된 각 서비스의 기본 서비스 할당량과 Amazon Connect Connect의 기본 서비스 할당량을 검토하고 해당하는 경우 증가를 요청하십시오. Amazon Connect Connect에 대한 증가를 요청할 때는 변동에 대한 추가 패딩 없이 예상 값을 사용해야 합니다. 변동은 요청 시 자동으로 고려됩니다.

AWS엔터프라이즈 지원

AWS엔터프라이즈 Support 비즈니스 및/또는 미션 크리티컬 워크로드의 경우 권장됩니다AWS. Amazon Connect 서비스 수준 계약을 받으려면 엔터프라이즈 SupportAWS 솔루션스 아키텍트를 통한 Well-Architected 검토가 모두 필요합니다.

AWS잘 설계된 리뷰

Amazon Connect Connect로 마이그레이션하거나 구현하기 전에AWS Well-Architected 프레임워크인 운영 우수성을 사용하여 모범 사례를 따르십시오. 프레임워크는 운영 우수성, 보안, 신뢰성, 성능 효율성 및 비용 최적화의 5가지 요소를 중심으로 아키텍처를 평가하고 시간이 지남에 따라 확장되는 설계를 구현할 수 있는 일관된 접근방식을 제공합니다. 또한 의 비즈니스 및 미션 크리티컬 워크로드에AWS 엔터프라이즈 Support 사용하는 것이 좋습니다AWS. Amazon Connect 서비스 수준 계약을 체결하려면 엔터프라이즈 Support 및AWS 솔루션스 아키텍트의 Well-Architected 검토가 모두 필요합니다.

운영

Amazon Connect 워크로드를 운영하려면 다음 영역을 고려하십시오.

로깅 및 모니터링

를 사용하여 인스턴스 모니터링 CloudWatch 및 을 사용하여 Amazon Connect API 호출 로깅AWS CloudTrail를 참조하세요.

연락처 속성

Amazon Connect Connect를 사용하면 흐름 내에서 연락처 속성을 동적으로 설정하고 참조하여 연락처에 대한 동적이고 개인화된 경험을 만들고, 강력한 셀프 서비스 애플리케이션, 데이터 기반 IVR, 다른AWS 서비스와의 통합을 생성하고, 전화번호 관리를 간소화하고, 사용자 지정 실시간 및 기록 보고 및 분석을 수행할 수 있습니다. 다음은 복잡성을 줄이고 데이터 손실을 방지하며 담당자에게 일관된 경험 품질을 보장하기 위해 따를 수 있는 모범 사례 및 고려 사항입니다.

다음과 같은 고려 사항에 유의합니다.

• 데이터 크기 — 잘림을 방지하기 위해 연락처 속성 설정 블록에서 설정할 수 있는 연락처 속성의 크기 제한은 사용된 문자셋, 인코딩 및 언어에 따라 달라집니다. 이 데이터는 일반적으로 연락처에 대한 짧은 이야기를 재생하기에 충분하지만 이 제한을 초과하여 32KB를 초과하는 모든 속성을 잘라낼 수 있습니다.

• 데이터 민감도 — 설정, 쿼리 및 참조되는 속성이 민감하거나 규제 가이드라인에 해당하는지 확인하고 해당 데이터가 사용 사례에 맞게 적절하게 처리되고 있는지 확인하십시오.

• 데이터 지속성 — 연락처 속성 설정 블록을 사용하여 설정한 모든 속성은 연락처의 연락처 레코드에 포함되며 Streams API를 사용하는 모든 사용자 지정 에이전트 데스크톱에서 화면 팝업에 사용할 수 있습니다. 흐름 내에서 속성이 참조되고 플로우에 대한 로깅이 활성화될 때마다 속성의 이름과 값이 Amazon에 기록됩니다 CloudWatch.

모범 사례

• 사용량 모니터링 — 새 기능을 구현하고, 새 사업부를 등록하고, 기존 흐름을 반복하면서 연락처 검색에서 현재 속성 사용을 조회하고, 속성을 텍스트 편집기에 복사하고, 새 속성을 추가하고, 32KB 크기 제한을 초과하지 않는지 확인합니다. FirstName 및 LastName과 같은 가변 길이 필드를 고려하고 필드에 최대 공간이 사용된 경우에도 여전히 32KB 제한 미만인지 확인하십시오.

• 정리 — 데이터 지속성이 필요하지 않은 경우 동일한 이름과 빈 값으로 속성을 설정하여 데이터가 연락처 레코드에 저장되거나 Amazon Connect Streams API를 사용하는 에이전트에게 화면 팝업을 통해 전달되는 것을 방지하는 동시에 연락처 레코드에서 데이터가 사용되었을 바이트를 확보할 수 있습니다.

• 민감한 데이터 — Store 고객 입력 블록을 사용하여 연락처에서 민감한 DTMF 입력을 수집하고 봉투 암호화를 사용하여 원시 데이터와 이를 암호화하는 데 사용되는 데이터 키를 모두 보호합니다. 지속성이 필요한 별도의 데이터베이스에 민감한 데이터를 저장하고, 로깅 동작 설정 흐름 블록을 사용하여 중요한 정보가 참조될 때마다 로깅을 비활성화하고, 앞에서 설명한 연락처 속성 설정 블록 정리 방법을 사용하여 민감한 데이터를 제거, 정리 또는 난독화합니다. 자세한 정보는 Amazon Connect 커넥트에서의 규정 준수 검증을 참조하세요.

텔레포니

미국에서는 가능한 한 무료 전화번호를 사용하여 추가 경로 및 이동통신사 중복성을 위해 여러 배송사 간에 로드 밸런싱을 진행하세요. 또한 단일 통신사에서 관리해야 하는 DID 전화번호와 비교할 때 문제 해결 시간을 단축하는 데도 도움이 됩니다. DID를 사용하는 상황에서는 가능하면 여러 이동통신사의 번호 간에 로드 밸런싱을 수행하여 안정성을 높이십시오. 흐름의 모든 오류 경로를 적절하게 처리하고 에 있는 모범 사례, 요구 사항 및 권장 사항을 구현해야연락처 제어판 (CCP) 관련 문제 해결 합니다.

기존 전화 통신 공급업체의 전화번호를 Amazon Connect Connect로 착신 전환하려는 경우, 착신 전화를 다른 DID/무료 전화 번호로 변경하거나 착신 전화를 제거하는 프로세스를 운영 팀에서 정의하고 잘 이해했는지 확인하십시오. 프로덕션 준비 상태 평가, 전화 번호 포팅 및 전달 프로세스, 기존 전화 통신 사업자로부터 통화를 전송할 때 발생할 수 있는 오디오 문제 해결을 위한 Runbook 및 Playbook이 있는지 확인하세요. 또한 운영 팀이 따라 이러한 오디오 문제의 원인이 Amazon Connect Connect인지 기존 전화 통신 공급업체인지 확인할 수 있는 반복 가능한 프로세스가 필요합니다.

Amazon Connect API

Amazon Connect 스로틀링 할당량은 인스턴스가 아니라 계정별로 계산됩니다. Amazon Connect API를 사용하여 작업할 때는 다음 모범 사례 를 고려해야 합니다.

캐싱/큐잉 솔루션 구현

API 데이터 쿼리 오버헤드를 줄이고 스로틀링을 방지하려면 API 데이터에 관심이 있는 모든 엔드포인트에서 API를 호출하는 대신 Amazon DynamoDB와 같은 중간 데이터베이스를 사용하여 API 호출 결과를 저장할 수 있습니다. 예를 들어, 다음 다이어그램은 이 정보를 소비해야 하는 여러 소스에서 Amazon Connect 지표 API를 사용하는 것을 나타냅니다.

각각 고유한 폴링 요구 사항이 있는 별도의AWS Lambda 함수를 사용하는 대신 단일AWS Lambda 함수에서 Amazon DynamoDB에 모든 흥미로운 데이터를 기록하도록 할 수 있습니다. 다음 다이어그램에 표시된 것처럼 각 엔드포인트가 API로 직접 이동하여 데이터를 검색하도록 하는 대신 DynamoDB를 가리킵니다.

이 아키텍처를 사용하면 서비스 할당량 초과에 대한 걱정 없이 필요에 따라 폴링 간격을 변경하고 엔드포인트를 추가할 수 있으므로 데이터베이스 솔루션이 지원하는 동시 연결 수만큼 확장할 수 있습니다. Amazon Connect Connect에서 실시간 데이터 피드를 쿼리할 때도 이와 동일한 개념을 사용할 수 있습니다. 아웃바운드 API 호출과 같은 API 작업을 수행해야 하는 상황에서는 이와 동일한 개념을 Amazon Simple Queue Service와 함께 사용하여 SQS와AWS Lambda 함께 사용하여 API 요청을 대기열에 추가할 수 있습니다.

기하급수적 백오프 및 재시도 전략

API 제한 한도를 초과하는 상황이 발생할 수 있습니다. 이는 API 호출이 실패하고 반복적으로 재시도되거나 캐싱 또는 대기열 솔루션이 구현되지 않은 상태에서 여러 동시 엔드포인트에서 직접 수행될 때 발생할 수 있습니다. 서비스 할당량을 초과하여 다운스트림 프로세스에 영향을 주지 않으려면AWS Lambda 함수 내에서 기하급수적 백오프 및 재시도 전략을 캐싱 및 큐잉과 함께 사용하는 것을 고려해야 합니다.

변경 관리

Amazon Connect Connect로 워크로드를 이전하기 위한 두 가지 주요 동인은 유연성과 시장 출시 속도입니다. 민첩성을 희생하지 않으면서 운영 효율성을 보장하려면 다음 모범 사례 를 따르십시오.

• 모듈식 흐름: Amazon Connect Connect의 흐름은 모놀리식 대안에 비해 더 작고 용도에 맞게 구축된 구성 요소를 사용하면 유연성, 제어 및 관리 편의성이 뛰어난 최신 애플리케이션 구축과 유사합니다. Transfer to Flow block을 통해 모듈식 흐름을 하나의 end-to-end 경험에 결합하여 흐름을 작고 재사용할 수 있게 만들 수 있습니다. 이 접근 방식을 사용하면 변경을 구현하는 동안 위험을 줄이고, 전체 경험을 회귀 테스트하는 대신 작은 단일 변경 사항을 테스트할 수 있으며, 테스트 중에 흐름과 관련된 문제를 더 쉽게 식별하고 해결할 수 있습니다.

• 리포지토리: 변경 관리 프로세스의 일부로 연락처 플로우 Import/Export 사용하여 모든 플로우의 모든 버전을 선택한 리포지토리에 백업합니다.

• 백분율별 배포: 변경 관리 중에 발생할 수 있는 위험을 줄이고 연락처에 새로운 경험을 적용하려면 Distribution by% 블록을 사용하여 트래픽의 일부를 새 흐름으로 라우팅하고 나머지 트래픽은 원래 경험에 그대로 둘 수 있습니다.

• 결과 측정: 데이터 기반 의사 결정은 비즈니스에 의미 있는 변화를 성공적으로 추진하는 데 중요합니다. 변경 사항을 측정할 핵심 지표가 반드시 필요합니다. 모든 변화에 대비하여 성공을 측정하는 방법을 계획해야 합니다. 예를 들어, 연락처에 셀프 서비스 기능을 구현하려는 경우 셀프 서비스를 통해 업무량을 성공으로 간주할 것으로 예상하는 상담원의 비율은 몇 퍼센트입니까? 또는 성공을 결정하기 위해 측정하고 있는 다른 지표는 무엇입니까?

• 롤백: 수행된 변경과 관련된 이전 상태의 변경 사항을 취소할 수 있는 명확하고 잘 정의되고 이해하기 쉬운 프로세스가 있는지 확인하십시오. 예를 들어, 새 흐름 버전을 게시하는 경우 변경 지침에 이전 흐름 버전으로 롤백하는 방법에 대한 설명서를 포함해야 합니다.

라우팅 프로필

Amazon Connect Connect에서 우선 순위, 지연 및 오버플로 라우팅이 작동하는 방식을 이해하는 것은 상담원 생산성을 극대화하고, 문의 대기 시간을 줄이고, 연락처에 대한 최상의 경험 품질을 보장하는 데 매우 중요합니다.

Amazon Connect 커넥트에서의 라우팅

Amazon Connect Connect의 연락처 라우팅은 라우팅 프로필이라는 라우팅 구성 및 대기열 컬렉션을 통해 이루어집니다. 대기열은 상담원이 해당 대기열의 담당자에게 서비스를 제공하기 위해 보유해야 하는 기술 또는 숙련도와 같습니다. 라우팅 프로필은 연락처의 요구 사항에 맞출 수 있는 일련의 기술을 볼 수 있습니다.

흐름 내에서 추가 정보를 입력하라는 메시지를 표시할 수 있으며, 상담원에게 연락해야 하는 경우 흐름 구성을 사용하여 해당 정보를 적절한 대기열에 배치할 수 있습니다. 다음 예에서 예금, 당좌 예금 및 대출은 개별 대기열 또는 기술이고 세 가지 라우팅 프로파일은 고유한 기술 집합 또는 기술 그룹입니다.

각 상담원은 스킬셋에 따라 하나의 라우팅 프로필에만 배정되며, 스킬이 비슷한 여러 상담원은 동일한 라우팅 프로필을 공유할 수 있습니다.

각 전화번호 또는 채팅 엔드포인트는 하나의 흐름에 연결됩니다. 이 플로우는 고객에게 정보를 요청하는 것과 같은 로직을 실행하여 연락처의 요구 사항을 파악한 다음 최종적으로 해당 연락처를 적절한 대기열로 라우팅합니다. 다음 다이어그램은 라우팅 프로필, 대기열 및 흐름이 함께 작동하여 연락처에 서비스를 제공하는 방법을 보여줍니다.

다양한 대기열, 라우팅 프로필 및 라우팅 프로필에 대한 상담원 배정을 결정하는 방법을 설명하려면 다음 표를 참조하십시오.

맨 윗줄에는 자신의 기술 또는 대기열을 확인할 수 있습니다. 왼쪽 열에는 상담원 목록이 있고 가운데에는 각 상담원이 지원하는 스킬을 확인할 수 있습니다. 상담원 전체의 일반적인 기술 요구 사항별로 그룹화된 매트릭스를 정렬할 수 있습니다. 이렇게 하면 라우팅 프로필을 녹색 상자 (대기열 두 개로 구성) 에 표시된 것으로 식별하여 상담원을 배정할 수 있습니다. 이 연습을 통해 네 개의 라우팅 프로필을 식별하고 이에 따라 13명의 상담원을 배정했습니다.

위 표에 따르면 Savings 스킬이 필요한 담당자로부터 걸려오는 전화는 다음 다이어그램에 표시된 것처럼 세 개의 라우팅 프로필 1, 2, 4에 속한 세 그룹의 상담원이 처리할 수 있습니다.

우선 순위 및 지연

다양한 라우팅 프로파일의 우선 순위와 지연을 조합하여 유연한 라우팅 전략을 만들 수 있습니다.

위의 라우팅 프로파일 예제는 일련의 대기열과 각각의 우선 순위 및 지연을 보여줍니다. 숫자가 작을수록 우선 순위가 높아집니다. 우선 순위가 높은 모든 통화는 우선 순위가 낮은 통화가 처리되기 전에 처리되어야 합니다. 이는 결국 가중치를 기반으로 우선 순위가 낮은 통화를 처리하는 시스템과의 차이점입니다.

각 라우팅 프로필 내의 각 대기열에 지연을 추가할 수도 있습니다. 대기열로 들어오는 모든 통화는 지정된 대기열에 지정된 지연 시간 동안 보류됩니다. 상담원이 대기 중인 경우에도 해당 통화는 지연 기간 동안 보류됩니다. SLA (Service Level Agreement) 충족을 도와줄 상담원 그룹이 있지만 다른 작업이나 대기열에 배정된 상담원 그룹이 있는 상황에서 이 방법을 사용할 수 있습니다. 지정된 시간 내에 전화에 응답하지 않는 경우 해당 상담원은 지정된 대기열에서 전화를 받을 수 있는 자격이 부여됩니다. 예를 들어 다음 다이어그램을 고려해 보십시오.

이 다이어그램은 30초의 SLA를 보여줍니다. Savings 대기열로 전화가 걸려옵니다. 대기열에 대한 프로필의 지연 시간이 0으로 구성되어 있기 때문에 Savings 대기열은 “Savings” 라우팅 프로필에서 즉시 에이전트를 찾습니다. 시니어 에이전트는 15초 딜레이로 구성되어 있기 때문에 15초 동안 Savings 컨택을 받을 수 없습니다. 15초가 경과하면 상급 상담원이 해당 연락처를 사용할 수 있게 되며 Amazon Connect Connect는 두 라우팅 프로필 모두에서 가장 긴 예약 가능한 연락처를 찾습니다.

서비스 접근

Amazon Connect Connect에서 고객 경험을 설계할 때는 서비스를 받을 수 있는 경로를 계획하십시오. Amazon Connect Flows를 통해 이동하는 고객 경험에 영향을 미칠 수 있는 계획된 이벤트 및 계획되지 않은 이벤트가 많이 있습니다. 다음 샘플 고객 경험에서는 연락처에 일관된 품질 경험을 제공하기 위한 몇 가지 권장 점검 사항을 보여줍니다.

이 샘플 고객 경험은 휴일 및 업무 시간과 같은 계획된 이벤트는 물론, 업무 시간에 직원이 없는 상담원 등 계획되지 않은 이벤트를 고려합니다. 이 로직을 사용하면 악천후나 서비스 중단으로 인한 컨택 센터 폐쇄와 같은 긴급 상황도 고려할 수 있습니다. 다이어그램에 표시된 대로 다음 개념을 고려해 보십시오.

• 셀프 서비스: 일반적인 IVR에서는 모든 인사말 및 고지 사항 메시지 (예: 통화 녹음 알림) 를 미리 포함할 수 있으며, 이어서 셀프 서비스 옵션이 뒤따를 수 있습니다. 셀프 서비스는 컨택 센터의 비용 및 성능을 최적화하고 조직은 휴일, 업무 시간 또는 상담원의 가용성에 관계없이 연중무휴로 고객에게 서비스를 제공할 수 있습니다. 고객이 셀프 서비스를 이용할 수 없어 사람의 도움이 필요한 경우를 대비하여 항상 서비스를 받을 수 있는 경로를 포함시키십시오. 예를 들어 셀프 서비스용으로 Amazon Lex 봇을 사용하는 경우 대체 인텐트를 사용하여 상담원이 도움을 받을 수 있도록 대화를 에스컬레이션할 수 있습니다.

• 휴일: 대부분의 기업 고객은 회사 휴일을 보관하는 중앙 저장소를 사용합니다. AWS Lambda함수를 사용하여 해당 리포지토리에 데이터를 저장하여 고객에게 휴일 대접을 제공할 수 있습니다. 또한 회사 휴일을 각 휴일에 대한 사용자 지정 메시지와 함께 DynamoDB에 저장할 수도 있습니다. 예를 들어, 기업에서 12월 25일을 크리스마스로 기념하는 경우 휴일 안내 또는 Text to Speech 메시지를 보낼 수 있습니다. “현재 크리스마스는 휴무입니다. 정상 업무 시간이 재개되는 12월 26일에 다시 전화해 주십시오.”

  

• 업무 시간: 휴일이 확인되면 업무 시간을 확인할 수 있으며, 업무 시간이 아닐 경우 연락처에 대한 환경을 동적으로 변경할 수 있습니다. 업무 시간 중에 문의가 발생한 경우 고객의 통화 의도를 파악하고 컨택 센터의 특정 대기열에 매핑하여 올바른 상담원을 찾아갈 가능성을 높이고 상담원이 서비스를 받는 데 걸리는 시간을 줄일 수 있습니다. 고객이 아직 설명하지 못한 이유로 전화를 걸거나 예상하지 못한 방식으로 응답할 수 있으므로 기본값을 매핑하는 것이 좋습니다.

• 긴급 메시지: 고객의 통화 의도를 파악한 후에는 긴급 점검 처리를 실시하는 것이 좋습니다. 컨택 센터에 영향을 미치는 긴급 상황이 발생할 경우 DynamoDB와 같은 중개 데이터베이스에 긴급 True/False 플래그를 저장할 수 있습니다. 감독자와 관리자가 코드 없이 이 플래그를 동적으로 설정할 수 있도록 내부 전용 ANI 및 PIN 번호 확인을 기반으로 Amazon Connect 관리자를 인증하는 별도의 IVR을 구축할 수 있습니다. 긴급 상황이 발생하면 상사가 전화로 전용 회선으로 전화를 걸고 인증을 받은 후 악천후로 인한 컨택 센터 폐쇄나 컨택 센터의 물리적 위치에서의 ISP 가동 중단과 같은 시나리오에 대해 Emergency 플래그를 true로 설정할 수 있습니다.

• 긴급 메시지 API: 데이터베이스에서 Emergency 플래그를 true/false로 안전하게 설정하는AWS Lambda 기능을 백엔드에 포함하는AWS API 게이트웨이를 구축하는 것도 고려할 수 있습니다. 수퍼바이저는 웹을 통해 해당 API에 안전하게 액세스하여 재해 모드를 전환하거나 외부 이벤트에 대응하여 동적으로 전환할 수 있습니다. Amazon Connect 인스턴스에서 흐름을 통해 들어오는 모든 연락처는 해당 긴급 플래그를 확인하는AWS Lambda 데 사용되며, 재해 모드일 경우 동적으로 알림을 보내고 고객에게 서비스 경로를 제공할 수 있습니다. 이를 통해 비즈니스 연속성을 더욱 보장하고 이와 같은 상황이 고객에게 미치는 영향을 완화할 수 있습니다.

• 상담원 인력 확인: 흐름에서 대기열로 이동하기 전에 상담원 인력 배치를 확인하여 상담원이 연락처에 서비스를 제공할 수 있도록 로그인되어 있는지 확인할 수 있습니다. 예를 들어, 한 상담원이 5분 후에 연락이 닿을 수 있는 다른 연락처를 처리하느라 바쁘거나 시스템에 로그인한 사람이 전혀 없을 수 있습니다. 이러한 상황에서는 상담원이 대기 중일 때까지 고객을 기다리게 하는 것보다 색다른 고객 경험을 선호하게 될 것입니다.

• 서비스 라우팅: 통화를 대기열로 전환할 때 Amazon Connect 라우팅 프로필을 사용하여 대기 중인 콜백, 대기열 오버플로 또는 계층화된 라우팅을 제공하여 발신자에게 서비스 수준 요구 사항을 충족하는 일관되고 수준 높은 경험을 제공할 수 있습니다.

리소스

설명서

• DevOps 및AWS

• Amazon Connect 서비스 API 설명서

블로그

• Amazon Connect Connect를 사용하여 예상치 못한 연락처 급증을 처리하는 방법

동영상

• DevOps 아마존에서