위치:
IT 서비스의 인테이크에서 해결까지 사고 관리
이 예는 옴니채널 접수에서 SLA를 사용한 해결 및 문제 관리에 이르는 Cumulus Bank의 사고 수명 주기를 보여줍니다.
Cumulus Bank의 IT 처리 담당자인 Julian은 채팅, 이메일, 포털 또는 Slack과 같은 여러 채널을 통해 보고된 사고를 관리합니다. 옴니채널 및 할당 규칙을 사용하면 이러한 사고가 시스템에서 대기열로 자동으로 라우팅됩니다.
그런 다음 Julian 등 사용 가능한 처리자에게 사고가 할당됩니다.
인테이크 및 라우팅
| 소스 | 작업 |
|---|---|
| Chat, 이메일, 포털, Slack | Julian과 같은 처리 담당자가 픽업 |
최근 직원이 이메일을 통해 VPN 연결 문제를 보고했습니다. 문제의 우선 순위가 높으므로 시스템에서 SLA 중대 사건을 자동으로 적용합니다. Julian은 사고를 진행 중으로 이동하여 1시간 이내에 승인을 충족합니다.
SLA 추적
| 중대 사건 | 목표 시간 |
|---|---|
| 확인 | 1시간 이내 |
| 해결 | 4시간 이내 |
시/도 및 중대 사건
| 상태 변경 | 중대 사건 효과 |
|---|---|
| 새로 만들기에서 진행 중 | 1시간 이내에 승인 만남 중대 사건 |
| 진행 중인 작업 | 4시간 이내에 해결 타이머 지속 |
| 중요 사고로 승격 | 정책에 따라 재평가된 SLA 대상(구성된 경우) |
| 해결됨 - 마감됨 | 문제에 대해 해결 방법이 충족되었으며 사고 후 작업이 계속 진행됩니다. |
Julian은 Agentforce 사용하여 지난 하루 동안 보고된 유사한 사고를 이 사고와 자동 연결합니다. 일반적으로 처리 담당자는 추가 승인을 위해 해당 사고만 제안할 수 있습니다. Julian은 높은 권한을 보유하고 있으므로 승인이 필요하지 않고 레코드를 주요 사고로 직접 승격합니다. 승격 시 SLA 정책이 중대 사건 시간을 다시 적용하거나 조정할 수 있습니다(예: 주요 사고에 대한 더 엄격한 목표 설정).
주요 사고 에스컬레이션
| 트리거 | 사용자 작업 |
|---|---|
| 감지된 유사한 사고 | Julian이 사고를 주요 사고로 승격합니다. |
문제에 대한 즉각적인 도움을 받기 위해 Julian은 사고 레코드에서 직접 Slack에서 스워밍을 시작합니다. 또한 Julian은 Agentforce 사용하여 Slack 대화의 요약을 생성하고, Agentforce 요약을 콘솔의 사고 레코드에 대한 피드 업데이트로 게시한 후 스쿼브 세션이 종료됩니다. 이렇게 하면 Slack 및 콘솔 사용자가 모두 일관되게 유지됩니다.
이는 주요 사고이므로 시스템에서 문제 레코드를 자동으로 생성합니다.
문제 생성
| 작업 | 결과 |
|---|---|
| 주요 사고로 승격 | 시스템에서 문제 레코드를 자동으로 만듭니다. |
조사 후 팀은 해결 방법을 찾습니다. Julian은 Einstein 사용하여 문제 해결 가이드 유형의 Knowledge 기사의 초안을 작성하고 이 Knowledge 기사를 사고와 연결합니다. 사고와 관련된 문제가 이미 존재하므로 Knowledge 기사도 자동으로 문제와 연결됩니다. Julian이 문제의 근본 원인을 찾은 후에는 문제에 대해 알려진 오류 유형의 Knowledge 기사를 작성합니다.
Knowledge 재사용
| 작업 | 결과 |
|---|---|
| 해결 방법 식별 | Einstein 재사용을 위해 사고에 연결된 문제 해결 가이드로 Knowledge 기사의 초안을 작성합니다. |
| 근본 원인 식별 | Einstein 재사용을 위해 문제와 연결된 알려진 오류로 Knowledge 기사의 초안을 작성합니다. |
스마트 라우팅, SLA 추적, 연결, 자동화된 문제 생성 및 Knowledge 재사용을 결합하여 Julian은 사고를 더 빠르게 해결합니다.
