고객이 주문 파손 문제로 이메일을 보낸 후 다음날 전화를 걸고 상황을 아는 사람이 없어 다시 채팅을 시작합니다.지원팀이 이메일함, 메모, 개별 도구를 뒤지는 동안 고객은 매번 같은 이야기를 반복하게 됩니다.이것이 바로 다이나믹스 365 케이스 관리 기능으로 해결할 수 있는 문제입니다.케이스란 분주한 사무실 건물에 있는 라벨이 붙은 폴더와 같아서 고객 문제의 모든 부분이 첫질문부터 최종 답변까지 그 폴더 하나에 담깁니다.저는 M365 FM의 미르코 피터스입니다.이번 핵심 지식 시간에는 케이스, 라우팅, 응답기한, 지원 문서, 그리고 종료 처리가 어떻게 하나로 연결되는지 알아보겠습니다. 20단어로 알아보는 케이스의 정의입니다.그렇다면 케이스란 정확히 무엇일까요?케이스는 답변이나 해결이 필요한 한 가지 고객 이슈를 기록한 것이며, 제품 파손, 청구 문외, 로그인 문제, 서비스 이용 관련 지원 요청 등이 여기에 해당합니다.여기서 중요한 점은 한 명이 고객이 동시에 여러 케이스를 가질 수 있다는 것입니다.한 고객이 월요일에는 청구서에 대해 문외하고, 화요일에는 기기 고장을 보고하며, 금요일에는 주소 변경 지원을 요청할 수 있습니다.이는 별개의 문제이므로 다이나믹스 365는 모든 대화를 혼란스러운 하나의 스레드에 쌓아두지 않고 개별 케이스 레코드에 보관합니다.상담원이 케이스를 생성하면 즉시 고객과 연결합니다.여기서 고객이란 개인을 의미하는 연락처일 수도 있고, 그들이 소속된 회사를 의미하는 계정일 수도 있습니다.따라서 노스인드 트레이더스 위 제이미가 문제를 보고하면, 케이스는 제이미와 회사 모두를 가리킬 수 있으며, 기록을 여는 누구든 누가 도움이 필요한지, 어떤 조직의 문제인지 확인할 수 있습니다.또한 케이스에는 소프트웨어 업데이트 후 프린터 작동 중단, 또는 연간 플랜 이중 결제와 같은 제목으로 시작하는 문제의 명확한 설명이 필요하며, 이러한 제목은 모든 레코드를 열지 않고도 열린 케이스 목록을 빠르게 훑어볼 수 있게 해줍니다.

상담원은 해당 제목 아래에 세부 정보를 추가합니다.무슨 일이 일어났나요? 언제 시작되었나요? 고객이 이미 시도해본 방법은 무엇인가요? 어떤 제품과 관련된 문제인가요? 질문인지, 요청인지, 아니면 결함인지도 포함됩니다.이러한 세부 정보는 모호한 메시지를 누군가 맡아서 해결할 수 있는 업무로 변환해줍니다.더 자세히 살펴보겠습니다.케이스에는 주제, 제품, 우선순위, 케이스 유형을 담을 수 있습니다.주제는 문제를 청구 또는 기술 지원과 같은 영역으로 그룹화하고, 제품은 고객이 사용하는 항목을 식별하며, 우선순위는 팀에게 처리 속도를 알려주고,사례 유형은 지원 프로세스에 따라 업무를 분류할 또 다른 방법을 제공합니다.이러한 필드 자체가 고객 인하 문제를 해결해주지는 않지만, 수많은 고객으로부터 수백 건의 사례가 접수될 때 지원팀이 업무를 명확하게 파악하도록 돕습니다.심각한 서비스 장애를 처리하는 팀이 일반적인 질문들 사이에서 해당 문제를 찾느라 시간을 허비해서는 안 됩니다.이제 사례는 단순히 누군가 작성하고 잊어버리는 양식이 아닙니다.사례는 전체 대화에 대한 작업 기록이 됩니다.이메일을 사례에 연결하고, 전화통화를 기록하며, 상담원은 채팅 후 메모를 추가하거나 후속 작업을 설정하고 약속을 기록할 수 있습니다.각 활동은 동일한 고객 문제에 계속 연결되므로, 다음 담당자가 처음부터 이야기를 다시 파악할 필요가 없습니다.상담원이 아침에 업무를 시작하고, 점심 식사 후 사례를 제품 전문가에게 넘기는 상황을 상상해보세요.사례 기록이 없다면 전문가는 이것 좀 확인해줄래요? 와 같은 짧은 메시지만 받을 수도 있습니다.그것으로는 충분하지 않습니다.사례 기록이 있으면 전문가는 원래 문제, 고객 세부 정보, 통화 중 발생한 일, 첫 번째 상담원이 이미 확인한 내용을 볼 수 있습니다.이는 훨씬 더 나은 업무 인계를 가능하게 합니다.

