WEBVTT

00:00:00.000 --> 00:00:05.900
고객이 주문 파손 문제로 이메일을 보낸 후 다음날 전화를 걸고 상황을 아는 사람이 없어 다시 채팅을 시작합니다.

00:00:06.060 --> 00:00:11.000
지원팀이 이메일함, 메모, 개별 도구를 뒤지는 동안 고객은 매번 같은 이야기를 반복하게 됩니다.

00:00:11.240 --> 00:00:15.040
이것이 바로 다이나믹스 365 케이스 관리 기능으로 해결할 수 있는 문제입니다.

00:00:15.200 --> 00:00:21.860
케이스란 분주한 사무실 건물에 있는 라벨이 붙은 폴더와 같아서 고객 문제의 모든 부분이 첫질문부터 최종 답변까지 그 폴더 하나에 담깁니다.

00:00:22.020 --> 00:00:24.260
저는 M365 FM의 미르코 피터스입니다.

00:00:24.260 --> 00:00:31.560
이번 핵심 지식 시간에는 케이스, 라우팅, 응답기한, 지원 문서, 그리고 종료 처리가 어떻게 하나로 연결되는지 알아보겠습니다.

00:00:31.760 --> 00:00:33.920
20단어로 알아보는 케이스의 정의입니다.

00:00:34.160 --> 00:00:36.220
그렇다면 케이스란 정확히 무엇일까요?

00:00:36.420 --> 00:00:44.980
케이스는 답변이나 해결이 필요한 한 가지 고객 이슈를 기록한 것이며, 제품 파손, 청구 문외, 로그인 문제, 서비스 이용 관련 지원 요청 등이 여기에 해당합니다.

00:00:45.180 --> 00:00:48.880
여기서 중요한 점은 한 명이 고객이 동시에 여러 케이스를 가질 수 있다는 것입니다.

00:00:48.880 --> 00:00:54.900
한 고객이 월요일에는 청구서에 대해 문외하고, 화요일에는 기기 고장을 보고하며, 금요일에는 주소 변경 지원을 요청할 수 있습니다.

00:00:55.080 --> 00:01:01.760
이는 별개의 문제이므로 다이나믹스 365는 모든 대화를 혼란스러운 하나의 스레드에 쌓아두지 않고 개별 케이스 레코드에 보관합니다.

00:01:01.960 --> 00:01:04.900
상담원이 케이스를 생성하면 즉시 고객과 연결합니다.

00:01:05.180 --> 00:01:10.540
여기서 고객이란 개인을 의미하는 연락처일 수도 있고, 그들이 소속된 회사를 의미하는 계정일 수도 있습니다.

00:01:10.540 --> 00:01:20.400
따라서 노스인드 트레이더스 위 제이미가 문제를 보고하면, 케이스는 제이미와 회사 모두를 가리킬 수 있으며, 기록을 여는 누구든 누가 도움이 필요한지, 어떤 조직의 문제인지 확인할 수 있습니다.

00:01:20.560 --> 00:01:34.580
또한 케이스에는 소프트웨어 업데이트 후 프린터 작동 중단, 또는 연간 플랜 이중 결제와 같은 제목으로 시작하는 문제의 명확한 설명이 필요하며, 이러한 제목은 모든 레코드를 열지 않고도 열린 케이스 목록을 빠르게 훑어볼 수 있게 해줍니다.

00:01:34.800 --> 00:01:37.060
상담원은 해당 제목 아래에 세부 정보를 추가합니다.

00:01:37.060 --> 00:01:45.080
무슨 일이 일어났나요? 언제 시작되었나요? 고객이 이미 시도해본 방법은 무엇인가요? 어떤 제품과 관련된 문제인가요? 질문인지, 요청인지, 아니면 결함인지도 포함됩니다.

00:01:45.240 --> 00:01:48.700
이러한 세부 정보는 모호한 메시지를 누군가 맡아서 해결할 수 있는 업무로 변환해줍니다.

00:01:48.860 --> 00:01:50.060
더 자세히 살펴보겠습니다.

00:01:50.440 --> 00:01:54.140
케이스에는 주제, 제품, 우선순위, 케이스 유형을 담을 수 있습니다.

00:01:54.380 --> 00:02:02.760
주제는 문제를 청구 또는 기술 지원과 같은 영역으로 그룹화하고, 제품은 고객이 사용하는 항목을 식별하며, 우선순위는 팀에게 처리 속도를 알려주고,

00:02:02.760 --> 00:02:06.920
사례 유형은 지원 프로세스에 따라 업무를 분류할 또 다른 방법을 제공합니다.

00:02:07.100 --> 00:02:15.680
이러한 필드 자체가 고객 인하 문제를 해결해주지는 않지만, 수많은 고객으로부터 수백 건의 사례가 접수될 때 지원팀이 업무를 명확하게 파악하도록 돕습니다.

00:02:15.900 --> 00:02:21.140
심각한 서비스 장애를 처리하는 팀이 일반적인 질문들 사이에서 해당 문제를 찾느라 시간을 허비해서는 안 됩니다.

00:02:21.420 --> 00:02:24.920
이제 사례는 단순히 누군가 작성하고 잊어버리는 양식이 아닙니다.

00:02:25.140 --> 00:02:27.460
사례는 전체 대화에 대한 작업 기록이 됩니다.

00:02:27.460 --> 00:02:35.520
이메일을 사례에 연결하고, 전화통화를 기록하며, 상담원은 채팅 후 메모를 추가하거나 후속 작업을 설정하고 약속을 기록할 수 있습니다.

