시나리오 및 배포 접근 방식 - Amazon Connect

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

시나리오 및 배포 접근 방식

Amazon Connect 셀프 서비스 구성 기능을 제공하고, 모든 규모에서 다양한 마이그레이션 및 통합 옵션을 통해 동적이고 개인적이며 자연스러운 고객 참여를 지원합니다. 이 섹션에서는 Amazon Connect Connect용 워크로드를 설계할 때 고려해야 할 다음 시나리오와 배포 접근 방식을 설명합니다.

  • 기존 컨택 센터

  • 인바운드

  • 아웃바운드

  • 하이브리드 컨택센터

  • 기존 컨택 센터 마이그레이션

  • 가상 데스크톱 인프라 (VDI)

기존 컨택 센터

기존 컨택 센터에는 여러 공급업체 및 데이터 센터 위치에 걸쳐 연락처에 서비스를 제공할 수 있는 상당한 전화 통신, 미디어, 네트워킹, 데이터베이스 및 컴퓨팅 인프라 공간이 필요합니다. 각 개별 솔루션 및 공급업체는 버전 관리, 호환성 및 라이선스 충돌을 해결하는 동시에 충족해야 하는 고유한 하드웨어, 소프트웨어, 네트워킹 및 아키텍처 요구 사항을 가지고 있습니다.

로컬 및 원격 에이전트 하드웨어 및 VPN 연결, TTS (Text-to-Speech), ACD (자동 통화 분배), IVR (대화형 음성 응답), 음성 오디오 및 데이터, 물리적 데스크폰, 음성 녹음, 음성 트랜스크립션, 채팅, 등에 대한 별도의 공급업체 및 인프라 요구 사항이 있는 것이 일반적입니다.보고, 데이터베이스, CTI (자동 음성 인식), 자동 음성 인식 (ASR), 자동 음성 인식 (ASR) 및 자연 언어 이해 (NLP). 다단계 개발, 품질 보증 및 테스트 환경을 고려할 때 컨택 센터 아키텍처 및 인프라는 더욱 복잡해집니다.

일반적인 Amazon Connect 배포는 버전 관리, 호환성, 라이선스, 콜 센터 전화 인프라 및 유지 관리와 관련된 많은 문제를 해결하거나 줄입니다. 몇 분 만에 새 위치에 인스턴스를 만들고 개별 비즈니스 목표에 맞게 구성 요소를 개별적으로 또는 parallel 마이그레이션할 수 있는 유연성을 제공합니다. IVR/ACD에 흐름을 사용하고, 지원되는 웹 브라우저를 통해 상담원의 소프트폰으로 음성 및 데이터를 전달하고, 기존 전화 번호를 포팅하고, 소프트폰 오디오를 기존 데스크 폰으로 리디렉션하고, ASR 및 NLP에 대한 흐름 내에서 기본적으로 Amazon Lex 봇을 호출하고, 채팅에 동일한 흐름을 사용할 수 있습니다.음성. Amazon Contact Lens를 사용하여 음성 전사를 자동으로 생성하고, 키워드 식별 및 감성 분석을 수행하고, 연락처를 분류할 수 있습니다. 에이전트 CTI 데이터 및 실시간 음성 스트리밍의 경우 Amazon Connect 에이전트 이벤트 스트림 및 Kinesis Video Streams 사용할 수 있습니다. 또한 추가 비용 없이 사용한 만큼만 비용을 지불하면서 다단계 개발, 품질 보증 및 테스트 환경을 만들 수 있습니다.

인바운드

인바운드는 센터 연락처가 시작한 커뮤니케이션 요청을 설명하는 데 사용되는 컨택 센터 용어입니다. 연락처는 Amazon Connect 인스턴스에 도달하여 인바운드 셀프 서비스를 이용하거나 음성 및 채팅을 비롯한 다양한 방식으로 실시간 상담원과 대화할 수 있습니다. 음성 연락처는 PSTN을 거쳐 인스턴스에서 요청한 전화번호를 통해 Amazon Connect 인스턴스 텔레포니 진입점으로 라우팅됩니다. Amazon Connect Connect로 직접 전화번호를 예약하거나, 기존 전화번호를 이식하거나, 음성 연락처를 Amazon Connect Connect로 전달할 수 있습니다. Amazon Connect 서비스가 지원되는 모든 지역에서 지역 및 무료 전화 번호를 제공할 수 있습니다.