다이나믹스 365는 지원 프로세스가 진행됨에 따라 사례의 상태를 명확하게 유지합니다.팀이 조사하는 동안 사례는 활성 상태로 유지될 수 있으며, 문제가 해결되거나 최종 답변이 제공되면 사례를 해결됨으로 처리합니다.더 이상 작업이 필요 없는 요청인 경우, 즉 실수로 접수되었거나 고객이 철회한 경우 팀은 이를 취소할 수 있습니다.활성, 해결됨, 취소됨, 이 세 가지 상태를 통해 팀은 각 문제의 진행 상황을 공유하며,아무도 사례에 주의가 필요한지 추측할 필요가 없고, 관리자도 이미 끝난 과거의 업무를 새로운 고객 문제로 오인할 일이 없습니다.하나의 기록은 제억 원을 제공하며, 전체 고객 이력은 상담원에게 맥락을 제공합니다.사례 이면에 담긴 고객의 이야기입니다.사례는 무엇을 고쳐야 하는지 알려줍니다.고객 기록은 이 순간에 이르게 된 과정을 알려줍니다.상담원이 다이나믹스 365 커스터머 서비스에서 사례를 열면 최신 메시지 너머를 볼 수 있습니다.상담원은 더 큰 그림, 즉 이전 사례, 과거 이메일, 고객과 연결된 제품 및 지원 이력을 확인합니다.맥락이 대화의 흐름을 바꿉니다.왜 맥락이 중요할까요?고객이 장치 고장을 보고하는 상황을 상상해보세요.상담원이 오늘의 메시지만 확인한다면 기본적인 질문부터 시작할 수 있습니다.모델명이 무엇인가요? 언제부터 시작되었나요? 재부팅은 해보셨나요?하지만 고객은 이번 주에 이미 두 번이나 고객 지원팀에 연락했습니다.첫 번째 상담원은 문제 해결 단계를 안내했고, 두 번째 상담원은 교체 부품을 준비했습니다.그 기록을 확인한 세 번째 상담원은 고객에게 처음부터 다시 설명해달라고 하지 않을 것입니다.대신 이렇게 말하겠죠.이미 안내해드린 단계를 시도하셨고, 교체 부품으로도 해결되지 않은 것을 확인했습니다.다음 방법을 시도해보겠습니다.이는 문제를 다시 설명해 주시겠어요? 라는 말과는 완전히 다른 느낌입니다.

