기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 고객 응대 여정 매핑 조직의 목표가 정의되면 다시 돌아가 고객 여정 맵을 구축합니다. 이 맵은 일반적인 참여 패턴과 고객 쿼리를 해결하는 데 필요한 데이터를 식별하는 데 도움이 됩니다. 또한 고객에게 제공되는 경험, 계획되지 않은 이벤트 및 긴급 상황에 대한 대응, 배포에 필요한 고객 응대의 양과 규모를 정의하는 데 도움이 됩니다. 이 단계는 [운영 우수성](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html), [보안](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) 및 [신뢰성](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)이라는 세 가지 [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) 원칙을 계획하는 데 매우 중요합니다. 다음은 고객 응대 여정 맵을 생성할 때 고려해야 할 몇 가지 질문입니다. + **고객이 연락한 이유는 무엇인가요?** 이 질문에 대한 답변은 밸런스 문의, 주문 상태 업데이트, 암호 재설정과 같이 자주 묻는 질문을 식별하는 데 도움이 됩니다. + **고객 신원을 검증하려면 어떻게 해야 하나요?** 보안이 가장 중요합니다. 고객 신원 확인은 고객 응대 여정의 중요한 단계입니다. 인증 옵션에는 음성 생체 인식, 일회용 암호, 신용카드 번호 및 생년월일과 같은 개인 정보가 포함됩니다. 또한 이 정보는 미국 건강 보험 양도 및 책임에 관한 법(HIPAA), Payment Card Industry Data Security Standard(PCI DSS), 시스템 및 조직 제어(SOC)와 같은 규정 준수 요구 사항을 식별하는 데 도움이 됩니다. + **이 고객에 대해 이미 알고 있는 정보는 무엇인가요?** 고객이 식별되면 관련 고객 데이터를 통해 고객 경험을 개인화하고 문제를 선제적으로 해결할 수 있습니다. 이 데이터에는 고객 이름, 미해결 사례, 고객 응대 기록 및 감정, 구매 동작이 포함될 수 있습니다. + **고객의 쿼리를 해결하는 데 필요한 정보는 무엇인가요?** 고객 쿼리를 해결하는 데 필요한 정보를 결정하면 IVR 시스템 내에서 수집해야 하는 고객 데이터를 정의하는 데 도움이 됩니다. 예를 들어 고객이 잔액을 확인하려는 경우 계정 번호와 보안 PIN이 필요하며, IVR 애플리케이션은 뱅킹 데이터가 포함된 백엔드 데이터 저장소와 통합되어야 합니다. 주문 상태를 확인하려면 주문 번호가 필요합니다.  + **고객 요청을 이행하기 위해 통합이 필요한가요?** 일반적으로 성공적인 이행을 위해 IVR의 셀프 서비스 요청에는 백엔드 통합이 필요합니다. 사용 사례에 따라 조직의 데이터베이스, CRM 또는 티켓팅 시스템과 통합될 수 있습니다. 예를 들어 주문 상태를 전달하려면 주문 관리 시스템에서 정보를 쿼리해야 할 수 있습니다. 구매 시 결제 게이트웨이와의 통합이 필요할 수 있습니다. 관련 API의 가용성을 계획할 수 있도록 이러한 종속성을 조기에 식별하는 것이 중요합니다. + **고객 여정 또는 데이터와 관련된 규정 준수 요구 사항은 무엇인가요?** 규정 준수 목표를 정의하고 IVR 설계에 통합하는 것이 중요합니다. 규정 준수 프로그램은 일반적으로 조직 수준에서 시행됩니다. 이러한 토론 및 계획 세션에 정보 보안 팀을 참여시키는 것이 좋습니다. 예를 들어 IVR의 결제 정보에는 암호화 및 PCI DSS 규정 준수가 필요할 수 있습니다. 고객으로부터 수집한 개인 식별 정보(PII)에는 암호화가 필요합니다. IVR 시스템에는 보호해야 하는 추가 정보가 포함될 수도 있습니다. + **통화량이 많거나 사용 가능한 에이전트가 없는 경우 어떻게 대응하나요?** 통화량이 많으면 대기 시간이 길어질 수 있는 시나리오를 식별하는 것이 중요합니다. 이러한 상황에서 IVR 시스템은 종종 고객 응대의 효과적인 리디렉션을 위한 게이트웨이 역할을 수행합니다. 몇 가지 일반적인 편향 전략으로, 예외적으로 긴 대기 시간에는 콜백 제공, 대상 에이전트 풀을 확장하는 오버플로 시나리오 설계, 프로모션 메시지 재생, 고객을 다른 채널(SMS 또는 채팅)로 리디렉션 등이 있습니다. 이러한 전략에 대한 자세한 내용은 블로그 게시물 [How to handle unexpected contact spikes with Connect Customer를 참조하세요](https://aws.amazon.com/blogs/contact-center/how-to-handle-unexpected-contact-spikes-with-amazon-connect/). + **휴일이나 긴급 상황에서 고객 경험은 어떠해야 하나요?** 예상치 못한 긴급 상황과 예상치 못한 이벤트는 고객에게 서비스를 제공하는 조직의 역량에 영향을 줄 수 있습니다. 이러한 이벤트 중에 고객 경험을 계획하는 것은 신뢰성을 위한 모범 사례입니다. 또한 휴일에는 인력 배정이 제한될 수 있으며, IVR 시스템은 고객에게 최신 정보를 제공하고 기대치를 설정하는 데 이상적인 장소가 될 수 있습니다. 예를 들어 IVR 시스템에서 긴급 상황 대체 기능과 휴일 메시지를 설계하고, 이를 업데이트하며, 필요한 경우 관련 업데이트를 재생할 수 있습니다.  + **기술적인 문제가 발생한 경우 고객 경험은 어떠해야 하나요?** 애플리케이션 또는 백엔드 통합 오류가 발생하더라도 IVR 흐름을 따르는 경우 항상 고객 경험이 완전하고 의미가 있어야 합니다. 통합 실패 시 발신자 환경을 설계하는 것이 좋습니다. 일반적으로 재시도 및 루프를 구현하거나 기술적 어려움을 알리는 메시지를 재생하거나 고객을 에이전트로 이전할 수 있습니다. 어느 시나리오에서든 발신자 경험에서 발신자와의 통신이 갑작스럽고 설명되지 않은 방식으로 중단되지 않아야 합니다. 그럴 경우 보통 통화 수가 더 늘어납니다. 고객 응대 여정을 요약한 후 반복 가능한 프로세스 또는 일반적인 패턴을 찾습니다. 이는 IVR 아키텍처 기반을 설계할 때 중점을 두어야 할 핵심 사항입니다.