00:02:35.720 --> 00:02:41.740
각 활동은 동일한 고객 문제에 계속 연결되므로, 다음 담당자가 처음부터 이야기를 다시 파악할 필요가 없습니다.

00:02:42.080 --> 00:02:46.860
상담원이 아침에 업무를 시작하고, 점심 식사 후 사례를 제품 전문가에게 넘기는 상황을 상상해보세요.

00:02:46.860 --> 00:02:52.140
사례 기록이 없다면 전문가는 이것 좀 확인해줄래요? 와 같은 짧은 메시지만 받을 수도 있습니다.

00:02:52.420 --> 00:02:53.980
그것으로는 충분하지 않습니다.

00:02:54.220 --> 00:03:00.160
사례 기록이 있으면 전문가는 원래 문제, 고객 세부 정보, 통화 중 발생한 일, 첫 번째 상담원이 이미 확인한 내용을 볼 수 있습니다.

00:03:00.360 --> 00:03:02.500
이는 훨씬 더 나은 업무 인계를 가능하게 합니다.

00:03:02.700 --> 00:03:07.140
다이나믹스 365는 지원 프로세스가 진행됨에 따라 사례의 상태를 명확하게 유지합니다.

00:03:07.340 --> 00:03:13.340
팀이 조사하는 동안 사례는 활성 상태로 유지될 수 있으며, 문제가 해결되거나 최종 답변이 제공되면 사례를 해결됨으로 처리합니다.

00:03:13.340 --> 00:03:19.560
더 이상 작업이 필요 없는 요청인 경우, 즉 실수로 접수되었거나 고객이 철회한 경우 팀은 이를 취소할 수 있습니다.

00:03:19.760 --> 00:03:26.300
활성, 해결됨, 취소됨, 이 세 가지 상태를 통해 팀은 각 문제의 진행 상황을 공유하며,

00:03:26.840 --> 00:03:35.000
아무도 사례에 주의가 필요한지 추측할 필요가 없고, 관리자도 이미 끝난 과거의 업무를 새로운 고객 문제로 오인할 일이 없습니다.

00:03:35.560 --> 00:03:40.420
하나의 기록은 제억 원을 제공하며, 전체 고객 이력은 상담원에게 맥락을 제공합니다.

00:03:40.420 --> 00:03:42.780
사례 이면에 담긴 고객의 이야기입니다.

00:03:42.780 --> 00:03:45.120
사례는 무엇을 고쳐야 하는지 알려줍니다.

00:03:45.320 --> 00:03:47.860
고객 기록은 이 순간에 이르게 된 과정을 알려줍니다.

00:03:48.100 --> 00:03:53.200
상담원이 다이나믹스 365 커스터머 서비스에서 사례를 열면 최신 메시지 너머를 볼 수 있습니다.

00:03:53.480 --> 00:03:59.220
상담원은 더 큰 그림, 즉 이전 사례, 과거 이메일, 고객과 연결된 제품 및 지원 이력을 확인합니다.

00:03:59.420 --> 00:04:01.180
맥락이 대화의 흐름을 바꿉니다.

00:04:01.360 --> 00:04:02.600
왜 맥락이 중요할까요?

00:04:02.800 --> 00:04:05.140
고객이 장치 고장을 보고하는 상황을 상상해보세요.

00:04:05.440 --> 00:04:08.800
상담원이 오늘의 메시지만 확인한다면 기본적인 질문부터 시작할 수 있습니다.

00:04:08.800 --> 00:04:12.620
모델명이 무엇인가요? 언제부터 시작되었나요? 재부팅은 해보셨나요?

00:04:12.860 --> 00:04:15.520
하지만 고객은 이번 주에 이미 두 번이나 고객 지원팀에 연락했습니다.

00:04:15.760 --> 00:04:19.040
첫 번째 상담원은 문제 해결 단계를 안내했고, 두 번째 상담원은 교체 부품을 준비했습니다.

00:04:19.220 --> 00:04:22.480
그 기록을 확인한 세 번째 상담원은 고객에게 처음부터 다시 설명해달라고 하지 않을 것입니다.

00:04:22.660 --> 00:04:23.680
대신 이렇게 말하겠죠.

00:04:23.920 --> 00:04:26.880
이미 안내해드린 단계를 시도하셨고, 교체 부품으로도 해결되지 않은 것을 확인했습니다.

00:04:27.140 --> 00:04:28.260
다음 방법을 시도해보겠습니다.

00:04:28.260 --> 00:04:32.320
이는 문제를 다시 설명해 주시겠어요? 라는 말과는 완전히 다른 느낌입니다.

00:04:32.480 --> 00:04:34.660
이를 흔히 360도 고객교라고 부릅니다.

00:04:34.920 --> 00:04:37.020
이름은 거창해 보이지만 의미는 간단합니다.

00:04:37.220 --> 00:04:41.380
상담원이 단편적인 메시지 하나가 아닌 다양한 각도에서 고객을 바라본다는 뜻입니다.

00:04:41.580 --> 00:04:47.220
상담원은 고객 개인과 회사, 이전 지원 요청 내역, 지난 대화, 그리고 그와 관련된 제품까지 모두 파악합니다.

00:04:47.440 --> 00:04:50.860
지원팀 입장에서는 추측 대신 명확한 출발점으로 업무를 시작하게 되는 것입니다.

00:04:51.080 --> 00:04:53.660
이제 모든 고객이 동일한 지원을 받는 것은 아닙니다.

00:04:53.660 --> 00:05:02.900
고객은 보증 서비스를 구매했거나, 소속 회사가 정해진 지원 시간을 지불하거나, 특정 건수의 사례를 허용하는 계약을 맺었거나, 더 빠른 지원을 받는 프리미엄 서비스를 이용할 수도 있습니다.