이를 흔히 360도 고객교라고 부릅니다.이름은 거창해 보이지만 의미는 간단합니다.상담원이 단편적인 메시지 하나가 아닌 다양한 각도에서 고객을 바라본다는 뜻입니다.상담원은 고객 개인과 회사, 이전 지원 요청 내역, 지난 대화, 그리고 그와 관련된 제품까지 모두 파악합니다.지원팀 입장에서는 추측 대신 명확한 출발점으로 업무를 시작하게 되는 것입니다.이제 모든 고객이 동일한 지원을 받는 것은 아닙니다.고객은 보증 서비스를 구매했거나, 소속 회사가 정해진 지원 시간을 지불하거나, 특정 건수의 사례를 허용하는 계약을 맺었거나, 더 빠른 지원을 받는 프리미엄 서비스를 이용할 수도 있습니다.다이나믹스 365는 권한, 인타이틀먼츠, 기능을 통해 이 모든 것을 추적합니다.권한은 시스템 내 고객의 지원 계약 상태를 의미합니다.고객 계정에 연결된 서비스 약관이라고 생각하면 됩니다.상담원은 엔지니어 파견이나 유료 작업을 약속하기 전에 어떤 지원이 적용되는지 먼저 확인합니다.그 덕분에 당황스러운 상황을 피할 수 있습니다.예를 들어, 고객이 제품 결함에 대해 여전히 보증을 받을 수 있을지도 모릅니다.그렇다면 해당 절차를 따르면 됩니다.또 다른 고객은 이미 지원 시간을 모두 소진했을 수도 있습니다.상담원은 계약 범위를 벗어난 작업을 약속하기 전에 이를 미리 파악합니다.또한 지원팀이 고객을 공정하게 대우할 수 있도록 돕습니다.상담원이 이전 계약서를 일일이 뒤지거나 다른 부서에 물어볼 필요가 없습니다.지원 약관은 고객 정보와 함께 상담원이 바로 찾을 수 있는 곳에 위치합니다.다음으로는 지식 페이스가 있습니다.지원팀은 반복적으로 동일한 문제를 해결합니다.비밀번호 재설정, 설정 안내, 업데이트 후 발생하는 알려진 오류, 표준 답변이 필요한 청구 관련 질문 등이 있습니다.지식 문서, 날리지 아티클, 는 이러한 답변을 한 곳에 저장합니다.

상담원은 서비스 작업 공간 내에서 사례를 처리하는 동안 관련 문서를 검색할 수 있습니다.문서에는 쉬운 설명, 단계별 절차, 스크린샷, 또는 팀이 완료해야 할 정확한 확인 사항 등이 포함될 수 있습니다.각 상담원이 기억에 의존해 제각기 답변을 작성하는 대신 팀이 검토한 공유 답변을 사용하게 됩니다.그 덕분에 일관된 지원이 가능해집니다.신입 상담원들에게도 큰 도움이 됩니다.팀이 이미 알고 있는 해결 방법이 필요할 때 바로 제공되므로 일반적인 문제를 처리하기 위해 수년의 경험이 필요한 것은 아닙니다.코파일럿 사례 요약은 또 다른 일반적인 문제인 긴 사례 기록 문제를 해결하는 데 도움을 줍니다.사례 하나에는 시간이 지남에 따라 많은 이메일, 네모, 업데이트가 쌓일 수 있습니다.특히 업무 인수 인계 후에는 이 모든 내용을 읽는 데 시간이 걸립니다.코파일럿은 사례 제목, 고객, 주제, 제품, 우선순위, 사례 유형, 설명 및 최근 활동을 하나로 모아 짧은 사례 요약을 만듭니다.상담원이 업무를 시작하기 전에 확인하는 간략한 브리핑입니다.상담원이 여전히 기록을 확인하고 자신의 판단을 사용하지만 상황을 더 빠르게 파악할 수 있습니다.이는 고객이 기다리고 있고 사례가 여러 사람의 손을 거친 경우에 도움이 됩니다.상담원이 고객과 문제를 이해했다면 이제 사례가 적절한 담당자에게 전달되어야 합니다.접수부터 올바른 대기열까지의 과정입니다.고객은 이메일, 전화, 채팅, 소셜미디어, 셀프 서비스 포털 등 다양한 방식으로 도움을 요청할 수 있습니다.채널은 바뀌어도 지원팀은 요청을 관리할 단일한 창구가 필요합니다.다이나믹스 365는 레코드 생성 규칙이 설정된 경우 이러한 대화에서 사례를 생성할 수 있습니다.공용지원 주소로 도착하는 이메일을 생각해보세요.누군가 발견할 때까지 메일함에 방치하는 대신 규칙을 통해 해당 이메일을 사례로 전환합니다.

