운영 우수성 - Amazon Connect

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

운영 우수성

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

Prepare

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

AWS 계정

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

리전 선택

Amazon Connect 리전 선택은 데이터 거버넌스 요구 사항, 각 리전에서 사용 가능한 서비스, 각 리전의 전화 요금, 그리고 에이전트, 고객 응대 및 외부 전송 엔드포인트 위치와 관련된 지연 시간에 따라 달라집니다.

텔레포니

  • 전화 번호 포팅보류 중인 가동 날짜보다 가능한 한 빨리 포팅 요청을 여십시오.

    중요한 워크로드에 대한 전화번호를 포팅할 때는 가동 날짜 몇 개월 전에 청구/포트 번호에 모든 요구 사항 및 사용 사례 정보를 포함하세요. 여기에는 실시간 전환 지원 요청, 전환 전, 전환 중 및 전환 후의 커뮤니케이션, 모니터링 및 기타 사용 사례와 관련된 모든 내용이 포함됩니다.

    번호 포팅에 대한 자세한 내용은 단원을 참조하십시오.현재 전화 번호 포팅.

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

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

  • 테스트가급적이면 상담원 및 고객과 동일하거나 유사한 환경을 사용하여 모든 사용 사례 시나리오를 철저히 테스트하십시오. 경험 품질, 발신자 ID 기능에 대한 여러 인바운드 및 아웃바운드 시나리오를 테스트하고 지연 시간을 측정하여 사용 사례에 적합한 범위에 속하는지 확인하십시오. 대상 에이전트와 고객 환경과의 모든 차이를 측정하고 설명해야 합니다. 사용 사례 테스트 지침 및 기준을 포함한 자세한 정보는 단원을 참조하십시오.CCP (Contact Control Panel) 를 이용한 문제 해결.

에이전트 워크스테이션

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

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

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

  • 상담원과 연락처가 지리적으로 멀리 떨어진 위치에 있어야 하는 사용 사례의 PSTN 지연 시간을 계산해 보세요.

  • 복습CCP (Contact Control Panel) 를 이용한 문제 해결섹션에서 상담원과 수퍼바이저가 문제가 발생할 경우 따라야 할 런북과 플레이북을 만들 수 있습니다.

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

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

기존 디렉터리 구성

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

Service Quotas

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

AWSEnesis 지원

AWS엔터프라이즈 Support 다음과 같은 비즈니스 및/또는 미션 크리티컬 워크로드에 권장됩니다.AWS. 기업 Support 및 Well-Architected 검토 모두AWS솔루션스 아키텍트는 Amazon Connect 서비스 수준 계약 자격을 갖추어야 합니다.

AWS잘 설계된 리뷰

Amazon Connect Connect로 마이그레이션하거나 구현하기 전에 다음을 사용하여 모범 사례를 따르십시오.AWSWell-Architected 프레임워크, 운영 프레임워크는 운영 우수성, 성능, 성능, 성능 최적화 등 다섯 가지 기반을 토대로 아키텍처를 평가하고 설계 구현에 대한 일관적인 접근 방식을 제공합니다. 뿐만 아니라AWS의 비즈니스 및 미션 크리티컬 워크로드에 대한 엔터프라이즈 SupportAWS. 기업 Support 및 Well-Architected 검토 모두AWS솔루션스 아키텍트는 Amazon Connect 서비스 수준 계약 자격을 갖추어야 합니다.

작동

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

로깅 및 모니터링

를 사용해 인스턴스 모니터링 CloudWatch에서 Amazon Connect API 호출 로깅AWS CloudTrail 섹션을 참조하세요.

연락처 속성

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

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

  • 데이터 크기 - 잘리지 않도록 연락처 속성 설정 블록에서 설정할 수 있는 연락처 속성의 크기 제한은 사용된 문자 집합, 인코딩 및 언어에 따라 달라집니다. 일반적으로 이 데이터는 연락처의 단편 소설을 재생하기에 충분하지만 32KB를 초과하여 설정된 모든 속성을 잘라서 이 한도를 초과할 수 있습니다.

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

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