00:05:03.100 --> 00:05:07.040
다이나믹스 365는 권한, 인타이틀먼츠, 기능을 통해 이 모든 것을 추적합니다.

00:05:07.240 --> 00:05:09.660
권한은 시스템 내 고객의 지원 계약 상태를 의미합니다.

00:05:10.440 --> 00:05:13.260
고객 계정에 연결된 서비스 약관이라고 생각하면 됩니다.

00:05:13.580 --> 00:05:18.400
상담원은 엔지니어 파견이나 유료 작업을 약속하기 전에 어떤 지원이 적용되는지 먼저 확인합니다.

00:05:18.600 --> 00:05:20.520
그 덕분에 당황스러운 상황을 피할 수 있습니다.

00:05:20.520 --> 00:05:23.840
예를 들어, 고객이 제품 결함에 대해 여전히 보증을 받을 수 있을지도 모릅니다.

00:05:24.020 --> 00:05:25.620
그렇다면 해당 절차를 따르면 됩니다.

00:05:25.860 --> 00:05:28.280
또 다른 고객은 이미 지원 시간을 모두 소진했을 수도 있습니다.

00:05:28.500 --> 00:05:31.160
상담원은 계약 범위를 벗어난 작업을 약속하기 전에 이를 미리 파악합니다.

00:05:31.340 --> 00:05:33.720
또한 지원팀이 고객을 공정하게 대우할 수 있도록 돕습니다.

00:05:33.960 --> 00:05:37.040
상담원이 이전 계약서를 일일이 뒤지거나 다른 부서에 물어볼 필요가 없습니다.

00:05:37.320 --> 00:05:40.420
지원 약관은 고객 정보와 함께 상담원이 바로 찾을 수 있는 곳에 위치합니다.

00:05:40.640 --> 00:05:42.060
다음으로는 지식 페이스가 있습니다.

00:05:42.380 --> 00:05:44.600
지원팀은 반복적으로 동일한 문제를 해결합니다.

00:05:44.600 --> 00:05:49.660
비밀번호 재설정, 설정 안내, 업데이트 후 발생하는 알려진 오류, 표준 답변이 필요한 청구 관련 질문 등이 있습니다.

00:05:49.820 --> 00:05:52.540
지식 문서, 날리지 아티클, 는 이러한 답변을 한 곳에 저장합니다.

00:05:52.740 --> 00:05:56.320
상담원은 서비스 작업 공간 내에서 사례를 처리하는 동안 관련 문서를 검색할 수 있습니다.

00:05:56.540 --> 00:06:01.880
문서에는 쉬운 설명, 단계별 절차, 스크린샷, 또는 팀이 완료해야 할 정확한 확인 사항 등이 포함될 수 있습니다.

00:06:02.080 --> 00:06:06.760
각 상담원이 기억에 의존해 제각기 답변을 작성하는 대신 팀이 검토한 공유 답변을 사용하게 됩니다.

00:06:06.960 --> 00:06:08.760
그 덕분에 일관된 지원이 가능해집니다.

00:06:08.760 --> 00:06:10.780
신입 상담원들에게도 큰 도움이 됩니다.

00:06:10.960 --> 00:06:16.240
팀이 이미 알고 있는 해결 방법이 필요할 때 바로 제공되므로 일반적인 문제를 처리하기 위해 수년의 경험이 필요한 것은 아닙니다.

00:06:16.400 --> 00:06:19.960
코파일럿 사례 요약은 또 다른 일반적인 문제인 긴 사례 기록 문제를 해결하는 데 도움을 줍니다.

00:06:20.160 --> 00:06:23.340
사례 하나에는 시간이 지남에 따라 많은 이메일, 네모, 업데이트가 쌓일 수 있습니다.

00:06:23.520 --> 00:06:26.160
특히 업무 인수 인계 후에는 이 모든 내용을 읽는 데 시간이 걸립니다.

00:06:26.360 --> 00:06:33.180
코파일럿은 사례 제목, 고객, 주제, 제품, 우선순위, 사례 유형, 설명 및 최근 활동을 하나로 모아 짧은 사례 요약을 만듭니다.

00:06:33.180 --> 00:06:36.000
상담원이 업무를 시작하기 전에 확인하는 간략한 브리핑입니다.

00:06:36.160 --> 00:06:40.480
상담원이 여전히 기록을 확인하고 자신의 판단을 사용하지만 상황을 더 빠르게 파악할 수 있습니다.

00:06:40.700 --> 00:06:44.400
이는 고객이 기다리고 있고 사례가 여러 사람의 손을 거친 경우에 도움이 됩니다.

00:06:44.680 --> 00:06:49.560
상담원이 고객과 문제를 이해했다면 이제 사례가 적절한 담당자에게 전달되어야 합니다.

00:06:50.100 --> 00:06:52.300
접수부터 올바른 대기열까지의 과정입니다.

00:06:52.560 --> 00:06:58.020
고객은 이메일, 전화, 채팅, 소셜미디어, 셀프 서비스 포털 등 다양한 방식으로 도움을 요청할 수 있습니다.

00:06:58.240 --> 00:07:01.960
채널은 바뀌어도 지원팀은 요청을 관리할 단일한 창구가 필요합니다.

00:07:01.960 --> 00:07:07.820
다이나믹스 365는 레코드 생성 규칙이 설정된 경우 이러한 대화에서 사례를 생성할 수 있습니다.

00:07:08.040 --> 00:07:10.720
공용지원 주소로 도착하는 이메일을 생각해보세요.