Amazon Connect 인스턴스에서 요청하거나 해당 인스턴스로 포팅된 번호로 전화를 걸면 해당 호출 번호와 관련된 흐름이 호출됩니다. 코딩 지식이 필요 없이 구성할 수 있는 흐름 블록을 사용하여 흐름을 정의할 수 있습니다. 플로우는 연락처를 처리하고 라우팅하는 방법을 결정하며, 선택적으로 연락처에게 의사 결정을 라우팅하는 데 도움이 되는 추가 정보를 요청하고, 해당 속성을 연락처 세부 정보에 저장하고, 필요한 경우 모든 통화 세부 정보 및 기록을 수집하여 해당 연락처를 상담원에게 라우팅합니다.길을 따라. 흐름을 통해 다음을 호출할 수 있습니다.AWS Lambda고객 정보 조회, 기타 통화 기능AWSAmazon Pinpoint Pinpoint와 같은 서비스를 통해 SMS 문자 메시지를 보내고 기본 설정을 사용하는 서비스AWSNLU/NLP용 Amazon Lex 및 음성 통화의 실시간 스트리밍을 위한 Kinesis Video Streams 포함한 서비스 통합

인바운드 연락처가 상담원에게 연락해야 하는 경우 라우팅 구성에 따라 상담원이 상태를 Available로 변경하면 해당 연락처가 대기열에 추가되고 상담원에게 라우팅됩니다. 지원 가능한 상담원의 문의가 수동으로 수락되거나 자동 수락 구성을 통해 수락되면 Amazon Connect 해당 연락처를 상담원과 연결합니다.

채팅 세션에 대한 브라우저 또는 모바일 앱 요청에서 인바운드 문의가 오는 경우, 요청은 Amazon Connect 채팅 API를 호출하여 요청에 구성된 흐름을 호출하는 웹 서비스 또는 Amazon API Gateway 엔드포인트로 라우팅됩니다. 채팅과 음성에 동일한 플로우를 사용할 수 있으며, 여기서 플로우에 정의된 로직에 따라 경험이 동적으로 관리되고 라우팅됩니다.

아웃바운드

Amazon Connect Connect를 사용하면 프로그래밍 방식으로 로컬 및 해외 엔드포인트에 대한 아웃바운드 문의를 시도하고, 통화 간 상담원 설정 시간을 줄이고, 상담원 생산성을 높일 수 있습니다. 를 사용하여Amazon Connect 스트림API 및StartOutboundVoiceContact자체 아웃바운드 솔루션을 개발하거나 CRM 데이터와 연동되는 기존 파트너 통합을 활용하여 연락처에 대한 역동적이고 개인화된 경험을 만들고 상담원이 해당 연락처에 서비스를 제공하는 데 필요한 도구와 리소스를 제공할 수 있습니다.

아웃바운드 캠페인은 일반적으로 CRM에서 내보낸 연락처 데이터를 기반으로 하며 연락처 목록으로 구분됩니다. 이러한 연락처는 우선 순위가 지정되고 일정 기간 미리 보기 후에 시작할 수 있도록 에이전트에게 전달되거나, 흐름 로직에 따라 Amazon Connect Outbound API를 통해 프로그래밍 방식으로 연락하고 필요에 따라 에이전트에 연결합니다. 일반적인 아웃바운드 컨택 센터 사용 사례에는 사기 및 서비스 알림, 픽업, 약속 확인이 포함됩니다.

하이브리드

Amazon Connect Connect와 기존 고객 센터 기술 간에 연락처를 이전해야 하는 요구 사항이 있는 경우 하이브리드 모델 아키텍처를 사용하여 전송과 함께 연락처 데이터를 전달할 수 있습니다. 예를 들어, 기존 콜 센터 플랫폼의 영업 사업부는 Amazon Connect Connect로 마이그레이션된 서비스 사업부로 통화를 전환해야 할 수 있습니다. 하이브리드 아키텍처가 없으면 통화 세부 정보가 손실되며 해당 연락처가 정보를 반복해야 할 수 있습니다. 이로 인해 처리 시간이 늘어나고 동일한 용도의 연락처 호출이 다시 발생할 수 있습니다.