메시지는 고객 서비스 내부에서 업무의 시작점이 됩니다.이는 수동 복사 작업을 줄여줍니다.동일한 개념이 다른 연결된 채널에도 적용됩니다.팀은 어떤 메시지가 새 사례를 생성하고 어떤 메시지가 기존 사례에 포함되어야 하는지 선택합니다.진행 중인 이슈에 대한 답장은 해당 이슈와 함께 유지됩니다.새로운 질문은 별도의 사례로 생성됩니다.그 다음 누군가가 책임을 맡을 때까지 사례가 머물 공간이 필요합니다.그 공간은 보통 대기열입니다.대기열은 팀을 위한 공유 작업함입니다.이는 한 상담원의 받은 편지함이 아니면 요청을 처음 확인한 사람의 것도 아닙니다.대신 팀 전체가 처리를 기다리는 업무를 확인할 수 있는 공간을 제공합니다.청구팀, 기술지원팀, 반품팀이 있는 회사를 상상해보세요.각 팀은 고유한 대기열을 가지고 있습니다.청구질문은 청구팀으로, 제품결함은 기술지원으로, 반품요청은 반품 절차를 아는 담당자에게 전달됩니다.반순해 보이지만 실제로도 그렇습니다.명확한 분류는 사람들이 업무를 무작정 전달하는 수고를 덜어줍니다.나우팅 규칙은 이러한 분류를 돕습니다.나우팅 규칙은 사례의 세부 정보를 확인하여 올바른 대기열이나 담당자에게 보냅니다.특정 제품에 대한 사례는 제품팀으로 이동합니다.특정 지역에서 발생한 사례는 현지 지원팀으로 전달됩니다.심각한 이슈는 긴급 대기열로 보내집니다.일반적인 질문은 일반팀에서 대기하게 됩니다.일부 조직은 기술을 기반으로 업무를 배정합니다.예를 들어 프랑스어로 문외하는 고객에게는 프랑스어 상담원이 필요합니다.기술적인 문제는 특정 제품에 대해 교육받은 사람이 해결해야 합니다.나우팅은 모든 요청을 동일하게 처리하는 대신 해결할 수 있는 사람에게 사례를 더 가깝게 전달합니다.자동화는 도움이 되지만 최종 결정은 여전히 사람이 내립니다.팀 리더는 어려운 사례를 확인하고 숙련된 상담원에게 직접 배정할 수 있습니다.

이미 고객을 잘 알고 있는 상담원이 있을 수도 있습니다.문제가 여러 제품에 걸쳐 있어 규칙만으로는 판단할 수 없는 경험이 필요할 수도 있습니다.수동 배정을 통해 팀은 이러한 인간적 판단을 내릴 여지를 갖게 됩니다.사례 처리 과정에서 담당자가 변경될 수 있습니다.상담원이 추가 정보를 얻기 위해 사례를 대기열로 다시 보낼 수 있습니다.팀이 문제가 다른 부서의 소관임을 발견하거나일반 팀에서 해결할 수 없는 긴급 요청의 경우 에스컬레이션이 필요할 수 있습니다.다이나믹스 365는 작업이 한 곳에 정체되지 않고 원활하게 흐르도록 합니다.때로는 하나의 문제가 여러 사례를 만들기도 합니다.수십 명이 고객에게 영향을 미치는 소프트웨어 중단을 상상해보십시오.각 고객이 개별적으로 지원팀에 연락하므로 각 신고마다 별도의 사례가 필요합니다.하지만 모든 신고는 하나의 더 큰 문제와 연결되어 있습니다.상위 사례는 광범위한 문제를 추적하고하위 사례는 그 아래에서 개별 고객의 신고를 추적합니다.이를 통해 지원팀은 두 가지 관점을 동시에 볼 수 있습니다.팀은 상위 사례를 통해 근본적인 중단 문제를 해결하고각 하위 사례를 통해 해당 고객에게 진행 상황을 알립니다.해결 방법을 찾으면 상담원마다 매번 처음부터 중단 문제를 조사할 필요가 없습니다.중복 사례는 더 작은 규모로 비슷한 문제를 발생시킵니다.고객이 동일한 문제로 이메일과 전화를 모두 하거나상담원 두 명이 서로 모른 채 사례를 열 수도 있습니다.노력을 분산시키는 대신 팀은 유사한 사례를 병합할 수 있습니다.하나의 사례가 주 기록이 되고 작업이 하나로 관리됩니다.같은 문제를 두 번 해결할 필요는 없습니다.사례를 올바른 대기열과 담당자에게 전달하는 것이 시작이며고객은 약속된 시간 내에 답변을 기대합니다. SLA 및 가이드 작업을 통한 약속 이행사례를 적절한 담당자에게 전달하는 것은 일의 절반일 뿐입니다.