00:07:10.980 --> 00:07:15.540
누군가 발견할 때까지 메일함에 방치하는 대신 규칙을 통해 해당 이메일을 사례로 전환합니다.

00:07:15.780 --> 00:07:18.360
메시지는 고객 서비스 내부에서 업무의 시작점이 됩니다.

00:07:18.640 --> 00:07:20.340
이는 수동 복사 작업을 줄여줍니다.

00:07:20.560 --> 00:07:22.920
동일한 개념이 다른 연결된 채널에도 적용됩니다.

00:07:23.120 --> 00:07:27.040
팀은 어떤 메시지가 새 사례를 생성하고 어떤 메시지가 기존 사례에 포함되어야 하는지 선택합니다.

00:07:27.260 --> 00:07:29.520
진행 중인 이슈에 대한 답장은 해당 이슈와 함께 유지됩니다.

00:07:29.520 --> 00:07:31.340
새로운 질문은 별도의 사례로 생성됩니다.

00:07:31.500 --> 00:07:33.960
그 다음 누군가가 책임을 맡을 때까지 사례가 머물 공간이 필요합니다.

00:07:34.100 --> 00:07:35.400
그 공간은 보통 대기열입니다.

00:07:35.580 --> 00:07:37.440
대기열은 팀을 위한 공유 작업함입니다.

00:07:37.660 --> 00:07:41.260
이는 한 상담원의 받은 편지함이 아니면 요청을 처음 확인한 사람의 것도 아닙니다.

00:07:41.440 --> 00:07:44.760
대신 팀 전체가 처리를 기다리는 업무를 확인할 수 있는 공간을 제공합니다.

00:07:44.980 --> 00:07:48.380
청구팀, 기술지원팀, 반품팀이 있는 회사를 상상해보세요.

00:07:48.640 --> 00:07:50.540
각 팀은 고유한 대기열을 가지고 있습니다.

00:07:50.820 --> 00:07:56.340
청구질문은 청구팀으로, 제품결함은 기술지원으로, 반품요청은 반품 절차를 아는 담당자에게 전달됩니다.

00:07:56.340 --> 00:07:58.380
반순해 보이지만 실제로도 그렇습니다.

00:07:58.580 --> 00:08:01.560
명확한 분류는 사람들이 업무를 무작정 전달하는 수고를 덜어줍니다.

00:08:01.760 --> 00:08:03.580
나우팅 규칙은 이러한 분류를 돕습니다.

00:08:03.800 --> 00:08:07.660
나우팅 규칙은 사례의 세부 정보를 확인하여 올바른 대기열이나 담당자에게 보냅니다.

00:08:07.860 --> 00:08:10.240
특정 제품에 대한 사례는 제품팀으로 이동합니다.

00:08:10.460 --> 00:08:13.060
특정 지역에서 발생한 사례는 현지 지원팀으로 전달됩니다.

00:08:13.280 --> 00:08:15.200
심각한 이슈는 긴급 대기열로 보내집니다.

00:08:15.380 --> 00:08:17.400
일반적인 질문은 일반팀에서 대기하게 됩니다.

00:08:17.680 --> 00:08:19.860
일부 조직은 기술을 기반으로 업무를 배정합니다.

00:08:19.860 --> 00:08:23.080
예를 들어 프랑스어로 문외하는 고객에게는 프랑스어 상담원이 필요합니다.

00:08:23.220 --> 00:08:26.100
기술적인 문제는 특정 제품에 대해 교육받은 사람이 해결해야 합니다.

00:08:26.280 --> 00:08:30.260
나우팅은 모든 요청을 동일하게 처리하는 대신 해결할 수 있는 사람에게 사례를 더 가깝게 전달합니다.

00:08:30.420 --> 00:08:32.940
자동화는 도움이 되지만 최종 결정은 여전히 사람이 내립니다.

00:08:33.160 --> 00:08:36.360
팀 리더는 어려운 사례를 확인하고 숙련된 상담원에게 직접 배정할 수 있습니다.

00:08:36.600 --> 00:08:38.720
이미 고객을 잘 알고 있는 상담원이 있을 수도 있습니다.

00:08:38.960 --> 00:08:42.200
문제가 여러 제품에 걸쳐 있어 규칙만으로는 판단할 수 없는 경험이 필요할 수도 있습니다.

00:08:42.440 --> 00:08:45.140
수동 배정을 통해 팀은 이러한 인간적 판단을 내릴 여지를 갖게 됩니다.

00:08:45.140 --> 00:08:47.440
사례 처리 과정에서 담당자가 변경될 수 있습니다.

00:08:47.640 --> 00:08:50.640
상담원이 추가 정보를 얻기 위해 사례를 대기열로 다시 보낼 수 있습니다.

00:08:50.840 --> 00:08:52.960
팀이 문제가 다른 부서의 소관임을 발견하거나

00:08:52.960 --> 00:08:56.940
일반 팀에서 해결할 수 없는 긴급 요청의 경우 에스컬레이션이 필요할 수 있습니다.

00:08:57.180 --> 00:09:01.360
다이나믹스 365는 작업이 한 곳에 정체되지 않고 원활하게 흐르도록 합니다.

00:09:01.500 --> 00:09:04.100
때로는 하나의 문제가 여러 사례를 만들기도 합니다.

00:09:04.300 --> 00:09:07.340
수십 명이 고객에게 영향을 미치는 소프트웨어 중단을 상상해보십시오.

00:09:07.480 --> 00:09:10.960
각 고객이 개별적으로 지원팀에 연락하므로 각 신고마다 별도의 사례가 필요합니다.

00:09:10.960 --> 00:09:13.700
하지만 모든 신고는 하나의 더 큰 문제와 연결되어 있습니다.