모범 사례

  • 사용량 모니터링 — 새 기능을 구현하고, 새 사업부를 온보딩하고, 기존 흐름을 반복할 때 연락처 검색에서 현재 특성 사용량을 조회하고, 속성을 텍스트 편집기에 복사하고, 새 특성을 추가하고, 32KB 크기 제한을 초과하지 않는지 확인합니다. FirstName 및 LastName과 같은 가변 길이 필드를 고려하여 필드에서 최대 공간을 사용하더라도 32KB 제한을 넘지 않도록 해야 합니다.

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

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

텔레포니

미국에서는 가능한 한 수신자 부담 전화번호를 사용하여 여러 배송사 간의 부하를 분산하여 추가 노선과 배송사 중복성을 확보하세요. 또한 단일 이동통신사에서 관리해야 하는 DID 전화번호에 비해 문제 해결 시간을 단축하는 데도 도움이 됩니다. DID를 사용하는 상황에서는 가능하면 여러 통신사의 번호 간에 로드 밸런싱을 수행하여 안정성을 높이십시오. 흐름의 모든 오류 경로를 적절하게 처리하고 에 있는 모범 사례, 요구 사항 및 권장 사항을 구현해야 합니다.CCP (Contact Control Panel) 를 이용한 문제 해결.

기존 전화 통신 공급자의 전화 번호를 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 모든 실시간 데이터 피드를 쿼리할 때도 이와 동일한 개념을 사용할 수 있습니다. 아웃바운드 API 호출과 같이 API 작업을 수행해야 하는 상황에서는 동일한 개념을 Amazon Simple Queue Service와 함께 사용하여 다음을 사용하여 API 요청을 대기열에 넣을 수 있습니다.AWS LambdaSQS 사용

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

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

변경 관리

Amazon Connect Connect로 워크로드를 이동하는 주요 요인 중 두 가지는 유연성과 시장 출시 속도입니다. 민첩성을 유지하면서 운영 우수성을 보장하려면 다음 모범 사례를 따르십시오.

  • 모듈식 흐름: Amazon Connect 흐름은 소형 특수 목적의 구성 요소가 모놀리식 대안에 비해 유연성, 제어 및 관리 용이성이 더 높은 최신 애플리케이션 구축과 유사합니다. 플로우를 작고 재사용할 수 있게 만들어 모듈식 플로우를 end-to-end 의 경험흐름으로 전송블록. 이 접근 방식을 사용하면 변경을 구현하는 동안 발생할 수 있는 위험을 줄이고, 전체 경험을 회귀 테스트하는 대신 작은 단일 변경 사항을 테스트할 수 있으며, 테스트 중에 흐름과 관련된 문제를 쉽게 식별하고 해결할 수 있습니다.

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

  • 비율별로 배포: 변경 관리 중에 발생하는 위험을 줄이고 연락처에 대한 새로운 경험을 실험해 보려면 다음을 사용할 수 있습니다.비율별로 배포트래픽의 일부를 새 흐름으로 라우팅하고 나머지 트래픽은 원래 경험에 남겨 두려면 차단합니다.

  • 측정 결과: 데이터 기반 의사 결정은 비즈니스에 의미 있는 변화를 성공적으로 이끌어내는 데 중요합니다. 변경 사항을 측정할 주요 지표를 갖는 것은 절대적으로 필요합니다. 모든 변경 사항에 대해 성공을 측정할 방법을 계획해야 합니다. 예를 들어, 연락처에 셀프 서비스 기능을 구현하는 경우, 셀프 서비스를 통해 워크로드를 성공으로 간주할 것으로 예상되는 연락처 중 몇 퍼센트가 좋다고 생각하십니까? 아니면 성공 여부를 판단하기 위해 측정하고 있는 다른 지표는 무엇입니까?

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

라우팅 프로필

Amazon Connect Connect에서 우선순위, 지연 및 오버플로 라우팅이 어떻게 작동하는지 이해하는 것은 상담원 생산성을 극대화하고, 문의 대기 시간을 줄이고, 통화 만족도를 극대화하는 데 매우 중요합니다.

Amazon Connect 커넥트에서의 라우팅

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

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