고객은 약속된 시간 내에 도움을 받길 원하기 때문입니다.이때 서비스 수준 계약, 즉 SLA가 필요합니다. SLA는 사례의 시계를 부착하여 팀이 고객과의 약속을 지키기 위해남은 시간을 정확히 알 수 있게 합니다.첫 응답이든 완전한 해결이든 말이죠.하지만 여기서 중요한 점이 있습니다.이 두 가지는 항상 같은 마감기한이 아닐 수 있습니다.예를 들어 기술팀이 해결 방법을 찾고 테스트하는데영업일 기준 2일이 걸리더라도고객은 1시간 이내에 접수 확인을 기대할 수 있습니다.다이나믹스 365는 최초 응답 목표와 해결 목표를 별도로 추적함으로모든 문제를 즉시 해결할 수 있는 것처럼가장하지 않고도 팀이 신속하게 대응할 수 있습니다.자, 서비스가 중단된 고객을 상상해보십시오.고객은 10분 만에 완벽한 수리를 기대하지는 않지만누군가 문제 상황을 인지했음을 확인해주고다음 단계를 설명하며 계속 정보를 공유해주기를 기대합니다.최초 응답 목표는 첫 연락을 추적하고해결 목표는 답변이나 수정까지의 전체 경로를 추적합니다.고객마다 서로 다른 약속이 설정될 수 있습니다.프리미엄 지원을 받는 기업은표준 플랜을 사용하는 고객보다 더 빠른 응답 목표를 적용받습니다.우선 순위가 높은 중단 사고는 일상적인 문의 보다 더 짧은 마감 기한이 설정됩니다.지원 계약, 우선 순위, 사례 유형이 모두 적용되는 시간 규칙을 결정합니다.이를 통해 약속은 공정하고 명확하게 유지됩니다. sla가 없으면 상담원은 목록에 가장 오래된 항목부터 처리할 수 있지만정작 중요한 시간 민감형 사례는 마감 기한을 넘길 수 있습니다. sla를 사용하면 사례 화면에 시간 표시기가 나타나상담원에게 어떤 약속을 먼저 처리해야 하는지 알려줍니다.따라서 점점 커지는 압박감을 확인할 수 있습니다.시간 여유가 있는 사례도 처리해야 하지만응답 마감 시간이 임박한 사례는 즉각적인 주의가 필요합니다.

팀은 목표 시간이 임박하거나 지났을 때알림 또는 에스컬레이션 단계를 설정할 수 있으므로고객이 먼저 팀을 재촉하기 전에 관리자가 개입할 수 있습니다.시간 목표는 긴급성을 안내하고비즈니스 프로세스 흐름은 업무 자체를 안내합니다.비즈니스 프로세스 흐름은 사례 내에 표시되는 일련의 단계입니다.이는 조직이 사례를 처리하는 방식에 따라상담원이 따라야 할 명확한 경로를 제공합니다.단계는 접수에서 조사, 해결로 이어지며각 시점마다 적절한 질문과 확인 절차가 포함될 수 있습니다.이를 프로세스 내 위치가 지정된 체크리스트라고 생각하십시오.신입 상담원은 사례를 전문가에게 보내기 전에어떤 세부 정보가 중요한지 추측할 필요가 없습니다.흐름은 다음 팀이 필요로 하는 제품, 문제 유형,영향 및 기타 정보를 요구할 수 있습니다.숙련된 상담원은 더 빠르게 처리할 수 있지만공유된 경로는 팀이 같은 방향으로 작업하도록 유지해줍니다.한 가지 시나리오를 살펴보겠습니다.우선 순위가 높은 서비스 중단 사례가 접수됩니다.사례가 긴급 대기열에 들어가고SLA 카운트다운이 시작됩니다.상담원은 고객 정보를 확인하고영향을 기록한 다음응답 목표가 만료되기 전에 최초 응답을 보냅니다.다음으로 프로세스 흐름에 따라사례가 진단 단계로 넘어가며팀은 오류 세부 정보를 수집하고관련 보고서를 확인합니다.팀이 원인을 파악하고고객 업데이트를 준비하면사례는 해결 단계로 이동합니다.이러한 순서는 관리자에게도더 명확한 상황 파악을 가능하게 합니다.그들은 접수, 진단 또는 최종 고객 응대 과정 중사례 처리가 어디서 지연되는지 확인할 수 있습니다.워크플로우가 팀의 문제를 완전히 해결해주는 것은 아니지만바쁜 업무 중에 기본적인 단계가 누락되는 것을 방지합니다.다이나믹스 365는 또한상담원이 특정 시점에어떤 상태 변경을 선택할 수 있는지제어할 수 있습니다.이를 상태 이유 전환이라고 하는데기술적으로 들리지만 개념은 간단합니다.