00:09:13.980 --> 00:09:15.660
상위 사례는 광범위한 문제를 추적하고

00:09:15.660 --> 00:09:18.400
하위 사례는 그 아래에서 개별 고객의 신고를 추적합니다.

00:09:18.580 --> 00:09:21.000
이를 통해 지원팀은 두 가지 관점을 동시에 볼 수 있습니다.

00:09:21.200 --> 00:09:23.400
팀은 상위 사례를 통해 근본적인 중단 문제를 해결하고

00:09:23.400 --> 00:09:25.920
각 하위 사례를 통해 해당 고객에게 진행 상황을 알립니다.

00:09:26.120 --> 00:09:29.800
해결 방법을 찾으면 상담원마다 매번 처음부터 중단 문제를 조사할 필요가 없습니다.

00:09:30.080 --> 00:09:32.920
중복 사례는 더 작은 규모로 비슷한 문제를 발생시킵니다.

00:09:33.100 --> 00:09:35.400
고객이 동일한 문제로 이메일과 전화를 모두 하거나

00:09:35.400 --> 00:09:38.100
상담원 두 명이 서로 모른 채 사례를 열 수도 있습니다.

00:09:38.100 --> 00:09:41.740
노력을 분산시키는 대신 팀은 유사한 사례를 병합할 수 있습니다.

00:09:41.940 --> 00:09:44.880
하나의 사례가 주 기록이 되고 작업이 하나로 관리됩니다.

00:09:45.080 --> 00:09:47.120
같은 문제를 두 번 해결할 필요는 없습니다.

00:09:47.520 --> 00:09:50.680
사례를 올바른 대기열과 담당자에게 전달하는 것이 시작이며

00:09:50.680 --> 00:09:53.440
고객은 약속된 시간 내에 답변을 기대합니다.

00:09:53.680 --> 00:09:56.180
SLA 및 가이드 작업을 통한 약속 이행

00:09:56.180 --> 00:09:59.500
사례를 적절한 담당자에게 전달하는 것은 일의 절반일 뿐입니다.

00:09:59.700 --> 00:10:02.380
고객은 약속된 시간 내에 도움을 받길 원하기 때문입니다.

00:10:02.560 --> 00:10:05.620
이때 서비스 수준 계약, 즉 SLA가 필요합니다.

00:10:05.620 --> 00:10:09.760
SLA는 사례의 시계를 부착하여 팀이 고객과의 약속을 지키기 위해

00:10:09.760 --> 00:10:11.580
남은 시간을 정확히 알 수 있게 합니다.

00:10:11.760 --> 00:10:13.820
첫 응답이든 완전한 해결이든 말이죠.

00:10:14.060 --> 00:10:15.660
하지만 여기서 중요한 점이 있습니다.

00:10:15.920 --> 00:10:18.200
이 두 가지는 항상 같은 마감기한이 아닐 수 있습니다.

00:10:18.420 --> 00:10:20.600
예를 들어 기술팀이 해결 방법을 찾고 테스트하는데

00:10:20.600 --> 00:10:22.000
영업일 기준 2일이 걸리더라도

00:10:22.000 --> 00:10:24.520
고객은 1시간 이내에 접수 확인을 기대할 수 있습니다.

00:10:24.740 --> 00:10:28.240
다이나믹스 365는 최초 응답 목표와 해결 목표를 별도로 추적함으로

00:10:28.240 --> 00:10:30.340
모든 문제를 즉시 해결할 수 있는 것처럼

00:10:30.340 --> 00:10:32.760
가장하지 않고도 팀이 신속하게 대응할 수 있습니다.

00:10:32.760 --> 00:10:35.700
자, 서비스가 중단된 고객을 상상해보십시오.

00:10:35.800 --> 00:10:38.020
고객은 10분 만에 완벽한 수리를 기대하지는 않지만

00:10:38.020 --> 00:10:40.280
누군가 문제 상황을 인지했음을 확인해주고

00:10:40.280 --> 00:10:43.000
다음 단계를 설명하며 계속 정보를 공유해주기를 기대합니다.

00:10:43.160 --> 00:10:45.120
최초 응답 목표는 첫 연락을 추적하고

00:10:45.120 --> 00:10:48.420
해결 목표는 답변이나 수정까지의 전체 경로를 추적합니다.

00:10:48.660 --> 00:10:51.020
고객마다 서로 다른 약속이 설정될 수 있습니다.

00:10:51.260 --> 00:10:52.460
프리미엄 지원을 받는 기업은

00:10:52.460 --> 00:10:55.560
표준 플랜을 사용하는 고객보다 더 빠른 응답 목표를 적용받습니다.

00:10:55.560 --> 00:11:00.140
우선 순위가 높은 중단 사고는 일상적인 문의 보다 더 짧은 마감 기한이 설정됩니다.

00:11:00.340 --> 00:11:03.920
지원 계약, 우선 순위, 사례 유형이 모두 적용되는 시간 규칙을 결정합니다.

00:11:04.120 --> 00:11:06.340
이를 통해 약속은 공정하고 명확하게 유지됩니다.

00:11:06.540 --> 00:11:09.260
sla가 없으면 상담원은 목록에 가장 오래된 항목부터 처리할 수 있지만

00:11:09.260 --> 00:11:11.860
정작 중요한 시간 민감형 사례는 마감 기한을 넘길 수 있습니다.

00:11:12.060 --> 00:11:14.400
sla를 사용하면 사례 화면에 시간 표시기가 나타나

00:11:14.400 --> 00:11:16.860
상담원에게 어떤 약속을 먼저 처리해야 하는지 알려줍니다.