각 상담원은 각자의 기술력에 따라 하나의 라우팅 프로필에만 배정되며, 비슷한 기술을 가진 많은 상담원은 동일한 라우팅 프로필을 공유할 수 있습니다.

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

다양한 큐, 라우팅 프로필 및 라우팅 프로필에 대한 에이전트 할당을 결정하는 방법을 설명하려면 다음 표를 참조하십시오.

맨 위 줄에서 자신의 기술 또는 대기열을 식별했습니다. 왼쪽 열에는 상담원 목록이 있고 가운데 열에는 각 상담원이 지원하는 기술을 확인했습니다. 상담원 집단 전체에 걸쳐 공통 기술 요구 사항 집합별로 그룹화된 매트릭스를 정렬할 수 있습니다. 이렇게 하면 라우팅 프로필을 에이전트를 배정할 수 있는 녹색 상자 (두 개의 대기열로 구성) 에 표시된 프로필로 식별하는 데 도움이 됩니다. 이 연습을 통해 라우팅 프로필 4개를 식별하고 이에 따라 13개의 에이전트를 할당했습니다.

이전 표를 기반으로 Savings 기술이 필요한 연락처로부터 걸려오는 전화는 다음 다이어그램에 표시된 것처럼 세 개의 라우팅 프로파일 1, 2, 4의 세 그룹의 상담원이 처리할 수 있습니다.

우선 순위 및 지연

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

위의 라우팅 프로필 예제는 대기열 집합과 해당 우선 순위 및 지연을 보여 줍니다. 숫자가 작을수록 우선 순위가 높아집니다. 우선 순위가 높은 모든 통화는 우선 순위가 낮은 통화가 처리되기 전에 처리되어야 합니다. 이는 가중치 요소에 따라 최종적으로 더 낮은 우선순위의 호출을 처리하는 시스템과의 차이점입니다.

각 라우팅 프로필 내의 각 대기열에 지연을 추가할 수도 있습니다. 대기열로 들어오는 모든 통화는 지정된 대기열에 할당된 지정된 지연 기간 동안 보류됩니다. 상담원이 대기할 수 있는 경우에도 지연 기간 동안 통화가 보류됩니다. 이 방법은 서비스 수준 계약 (SLA) 을 충족하는 데 도움을 줄 준비가 되어 있지만 다른 작업 또는 대기열에 배정된 상담원 그룹이 있는 상황에서 사용할 수 있습니다. 지정된 기간 내에 통화가 응답되지 않으면 해당 상담원은 지정된 대기열에서 전화를 받을 수 있습니다. 예를 들어 다음 다이어그램을 고려해 보십시오.

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

서비스 경로

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

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

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

  • holidays: 많은 기업 고객은 회사 휴일을 보관하는 중앙 저장소를 보유하고 있습니다. 다음을 사용할 수 있습니다.AWS Lambda데이터를 해당 저장소에 저장하여 고객에게 휴일 대접을 제공하는 기능. 또한 각 휴일에 대한 사용자 지정 메시지와 함께 회사 휴일을 DynamoDB에 저장할 수도 있습니다. 예를 들어, 기업에서 12월 25일을 크리스마스로 맞이하는 경우 휴일 프롬프트 또는 Text to Speech 메시지가 표시될 수 있습니다. “현재 크리스마스 기간에는 휴무입니다. 정상 업무 시간이 재개되는 12월 26일에 다시 전화해 주세요.”

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

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

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

  • 에이전트 인력 확인: 플로우에서 대기열로 전환하기 전에 상담원 스태핑을 점검하여 상담원이 로그인하여 대화 상대에게 서비스를 제공하는지 확인할 수 있습니다. 예를 들어 상담원이 향후 5분 내에 사용 가능해질 수 있는 다른 연락처에 서비스를 제공하는 데 바쁘거나 시스템에 로그인한 사람이 전혀 없을 수 있습니다. 이러한 경우 상담원이 대기열에서 대기하도록 하는 것보다 다른 고객 경험을 선호할 수 있습니다.

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

리소스

설명서

블로그

백서

동영상