하이브리드 아키텍처에서는 예상 최대 동시 통화 수만큼의 전화번호를 요청해야 하며 Amazon Connect와 기존 콜 센터 플랫폼에서 모두 액세스할 수 있는 중간 상태 데이터베이스를 요청해야 합니다. 다른 플랫폼으로 이전해야 하는 경우 이러한 전화번호 중 하나를 고유 식별자로 사용하고, 이를 중개 데이터베이스에서 사용 중이라고 표시하고, 연락처 세부 정보를 입력하고, 연락처를 이전할 때 해당 번호를 ANI 또는 DNIS로 사용합니다. 다른 컨택 센터 플랫폼에서 연락처를 수신하면 중개 데이터베이스에서 사용한 고유한 ANI 또는 DNIS를 기반으로 연락처 세부 정보를 쿼리합니다. 하이브리드 아키텍처는 추가 비용 및 복잡성 때문에 일반적으로 중간 마이그레이션 단계로 사용됩니다.

IVR 전용

상담원이 기존 콜 센터 플랫폼에 남아 있는 동안 Amazon Connect Connect를 사용하여 연락처의 IVR 경험을 향상할 수 있습니다. 이 접근 방식을 사용하면 Amazon Connect 흐름을 사용하여 셀프 서비스 및 라우팅 로직을 구동하고, 필요한 경우 기존 콜 센터 플랫폼의 대상 상담원 또는 상담원 대기열로 통화를 전송할 수 있습니다.

이 다이어그램에서 연락처는 Amazon Connect 인스턴스에서 서비스를 요청받은 전화번호로 전화를 겁니다. 기존 컨택 센터 플랫폼의 상담원에게 양도해야 하는 경우AWS Lambda함수가 호출되어 사용 가능한 고유 전화번호를 쿼리하고 사용 중인 것으로 플래그를 지정하고 관련 연락처 세부 정보를 중개 데이터베이스에 기록합니다. 그런 다음 Lambda 함수에서 반환된 전화번호와 함께 해당 연락처가 기존 컨택 센터 플랫폼으로 전송됩니다. 그런 다음 기존 컨택 센터는 중개 데이터베이스에서 연락처 세부 정보를 쿼리하고, 그에 따라 라우팅하고, 중개 데이터베이스의 연락처 데이터를 재설정하여 전화번호를 다시 사용할 수 있도록 합니다.

에이전트 전용

이러한 접근 방식을 사용하면 기존 콜 센터 IVR이 연락처의 IVR 셀프 서비스 및 라우팅 로직을 구동하고, 필요한 경우 해당 통화를 Amazon Connect Connect로 전송하여 상담원 모집단으로 라우팅합니다.

이 다이어그램에서 연락처는 기존 컨택 센터 플랫폼에서 요청받은 전화번호로 전화를 겁니다. Amazon Connect 상담원에게 전송해야 하는 경우 기존 콜 센터 플랫폼은 사용 가능한 고유 전화번호를 쿼리하여 사용 중으로 플래그를 지정하고 관련 연락처 세부 정보를 중개 데이터베이스에 작성합니다. 그러면 기존 콜 센터의 쿼리에서 반환한 전화번호와 함께 해당 연락처가 Amazon Connect로 전송됩니다. 그러면 Amazon Connect 다음을 사용하여 중개 데이터베이스에서 연락처 세부 정보를 쿼리합니다.AWS Lambda, 적절하게 라우팅하고 중개 데이터베이스의 연락처 데이터를 재설정하여 전화 번호를 다시 사용할 수 있도록 합니다.

혼합

이 시나리오에서는 Amazon Connect Connect와 기존 콜센터 플랫폼에서 IVR 및 에이전트가 병렬로 작동하여 사이트, 상담원 그룹 또는 line-of-business 마이그레이션.

기존 컨택 센터 마이그레이션

새 워크로드 또는 기존 워크로드에 대해 Amazon Connect Connect를 평가할 때 고려할 수 있는 몇 가지 전략이 있습니다. Amazon Connect Connect와 기존 콜 센터 솔루션 간에 통화를 전송할 때 연락처 세부 정보를 포함해야 하는 상황의 경우 마이그레이션이 완료될 때까지 하이브리드 모델 아키텍처가 필요합니다. 이 섹션에서 설명하는 접근 방식을 통해 특정 사업부를 단계별로 이전하고, 교육 및 지원을 관리하고, 변화와 관련된 위험을 완화할 수 있습니다.

새 워크로드