00:11:17.040 --> 00:11:19.140
따라서 점점 커지는 압박감을 확인할 수 있습니다.

00:11:19.400 --> 00:11:21.140
시간 여유가 있는 사례도 처리해야 하지만

00:11:21.140 --> 00:11:24.380
응답 마감 시간이 임박한 사례는 즉각적인 주의가 필요합니다.

00:11:24.520 --> 00:11:26.260
팀은 목표 시간이 임박하거나 지났을 때

00:11:26.260 --> 00:11:28.660
알림 또는 에스컬레이션 단계를 설정할 수 있으므로

00:11:28.660 --> 00:11:31.780
고객이 먼저 팀을 재촉하기 전에 관리자가 개입할 수 있습니다.

00:11:32.020 --> 00:11:33.680
시간 목표는 긴급성을 안내하고

00:11:33.680 --> 00:11:36.220
비즈니스 프로세스 흐름은 업무 자체를 안내합니다.

00:11:36.420 --> 00:11:39.640
비즈니스 프로세스 흐름은 사례 내에 표시되는 일련의 단계입니다.

00:11:39.880 --> 00:11:41.800
이는 조직이 사례를 처리하는 방식에 따라

00:11:41.800 --> 00:11:44.160
상담원이 따라야 할 명확한 경로를 제공합니다.

00:11:44.400 --> 00:11:46.540
단계는 접수에서 조사, 해결로 이어지며

00:11:46.540 --> 00:11:49.400
각 시점마다 적절한 질문과 확인 절차가 포함될 수 있습니다.

00:11:49.600 --> 00:11:52.360
이를 프로세스 내 위치가 지정된 체크리스트라고 생각하십시오.

00:11:52.520 --> 00:11:54.400
신입 상담원은 사례를 전문가에게 보내기 전에

00:11:54.400 --> 00:11:56.560
어떤 세부 정보가 중요한지 추측할 필요가 없습니다.

00:11:56.560 --> 00:11:59.200
흐름은 다음 팀이 필요로 하는 제품, 문제 유형,

00:11:59.480 --> 00:12:01.180
영향 및 기타 정보를 요구할 수 있습니다.

00:12:01.380 --> 00:12:03.160
숙련된 상담원은 더 빠르게 처리할 수 있지만

00:12:03.160 --> 00:12:05.880
공유된 경로는 팀이 같은 방향으로 작업하도록 유지해줍니다.

00:12:06.020 --> 00:12:07.320
한 가지 시나리오를 살펴보겠습니다.

00:12:07.740 --> 00:12:10.000
우선 순위가 높은 서비스 중단 사례가 접수됩니다.

00:12:10.220 --> 00:12:11.700
사례가 긴급 대기열에 들어가고

00:12:11.700 --> 00:12:13.400
SLA 카운트다운이 시작됩니다.

00:12:13.640 --> 00:12:15.280
상담원은 고객 정보를 확인하고

00:12:15.280 --> 00:12:16.620
영향을 기록한 다음

00:12:16.620 --> 00:12:19.540
응답 목표가 만료되기 전에 최초 응답을 보냅니다.

00:12:19.760 --> 00:12:21.100
다음으로 프로세스 흐름에 따라

00:12:21.100 --> 00:12:22.700
사례가 진단 단계로 넘어가며

00:12:22.700 --> 00:12:24.600
팀은 오류 세부 정보를 수집하고

00:12:24.600 --> 00:12:25.980
관련 보고서를 확인합니다.

00:12:26.140 --> 00:12:27.280
팀이 원인을 파악하고

00:12:27.280 --> 00:12:28.740
고객 업데이트를 준비하면

00:12:28.740 --> 00:12:30.400
사례는 해결 단계로 이동합니다.

00:12:30.600 --> 00:12:31.980
이러한 순서는 관리자에게도

00:12:31.980 --> 00:12:33.760
더 명확한 상황 파악을 가능하게 합니다.

00:12:33.980 --> 00:12:36.280
그들은 접수, 진단 또는 최종 고객 응대 과정 중

00:12:36.280 --> 00:12:38.300
사례 처리가 어디서 지연되는지 확인할 수 있습니다.

00:12:38.300 --> 00:12:40.700
워크플로우가 팀의 문제를 완전히 해결해주는 것은 아니지만

00:12:40.700 --> 00:12:43.420
바쁜 업무 중에 기본적인 단계가 누락되는 것을 방지합니다.

00:12:43.540 --> 00:12:44.820
다이나믹스 365는 또한

00:12:44.820 --> 00:12:45.880
상담원이 특정 시점에

00:12:45.880 --> 00:12:47.440
어떤 상태 변경을 선택할 수 있는지

00:12:47.440 --> 00:12:48.220
제어할 수 있습니다.

00:12:48.440 --> 00:12:50.040
이를 상태 이유 전환이라고 하는데

00:12:50.040 --> 00:12:52.540
기술적으로 들리지만 개념은 간단합니다.

00:12:52.800 --> 00:12:55.200
사례는 합리적인 단계를 거쳐 진행되어야 합니다.

00:12:55.400 --> 00:12:57.020
필수 내부검사가 대기 중인 사례를

00:12:57.020 --> 00:12:58.380
누군가 해결됨으로 표시하거나

00:12:58.380 --> 00:12:59.580
이유를 기록하지 않고

00:12:59.580 --> 00:13:02.320
새 사례에서 바로 취소됨으로 넘어가는 상황은 피해야 합니다.

00:13:02.520 --> 00:13:03.620
허용되는 선택 항목은

00:13:03.620 --> 00:13:05.300
사례의 변화에 따라 달라질 수 있습니다.

