헬프데스크의 티켓 수명주기 및 고객과의 커뮤니케이션
개요
이 문서에서는 헬프데스크에서 티켓이 생성되는 방식과 클라이언트의 시스템 액세스에 따라 티켓팅 프로세스를 살펴보겠습니다. 다양한 티켓 프로세스 구성에서 주의해야 할 사항에 대한 팁을 찾을 수 있습니다.
이 문서에는 다양한 구성에 대한 팁과 제안이 포함되어 있지만 구성 방법을 직접적으로 설명하지는 않습니다. 관련 기사는 다음과 같습니다.
세 가지 주요 통신 경로
티켓이 처음부터 끝까지 한 가지 유형의 흐름만 따르는 간단한 상황에서 티켓 수명 주기 체계로 시작합니다.
- 이메일
- 애플리케이션의 전체 사용자
- 애플리케이션의 헬프 데스크 사용자
티켓 내 생성 및 추가 커뮤니케이션
티켓 생성 및 추가 커뮤니케이션은 위의 접근 방식을 결합할 수 있습니다.
이메일을 통해 티켓을 만든 다음 애플리케이션에서 후속 조치를 취할 수 있습니다(정식 사용자 또는 헬프 데스크 사용자). 시스템을 통해 티켓을 만든 다음 이메일만 팔로우하는 것도 가능합니다.
예제 1
- 티켓은 이메일을 통해 생성됩니다. 클라이언트는 헬프데스크 주소로 새 이메일을 보냅니다.
- 클라이언트는 시스템에 로그인하여 티켓 작성자이므로 그곳에서 티켓을 볼 수 있습니다.
- 클라이언트는 권한에 따라 상태 및 기타 필드를 변경하고 댓글을 남길 수 있습니다.
예제 2
- 클라이언트가 시스템에 로그인하고 새 티켓을 생성합니다.
- 고객은 이메일을 통해 업데이트를 받고 이러한 업데이트를 보기만 하며 더 이상 시스템에 로그인할 필요를 느끼지 않습니다.
예제 3
- 클라이언트가 헬프데스크 포털을 통해 티켓을 생성합니다.
- 고객은 이메일만 팔로우하고 더 이상 포털에 로그인하지 않기로 결정합니다.
- 그런 다음 클라이언트는 포털을 통해 팔로우하기로 결정하고 나에게 로그인한 후 포털을 통해 일부 응답을 입력합니다.
고객의 편의를 위해 고객이 티켓을 생성 및/또는 업데이트하도록 허용할 방법을 결정할 수 있습니다. 하지만 가장 중요한 것은 티켓이 막다른 골목에 빠지지 않도록 가능한 모든 상황을 다루어야 한다는 것입니다. 워크플로 및 기타 구성은 필요한 모든 옵션을 제공합니다.
일반적인 문제
클라이언트가 정기적인 작업 알림에 응답하지만 응답이 제대로 처리되지 않습니다.
이 이야기는 예 2에 관한 것입니다. 클라이언트는 이메일을 통해 티켓에 답장하고 있다고 생각하지만 이메일이 기존 티켓과 페어링되지 않고 대신 새 티켓이 생성되거나 이메일이 시스템에 전혀 도달하지 않습니다. 고객이 알림에 응답하거나 실수로 새 이메일을 작성합니다.
원인: 이메일 알림 설정에서는 알림 주소에 대한 응답을 기대하지 않습니다.
해결 방법: 클라이언트 응답은 헬프데스크가 지정한 주소로 보내야 하며 티켓 번호를 포함해야 합니다. 알림 이메일 주소(관리 >> 설정 >> 이메일 알림 >> 알림 이메일 주소(FROM))는 클라이언트의 응답을 받아 처음 알림이 전송된 티켓과 연결하기 위한 헬프데스크 메일 주소와 동일할 수 있습니다.
또 다른 옵션은 클라이언트 사용자에게 정기적인 이메일 알림을 비활성화하는 것입니다. 그들이 받게 될 티켓의 유일한 이메일은 헬프 데스크 이메일 템플릿을 통해 운영자가 적극적으로 보내는 것입니다.
주요 내용: 고객은 받은 이메일 메시지에 자연스럽게 답장을 보내고 싶은 유혹을 받게 됩니다. 응답이 제대로 처리될 수 있는 메시지만 수신하는지 확인하세요.
클라이언트가 티켓을 "잘못된" 상태로 변경했습니다.
이는 클라이언트가 응용 프로그램에 헬프 데스크 사용자 대신 전체 사용자를 보유하고 있는 상황에서 주로 발생합니다. 고객은 상태를 포함한 많은 필드를 편집할 수 있는 옵션을 가질 수 있으며 다양한 상태의 의미를 잘못 해석할 수 있습니다. 또는 상태가 변경될 것으로 예상하는데 상태를 변경하지 않을 수도 있습니다.
원인: 올바른 상태를 설정하는 것은 클라이언트의 책임입니다.
해결 방법: 이는 분명한 안티 패턴입니다. 클라이언트는 작업 상태에 대한 규칙을 기억할 필요가 없습니다.
한 가지 해결책은 클라이언트 계정을 전체 사용자 대신 헬프 데스크 사용자로 전환하는 것입니다. 헬프 데스크 사용자는 티켓을 만들고 기존 티켓에 설명을 입력할 수 있습니다. 상태 변경은 헬프 데스크 구성을 기반으로 하므로 클라이언트가 일부 올바른 프로세스를 "중단"할 가능성이 없습니다. 헬프 데스크 사용자의 티켓 업데이트는 실질적으로 헬프 데스크 이메일 통신 논리 및 설정을 따르도록 설계되었습니다. 유일한 차이점은 사용자가 실제로 티켓의 물리적 형태를 보고 작업할 수 있다는 것입니다.
클라이언트의 전체 사용자를 유지해야 하는 경우 상태 변경(또는 기타 필드 변경)을 완전히 비활성화하는 것이 좋습니다. 이로 인해 일부 내부 프로세스가 중단될 수 있습니다. 업데이트해야 하는 티켓을 추적하는 다른 방법(예: 필드 기준) 사용 작업 마지막 업데이트 (마지막 업데이트 날짜), 최종 업데이트자: (마지막 업데이트를 한 사람), 목록의 티켓에 대한 마지막 댓글을 표시하여 클라이언트가 업데이트를 했는지 명확하게 알 수 있습니다.
약간 더 복잡한 시나리오는 이메일을 통한 티켓 통신을 허용하지만 클라이언트가 전체 사용자로 로그인하도록 허용하는 예 1의 시나리오입니다. 주의해야 할 사항은 다음과 같습니다.
- 클라이언트가 이메일로 응답한 후 상태 변경은 글로벌 헬프데스크 설정에서 설정됩니다.
- 로그인한 사용자에 대한 상태 변경 적용은 없습니다. 항상 상태를 그대로 유지하는 옵션이 있습니다.
이 경우 응답 대기열에 이메일로 업데이트된 상황(예: 특정 상태에 대한 필터)과 애플리케이션 내에서 클라이언트가 업데이트한 티켓(예: 열이 있는 티켓 목록)이 모두 포함되어 있는지 확인해야 합니다. 마지막 코멘트).
주요 내용: 고객은 내부 프로세스에 대해 걱정해서는 안 됩니다. 문제를 제출하고 귀하와 소통할 수 있는 장소만 있으면 됩니다. 프로세스는 귀하에게 달려 있으며 애플리케이션에는 이를 엄격하게 설정할 수 있는 다양한 옵션이 있습니다.
전체 사용자와 헬프 데스크 사용자 혼합
이는 결코 결합할 의도가 없었던 솔루션을 결합하지 말라는 강력한 경고일 뿐입니다. 사용 여부를 결정할 수 있습니다.
- 헬프 데스크 사용자 - 무료, 하드코딩되어 접근이 제한됨, 또는
- 전체 사용자 - 액세스 권한을 결정하는 일반 라이선스 사용자
, 그러나 특히 동일한 클라이언트의 경우 두 가지를 동시에 사용해서는 안 됩니다. 기술적으로 전체 사용자와 헬프 데스크 사용자는 어떤 방식으로도 연결되지 않습니다. 심지어 다른 로그인 페이지도 있습니다. 이들은 작업에 대한 서로 다른 분야(작성자 vs 헬프 데스크 작성자)를 나타냅니다. 따라서 클라이언트에게 두 가지 액세스 옵션을 모두 제공함으로써 클라이언트를 혼동할 이유가 없습니다.
내부 프로세스의 경우 일부 고객에게는 전체 사용자를 제공하고 다른 고객에게는 헬프 데스크 사용자만 제공하는 것이 기술적으로 가능합니다. 그러나 이렇게 하려면 매우 다른 채널의 티켓 처리가 혼동되지 않도록 상담원에 대한 정확한 프로세스 설명과 교육이 필요합니다. 조직적인 어려움으로 인해 클라이언트 액세스에 대해 하나의 옵션만 선택하는 것이 좋습니다.
요약
이전 정보를 다시 소화 가능한 형태로 되돌려 보겠습니다. 다음은 시스템에 대한 클라이언트의 액세스 유형에 따라 발생할 수 있는 상황의 표입니다.
| 애플리케이션에 대한 클라이언트 액세스 | 티켓 제출 옵션(클라이언트) |
티켓(대리인)의 알림 |
티켓 업데이트 옵션(클라이언트) |
우리의 추천 |
| 액세스하지 않음 | 헬프데스크 이메일 주소로 이메일을 보내세요. | 상담원이 티켓의 템플릿을 통해 이메일을 보냅니다. |
|
|
| 전체 사용자 |
|
|
|
|
| 헬프 데스크 사용자 |
|
상담원이 티켓의 템플릿을 통해 이메일을 보냅니다. |
|
|