사례는 합리적인 단계를 거쳐 진행되어야 합니다.필수 내부검사가 대기 중인 사례를누군가 해결됨으로 표시하거나이유를 기록하지 않고새 사례에서 바로 취소됨으로 넘어가는 상황은 피해야 합니다.허용되는 선택 항목은사례의 변화에 따라 달라질 수 있습니다.예를 들어 조사 중인 사례의 경우 상담원이 고객 세부 정보를 기다리는 동안보류 상태로 둘 수 있습니다.고객이 회신하면 상담원은 해당 사례를다시 활성 작업으로 전환할 수 있습니다.문제가 해결되면 사례를 해결된 상태로 변경할 수 있습니다.이는 더 깔끔한 사례 이력을 만들어줍니다.회신만으로는 작업이 완료되지 않습니다.팀은 문제가 어떻게 끝났는지기록한 다음 사례를 적절하게 종료해야 합니다.해결, 학습, 그리고 더 나은 서비스답장을 보낸다고 해서 사례가 자동으로 닫히지는 않습니다.팀은 무엇이 문제를 해결했는지또는 고객이 어떤 최종 답변을 받았는지기록하여 해결 과정을 남겨야 합니다.예를 들어 교체 장치 발송, 중복 결제, 환불또는 고객이 차단된 설정을 업데이트한 경우 등이 해당됩니다.이 기록은 고객 정보의 일부가 되며몇 달 후 같은 고객이 관련 문제로 다시 문의할 때다음 상담원에게 유용한 출발점이 됩니다.때로는 첫 번째 해결책이 효과가 없을 때도 있습니다.고객이 지침을 따랐는데도 오류가 다시 발생할 수 있습니다.교체 부품이 도착했지만 결함이 해결되지 않을 수도 있습니다.이런 경우 팀은 이력이 없는 새로운 기록을 시작하는 대신사례를 다시 열거나 대기열에 넣어 추가 작업을 진행할 수 있습니다.사례는 팀이 중단했던 지점부터 계속됩니다.이는 담당자가 변경될 때 중요합니다.새 상담원은 이전 상담원이 무엇을 시도했는지고객이 무엇을 확인했는지그리고 무엇을 더 확인해야 하는지 알 수 있습니다.담당자가 바뀌었다고 해서고객이 처음부터 다시 모든 이야기를 설명할 필요가 없습니다.

시간이 지남에 따라 축적된 사례들은 지원팀에게단일 고객 문제를 넘어선 전체적인 상황을 알려줍니다.관리자는 사례가 접수부터 종료까지 걸리는 시간을 추적하는 해결 소요 시간을 확인할 수 있습니다.관리자는 사례가 어느 단계에서 시간을 많이 소비하는지 보여주는 단계별 소요 시간을 볼 수 있습니다.또한 관리자는 첫 응대 해결률을 모니터링할 수 있는데이는 첫 상담원이 다른 부서로 이관하지 않고 문제를 해결하는 빈도를 의미합니다.업무량도 중요합니다.매주 월요일 아침 특정 대기열이 가득 찬다면팀은 이를 확인할 수 있습니다.기술 지원 사례가 내부 검토를 기다리며 며칠씩 지체되면그 지연 상황이 사례 데이터에 나타납니다.한 팀이 사례를 빠르게 종료하지만