00:13:05.300 --> 00:13:08.900
예를 들어 조사 중인 사례의 경우 상담원이 고객 세부 정보를 기다리는 동안

00:13:08.900 --> 00:13:10.080
보류 상태로 둘 수 있습니다.

00:13:10.280 --> 00:13:11.920
고객이 회신하면 상담원은 해당 사례를

00:13:11.920 --> 00:13:13.400
다시 활성 작업으로 전환할 수 있습니다.

00:13:13.620 --> 00:13:15.940
문제가 해결되면 사례를 해결된 상태로 변경할 수 있습니다.

00:13:16.160 --> 00:13:17.900
이는 더 깔끔한 사례 이력을 만들어줍니다.

00:13:18.100 --> 00:13:19.880
회신만으로는 작업이 완료되지 않습니다.

00:13:20.080 --> 00:13:21.360
팀은 문제가 어떻게 끝났는지

00:13:21.360 --> 00:13:23.600
기록한 다음 사례를 적절하게 종료해야 합니다.

00:13:23.780 --> 00:13:26.300
해결, 학습, 그리고 더 나은 서비스

00:13:26.300 --> 00:13:29.140
답장을 보낸다고 해서 사례가 자동으로 닫히지는 않습니다.

00:13:29.340 --> 00:13:30.780
팀은 무엇이 문제를 해결했는지

00:13:30.780 --> 00:13:32.800
또는 고객이 어떤 최종 답변을 받았는지

00:13:32.800 --> 00:13:34.560
기록하여 해결 과정을 남겨야 합니다.

00:13:34.720 --> 00:13:37.440
예를 들어 교체 장치 발송, 중복 결제, 환불

00:13:37.440 --> 00:13:40.600
또는 고객이 차단된 설정을 업데이트한 경우 등이 해당됩니다.

00:13:40.800 --> 00:13:42.560
이 기록은 고객 정보의 일부가 되며

00:13:42.560 --> 00:13:45.580
몇 달 후 같은 고객이 관련 문제로 다시 문의할 때

00:13:45.580 --> 00:13:47.720
다음 상담원에게 유용한 출발점이 됩니다.

00:13:47.960 --> 00:13:50.280
때로는 첫 번째 해결책이 효과가 없을 때도 있습니다.

00:13:50.520 --> 00:13:53.140
고객이 지침을 따랐는데도 오류가 다시 발생할 수 있습니다.

00:13:53.380 --> 00:13:56.080
교체 부품이 도착했지만 결함이 해결되지 않을 수도 있습니다.

00:13:56.080 --> 00:13:59.280
이런 경우 팀은 이력이 없는 새로운 기록을 시작하는 대신

00:13:59.280 --> 00:14:02.480
사례를 다시 열거나 대기열에 넣어 추가 작업을 진행할 수 있습니다.

00:14:02.740 --> 00:14:04.960
사례는 팀이 중단했던 지점부터 계속됩니다.

00:14:05.160 --> 00:14:06.980
이는 담당자가 변경될 때 중요합니다.

00:14:07.180 --> 00:14:08.860
새 상담원은 이전 상담원이 무엇을 시도했는지

00:14:08.860 --> 00:14:10.120
고객이 무엇을 확인했는지

00:14:10.120 --> 00:14:11.980
그리고 무엇을 더 확인해야 하는지 알 수 있습니다.

00:14:12.160 --> 00:14:13.440
담당자가 바뀌었다고 해서

00:14:13.440 --> 00:14:16.440
고객이 처음부터 다시 모든 이야기를 설명할 필요가 없습니다.

00:14:16.800 --> 00:14:19.020
시간이 지남에 따라 축적된 사례들은 지원팀에게

00:14:19.020 --> 00:14:21.580
단일 고객 문제를 넘어선 전체적인 상황을 알려줍니다.

00:14:21.580 --> 00:14:26.280
관리자는 사례가 접수부터 종료까지 걸리는 시간을 추적하는 해결 소요 시간을 확인할 수 있습니다.

00:14:26.460 --> 00:14:30.160
관리자는 사례가 어느 단계에서 시간을 많이 소비하는지 보여주는 단계별 소요 시간을 볼 수 있습니다.

00:14:30.340 --> 00:14:32.580
또한 관리자는 첫 응대 해결률을 모니터링할 수 있는데

00:14:32.580 --> 00:14:36.420
이는 첫 상담원이 다른 부서로 이관하지 않고 문제를 해결하는 빈도를 의미합니다.

00:14:36.580 --> 00:14:37.680
업무량도 중요합니다.

00:14:37.900 --> 00:14:39.860
매주 월요일 아침 특정 대기열이 가득 찬다면

00:14:39.860 --> 00:14:41.240
팀은 이를 확인할 수 있습니다.

00:14:41.460 --> 00:14:44.060
기술 지원 사례가 내부 검토를 기다리며 며칠씩 지체되면

00:14:44.060 --> 00:14:46.040
그 지연 상황이 사례 데이터에 나타납니다.

00:14:46.240 --> 00:14:47.760
한 팀이 사례를 빠르게 종료하지만

00:14:51.580 --> 00:14:54.740
숫자 자체가 모든 것을 설명해주지는 않습니다.

00:14:54.900 --> 00:14:57.340
숫자는 팀이 어떤 질문을 던져야 할지 알려줍니다.

00:14:57.540 --> 00:14:59.580
왜 특정 제품에 관한 사례가 증가할까요?

00:14:59.760 --> 00:15:02.360
왜 특정 유형의 사례는 예상보다 더 오래 걸릴까요?