Amazon Connect Connect에 완전히 새로운 워크로드를 도입하면 기존 사업부 변경과 관련된 위험을 줄이고 유연성과 디지털 혁신 잠재력을 높일 수 있습니다. 하이브리드 모델 아키텍처가 필요하지 않은 순 신규 워크로드는 덜 복잡하고, 비즈니스 프로세스 또는 에이전트 루틴의 변화에 영향을 받지 않으며, 출시 시간이 더 빠릅니다. 순 신규 워크로드를 채택하면 사용량 기반 워크로드를 활용할 수 있습니다. pay-as-you-go 요금. 컨택 센터 리소스를 통해 최종 사용자를 위한 새로운 경험을 만들고, 이를 테스트 및 구현하여 플랫폼을 평가하고, 자신감을 얻고, 기존 워크로드 전반에서 대규모 마이그레이션을 준비할 수 있는 기술 및 운영 메커니즘을 구축할 수 있습니다.

IVR 우선

상담원이 기존 콜 센터 플랫폼에 남아 있는 동안 Amazon Connect Connect를 사용하여 연락처의 IVR 경험을 향상할 수 있습니다. 이 접근 방식을 사용하면 Amazon Connect Flows를 사용하여 셀프 서비스 및 라우팅 로직을 구동하고, 필요한 경우 기존 콜 센터 플랫폼의 대상 상담원 또는 상담원 대기열로 통화를 전송할 수 있습니다.

IVR Last

이러한 접근 방식을 사용하면 기존 콜 센터 IVR이 연락처의 IVR 셀프 서비스 및 라우팅 로직을 구동하고, 필요한 경우 해당 통화를 Amazon Connect Connect로 전송하여 상담원 모집단으로 라우팅합니다.

LoB (Line of B

사업부에 별도의 IVR이 있거나 기존 컨택 센터 플랫폼으로의 연락처 이전이 필요하지 않은 경우 LOB (Line of Business) 마이그레이션 방식을 고려해 볼 수 있습니다. 예를 들어, 내부 지원을 받을 서비스 데스크를 첫 번째 사업부로 선택하여 마이그레이션하는 경우를 예로 들 수 있습니다. 서비스 데스크 IVR 및 상담원 인구를 Amazon Connect Connect로 마이그레이션한 후에는 테스트 및 비즈니스 검증이 완료된 후 엔드포인트를 포팅하여 기존 연락처를 Amazon Connect Connect로 전달하도록 선택할 수 있습니다.

사이트 또는 에이전트 그룹 세분화

컨택 센터가 전 세계에 퍼져 있거나 여러 국가의 서비스 문의가 있거나 각 지역 또는 위치에서 독립적으로 관리되는 경우 상담원의 물리적 사이트 또는 지역을 기반으로 한 마이그레이션 접근 방식을 고려할 수 있습니다. 각 상담원 집단 및/또는 지역에는 전 세계적으로 적용되지 않을 수 있는 고유한 요구 사항 및 고려 사항이 있을 수 있습니다. 이러한 방식으로 마이그레이션을 진행하면 각 사이트 또는 에이전트 그룹이 다음 단계로 넘어가기 전에 독립적으로 운영하는 데 필요한 기술을 습득할 수 있습니다.

가상 데스크톱 인프라 (VDI)

가상 데스크탑 인프라 (VDI) 환경에서 Amazon Connect CCP (Contact Contact Contact Contact Contact Control Panel) 를 사용할 수 있지만, 최적화하려면 별도의 POC 노력과 성능 테스트가 필요합니다. 구성/지원/최적화는 VDI 지원 팀에서 가장 잘 처리하며 가장 일반적으로 구현되는 배포 모델은 다음과 같습니다.

로컬 브라우저 액세스가 가능한 VDI 클라이언트

를 사용하여 사용자 지정 CCP를 만들 수 있습니다.Amazon Connect 스트림미디어 없는 CCP를 생성하여 통화 신호 전송을 위한 미디어 없는 CCP를 생성합니다. 이 방식에서 미디어는 표준 CCP를 사용해 로컬 데스크톱에서 처리되고, 신호 전송 및 통화 제어는 미디어 없는 CCP를 사용해 원격 연결에서 처리됩니다. 다음 다이어그램은 이러한 접근 방식을 설명합니다.

로컬 브라우저 액세스가 없는 VDI 클라이언트

VDI 클라이언트는 로컬 브라우저에 대한 액세스 권한이 없는 경우가 있습니다. 이 시나리오에서는 VDI 서버에서 실행되는 미디어를 사용하여 엔터프라이즈 리소스에 대한 액세스를 허용하는 단일 CCP 인스턴스를 생성할 수 있습니다. 이 배포 모델의 경우 UDP 오디오는 일반적으로 VDI OS에서 활성화됩니다. 이 배포 모델에는 다양한 VDI 서버 매개 변수를 조정하여 경험 품질을 최적화하기 위한 광범위한 테스트가 필요합니다.