숫자 자체가 모든 것을 설명해주지는 않습니다.숫자는 팀이 어떤 질문을 던져야 할지 알려줍니다.왜 특정 제품에 관한 사례가 증가할까요?왜 특정 유형의 사례는 예상보다 더 오래 걸릴까요?왜 상담원들은 동일한 답을 반복해서 찾으면서 유용한 기술 문서는 발견하지 못할까요?패턴은 일상적인 지원 업무를 실질적인 학습으로 바꿔줍니다.유사한 사례의 증가는 제품 결함을 시사할 수 있습니다.최근 업데이트로 인해 고객들이 혼란을 겪어둠을 보여줄 수도 있습니다.안내서에 더 명확한 단계가 필요하다는 점을 드러낼 수도 있습니다.모든 요청을 개별적인 것으로 처리하는 대신 팀은 공통된 원인을 찾아 해결할 수 있습니다.이는 향후 사례 건수를 줄여줄 수 있습니다.고객 피드백도 그 그림의 일부가 되어야 합니다.종료된 사례는 팀이 응답 목표를 달성했음을 보여주지만고객은 3번이나 문의해야 했다면 여전히 좌절감을 느낄 수 있습니다.사례 이력과 피드백을 모두 살펴보면 관리자는 고객 경험을 더 폭넓게 파악할 수 있습니다.아예 사례를 만들지 않길 원하는 고객도 있습니다.그럴 때 셀프 서비스 포털이 도움이 됩니다.포털을 통해 고객은 지원팀에 전화하지 않고도 요청을 생성하고상태를 확인하며 정보를 추가하거나 승인된 지원 문서를 읽을 수 있습니다.간단한 질문의 경우 이는 모두의 시간을 절약해줍니다.고객은 원할 때 언제든 배송 상태를 확인하거나 설정 가이드를 따라할 수 있습니다.그 사이 상담원은 사람이 직접 조사하고 설명하고 결정해야 하는 문제에 더 많은 시간을 할애할 수 있습니다.다이나믹스 365 커스터머 서비스는 사례 처리 과정에서 익숙한 마이크로소프트 도구들과 연결될 수도 있습니다.상담원은 아웃룩을 통해 이메일 업무를 처리할 수 있습니다.팀은 팀즈에서 어려운 문제를 논의할 수 있습니다.문서와 공유 정보는 시어포인트에 보관될 수 있습니다.

파워비아이는 사례 데이터를 보고서와 대시보드로 변환하며파워 플랫폼 도구는 팀 고유 프로세스에 필요한 추가 양식, 알림 또는 자동화 단계를 지원할 수 있습니다.각 도구에는 저마다의 역할이 있습니다.사례는 사람들이 소통하거나 파일을 공유하거나 작업을 검토하기 위해다른 도구를 사용하더라도 지원 문제와 그 이력이 하나로 연결되는 장소로 남습니다.사례 관리는 단순히 티켓 화면을 채우는 일이 아닙니다.모든 고객 문제의 명확한 경로와 기록된 답변을 제공하고일어난 일로부터 학습할 수 있는 팀을 만드는 것이 중요합니다.결론입니다.고객의 전체 이야기를 하나로 통합하세요.자, 이것이 핵심입니다.다이나믹스 365 사례 관리는 문제와 작업 내용, 약속, 그리고 결과를 하나의 기록으로 유지합니다.더 이상 맥락을 잃어버리거나 같은 수정을 반복할 필요가 없습니다.여러분의 지원 프로세스를 살펴보세요. 5. 고객 정보는 어디로 사라지는 걸까요?그 지점에서 모든 것을 하나로 모으는 것이 모든 것을 변화시킵니다. M365.FM에서 저 미르코 피터스가 전하는 마이크로소프트 지식 알짜 정보를 더 얻으려면즐겨찾는 팟캐스트 플랫폼에서 구독하세요.일상 업무에 쓰이는 마이크로소프트 도구들을 쉬운 언어로 설명해드립니다.