00:15:02.560 --> 00:15:06.740
왜 상담원들은 동일한 답을 반복해서 찾으면서 유용한 기술 문서는 발견하지 못할까요?

00:15:06.920 --> 00:15:09.880
패턴은 일상적인 지원 업무를 실질적인 학습으로 바꿔줍니다.

00:15:10.080 --> 00:15:12.380
유사한 사례의 증가는 제품 결함을 시사할 수 있습니다.

00:15:12.600 --> 00:15:15.220
최근 업데이트로 인해 고객들이 혼란을 겪어둠을 보여줄 수도 있습니다.

00:15:15.440 --> 00:15:18.120
안내서에 더 명확한 단계가 필요하다는 점을 드러낼 수도 있습니다.

00:15:18.120 --> 00:15:22.300
모든 요청을 개별적인 것으로 처리하는 대신 팀은 공통된 원인을 찾아 해결할 수 있습니다.

00:15:22.480 --> 00:15:24.320
이는 향후 사례 건수를 줄여줄 수 있습니다.

00:15:24.540 --> 00:15:26.680
고객 피드백도 그 그림의 일부가 되어야 합니다.

00:15:26.860 --> 00:15:29.540
종료된 사례는 팀이 응답 목표를 달성했음을 보여주지만

00:15:29.540 --> 00:15:33.000
고객은 3번이나 문의해야 했다면 여전히 좌절감을 느낄 수 있습니다.

00:15:33.260 --> 00:15:37.360
사례 이력과 피드백을 모두 살펴보면 관리자는 고객 경험을 더 폭넓게 파악할 수 있습니다.

00:15:37.600 --> 00:15:39.800
아예 사례를 만들지 않길 원하는 고객도 있습니다.

00:15:40.120 --> 00:15:42.080
그럴 때 셀프 서비스 포털이 도움이 됩니다.

00:15:42.360 --> 00:15:45.480
포털을 통해 고객은 지원팀에 전화하지 않고도 요청을 생성하고

00:15:45.480 --> 00:15:49.580
상태를 확인하며 정보를 추가하거나 승인된 지원 문서를 읽을 수 있습니다.

00:15:49.820 --> 00:15:52.880
간단한 질문의 경우 이는 모두의 시간을 절약해줍니다.

00:15:53.080 --> 00:15:57.080
고객은 원할 때 언제든 배송 상태를 확인하거나 설정 가이드를 따라할 수 있습니다.

00:15:57.320 --> 00:16:02.600
그 사이 상담원은 사람이 직접 조사하고 설명하고 결정해야 하는 문제에 더 많은 시간을 할애할 수 있습니다.

00:16:02.820 --> 00:16:07.660
다이나믹스 365 커스터머 서비스는 사례 처리 과정에서 익숙한 마이크로소프트 도구들과 연결될 수도 있습니다.

00:16:07.900 --> 00:16:10.300
상담원은 아웃룩을 통해 이메일 업무를 처리할 수 있습니다.

00:16:10.300 --> 00:16:12.780
팀은 팀즈에서 어려운 문제를 논의할 수 있습니다.

00:16:13.000 --> 00:16:15.560
문서와 공유 정보는 시어포인트에 보관될 수 있습니다.

00:16:15.780 --> 00:16:18.360
파워비아이는 사례 데이터를 보고서와 대시보드로 변환하며

00:16:18.360 --> 00:16:23.240
파워 플랫폼 도구는 팀 고유 프로세스에 필요한 추가 양식, 알림 또는 자동화 단계를 지원할 수 있습니다.

00:16:23.440 --> 00:16:25.240
각 도구에는 저마다의 역할이 있습니다.

00:16:25.580 --> 00:16:28.680
사례는 사람들이 소통하거나 파일을 공유하거나 작업을 검토하기 위해

00:16:28.680 --> 00:16:32.380
다른 도구를 사용하더라도 지원 문제와 그 이력이 하나로 연결되는 장소로 남습니다.

00:16:32.640 --> 00:16:35.200
사례 관리는 단순히 티켓 화면을 채우는 일이 아닙니다.

00:16:35.200 --> 00:16:37.880
모든 고객 문제의 명확한 경로와 기록된 답변을 제공하고

00:16:37.880 --> 00:16:40.700
일어난 일로부터 학습할 수 있는 팀을 만드는 것이 중요합니다.

00:16:40.840 --> 00:16:41.500
결론입니다.

00:16:41.740 --> 00:16:43.920
고객의 전체 이야기를 하나로 통합하세요.

00:16:44.180 --> 00:16:45.640
자, 이것이 핵심입니다.

00:16:45.860 --> 00:16:51.380
다이나믹스 365 사례 관리는 문제와 작업 내용, 약속, 그리고 결과를 하나의 기록으로 유지합니다.

00:16:51.580 --> 00:16:54.040
더 이상 맥락을 잃어버리거나 같은 수정을 반복할 필요가 없습니다.

00:16:54.340 --> 00:16:55.960
여러분의 지원 프로세스를 살펴보세요.

00:16:56.220 --> 00:16:58.260
5. 고객 정보는 어디로 사라지는 걸까요?

00:16:58.400 --> 00:17:01.140
그 지점에서 모든 것을 하나로 모으는 것이 모든 것을 변화시킵니다.

00:17:01.140 --> 00:17:05.240
M365.FM에서 저 미르코 피터스가 전하는 마이크로소프트 지식 알짜 정보를 더 얻으려면

00:17:05.240 --> 00:17:06.960
즐겨찾는 팟캐스트 플랫폼에서 구독하세요.

00:17:07.140 --> 00:17:10.560
일상 업무에 쓰이는 마이크로소프트 도구들을 쉬운 언어로 설명해드립니다.