Fine Tuning: 이상적인 워크플로우 구축 방법

본 Fine Tuning 세션은 다음을 포함한 워크플로우 구축 시 고려할 사항에 대한 것입니다.

• 트리거 및 자동화
• 업무 일정 및 SLA
• 매크로 및 보기

본 Fine Tuning 토론 1부도 확인해 보세요.

Fine Tuning 문서를 더 찾아보려면 Fine tuning 리소스를 참조하세요.

1부: 트리거 및 자동화

지난번 Brick by Brick Fine Tuning에서는 이상적인 Zendes 인스턴스를 구축하는 데 필요한 기본적인 사항과 특정 요구 사항을 충족하도록 구성하는 방법에 대해 다루었습니다. 이번에는 이상적인 워크플로우를 완성하는 데 필요한 나머지 사항들에 대해 자세히 알아보겠습니다.

트리거

트리거는 매우 유용한 기능으로 티켓을 만들거나 업데이트할 때 실행되는 이벤트 기반 시스템 작업입니다. Zendesk에서 트리거를 활용하는 방법에는 여러 가지가 있지만 모두 다음과 같은 몇 가지 카테고리로 요약할 수 있습니다.

• 티켓을 특정 상담사나 상담사 그룹에 배정
• 티켓 필드 값을 변경하거나 태그를 추가/제거
• 사용자나 대상에게 작성 또는 업데이트된 티켓에 대해 알리기
• 사용자나 조직 필드 값 변경(티켓 업데이트 시에만)

잠재적 위험 요소:

Zendesk에는 비활성화하거나 변경할 수 있는 몇 가지 표준 트리거가 있습니다. 실제 업무에 적용하기 전에 트리거 목록을 제대로 확인하지 않으면 원하지 않는 알림으로 이메일이 넘쳐날 수 있습니다.

요청자에게 댓글 업데이트에 대해 알림 기본 트리거는 Zendesk 계정에서 가장 중요한 트리거로서 최종 사용자에게 티켓 댓글을 보냅니다. 이 트리거를 변경하거나 삭제하면 고객과 소통하는 데 영향을 미칠 수도 있으니 주의하세요.

하나의 트리거로 너무 많은 일을 한꺼번에 하려고 하지 마세요. 트리거가 복잡할수록 문제 해결 및 유지 관리가 어려워집니다.

누구나 티켓을 제출할 수 있고 등록이 필요하지 않은 개방형 Zendesk Support 인스턴스가 있는 경우에는 아래의 자리 표시자를 사용하여 티켓이 만들어질 때 실행되는 첫 번째 응답 트리거가 릴레이 스팸의 공격 대상이 될 수 있습니다.

• {{ticket.title}}
• {{ticket.requester.first_name}}
• {{ticket.requester.last_name}}
• {{ticket.requester.name}}

릴레이 스팸은 이메일 주소의 출처를 숨겨 제3자를 가장하기 위해 제3자(이 경우 Zendesk)를 통해 목적지로 메일을 보낼 때 발생합니다. 이러한 자리 표시자는 누구든 원하는 텍스트나 링크를 입력할 수 있는 익명 엔드포인트를 사용하기 때문에 릴레이 스팸의 공격 대상입니다.

계정이 릴레이 스팸의 공격 대상이 되는 위험을 피하려면 최종 사용자 액세스 권한 구성하기에서 설명된 대로 인스턴스를 폐쇄형이나 제한형으로 구성하는 것을 고려하세요. 그렇지 않고 개방형 Zendesk Support 인스턴스를 사용하는 경우에는 첫 번째 응답 트리거의 제목이나 본문에 위에 나열된 자리 표시자를 사용하지 마세요. 대신 정적인 텍스트를 사용하세요. 이렇게 하면 티켓이 만들어질 때 보내는 이메일 알림이 예를 들어 “Dear Amanda Smith”라고 말하려던 인사말을 “Dear www.spam.com”으로 바꾸지 않습니다. 다른 트리거(첫 번째 응답 후)에서는 이러한 자리 표시자를 사용해도 되는데, 그 시점에서는 해당 대화가 이미 진짜임을 확인했기 때문입니다.

성공 사례:

이름 지정 규칙을 일관되게 사용하세요. 이름을 보고 트리거의 기능을 알 수 있어야 합니다. 그러면 기능을 확인하기 위해 각 트리거를 일일이 클릭하지 않아도 되므로 시간이 절약됩니다. 다음은 몇 가지 예입니다.

우선 순위 설정 - 보통

일정 설정 - 북미

그룹에 배정 - 티어 1

요청자에게 댓글 업데이트에 대해 알림

트리거 목록이 한 페이지를 넘는 경우 이름 지정 규칙이 매우 중요합니다. 제목을 기준으로 트리거를 검색할 수 있습니다.

트리거 순서가 중요합니다. 시스템은 티켓이 만들어지거나 업데이트될 때마다 모든 트리거를 검사합니다. 다음과 같은 방법으로 트리거 순서를 정할 것을 제안합니다.

1. 티켓 값 변경/업데이트 - 우선 순위, 상태, 기타 필드 값 등 티켓 값을 변경하거나 티켓을 추가하는 트리거는 첫 번째로 배치해야 합니다. 이렇게 하는 이유는 이러한 트리거가 티켓 배정 및 알림에 영향을 미칠 수 있기 때문입니다.
2. 티켓 배정 - 그룹 및 개별 상담사에게 티켓을 배정하는 트리거는 해당 티켓에서 기타 값을 업데이트하는 트리거 다음에 위치해야 합니다.
3. 알림 - 사용자 또는 대상에게 알림을 보내는 트리거는 목록 마지막에 위치해야 합니다. 이렇게 하는 이유는 알림 이메일을 보내기 전에 시스템에서 필요한 변경을 해야 하기 때문입니다.

위에 나열된 각 카테고리 내에서 구체적인 조건에서 일반적인 조건 순서로 트리거를 배치하는 것이 좋습니다. 이렇게 하면 전체적으로 적용되는 트리거가 대상이 지정된 트리거보다 먼저 실행되는 것을 방지할 수 있습니다.

트리거를 가능한 간단하고 신중하게 유지하세요. 트리거가 간단할수록 확장하거나 관리자를 변경함에 따라 트리거를 유지 관리하기가 더 쉬워집니다.

스스로에게 물어볼 질문:

1. 상담사가 하루 종일 Zendesk에서 라이브 지원을 하나요 아니면 이메일로 지원을 하나요?
2. 어떤 상담사에게 이메일 알림이 필요한가요?
3. 언제 알림을 받아야 하나요?
4. 언제 최종 사용자에게 알림을 보내야 하나요?
5. 워크플로우의 어느 항목을 자동화할 수 있나요?
6. 워크플로우의 어느 항목을 자동화해야 하나요?
7. 알림 트리거의 내용을 어떻게 작성해야 하나요?

여기에서 트리거를 만들고 관리하는 방법에 대해 자세히 알아보세요.

자동화

자동화는 시간 기반 시스템 작업으로 시간 기준으로 실행되며 보통 시간 기반 조건을 가지고 있습니다. 자동화를 사용하여 다음과 같은 작업을 할 수 있습니다.

• 티켓을 특정 상담사나 상담사 그룹에 배정
• 티켓 필드 값을 변경하거나 태그를 추가/제거
• 사용자나 대상에게 작성 또는 업데이트된 티켓에 대해 알리기
• 사용자나 조직 필드 값 변경

자동화로 수행될 수 있는 작업이 트리거로 수행될 수 있는 작업과 동일할 수도 있습니다. 둘 사이의 차이점은 자동화나 트리거가 수행할 수 있는 작업이 아니라 어떤 조건이 이를 발생시키냐는 것입니다. 자동화를 사용하면 이벤트 발생 후 x시간이 되었을 때 또는 이벤트 발생까지 x시간이 남았을 때 시스템 작업을 수행할 수 있습니다.

잠재적 위험 요소:

자동화는 시간당 한 번만 실행됩니다. 따라서 우선 순위가 높은 업데이트의 경우에는 자동화에만 의존하는 것이 어렵습니다. 자동화 실행 후 1분 이내에 티켓이 들어오면 티켓이 만들어진 후 0시간으로 표시되고 1시간 후에 다시 실행될 수 있습니다.

일반적인 시간 기반 조건(예: 만들어진 후 시간이 X보다 오래됨) 대신 구체적인 시간 기반 조건(예: 만들어진 시간이 X임)을 설정하면 티켓이 자격이 되는 시간 중에 자동화가 실행되지 않을 수도 있습니다. 이로 인해 중요한 알림이나 티켓 업데이트를 놓칠 수 있습니다.

성공 사례:

자동화를 만들기 전에 원하는 결과를 얻기 위해 트리거와 자동화 중 어느 것을 사용하는 게 더 나을지 스스로에게 질문해 보세요. 대부분의 경우 트리거는 즉시 실행될 수 있기 때문에 더 효과적입니다.

가능하다면 시간 기반 자동화를 만들 때 다음과 같음 조건 대신 다음보다 큼/작음 조건을 사용하세요. 그렇게 하면 자동화를 실행하지 않고 티켓을 놓칠 가능성이 없습니다. 그렇게 할 때 루프를 방지하기 위해 무효화 조건 및 작업을 추가해야 합니다(필요한 경우 시스템이 경고합니다).

이 작업을 수행하려면 자동화가 실행되기 전에 티켓에 없어야 할 항목(태그 또는 필드 값)을 조건에서 확인한 다음 자동화가 다음 번에 실행될 때 티켓을 무효화하는 변경을 하도록 하세요. 이로써 자동화가 여러 번 실행되지 않도록 보장합니다.

자동화를 사용하여 자동화된 범프, 범프, 해결 워크플로우를 만들 수 있습니다. 이렇게 하면 요청자가 응답하지 않아도 티켓이 한 상태에 계속 머물러 있지 않고 이러한 티켓이 불필요하게 보기를 방해하지 않습니다.

스스로에게 물어볼 질문:

1. 트리거 아니면 자동화여야 하나요?
2. 티켓이 오래되었을 때 이를 알리거나 조치를 취할 시스템이 필요한가요?
3. 티켓이 종료되기 전에 얼마나 오래 해결 상태로 있어야 하나요?
4. 알림 이메일의 내용을 어떻게 작성해야 하나요?

여기에서 자동화를 만들고 관리하는 방법에 대해 자세히 알아보세요.

2부: 업무 일정 및 SLA

업무 일정

업무 일정은 트리거나 자동화만큼 빠르지 않을 수 있지만 여전히 워크플로우에서 필수적인 역할을 할 수 있습니다. 업무 일정을 설정하면 다음을 수행할 수 있습니다.

• 업무 시간 중이나 외에 트리거 및 자동화로 시스템 작업 수행
• 자동화 및 SLA 내에서 캘린더 시간 대신 업무 시간으로 시간 지정
• SLA를 통해 정확한 서비스 목표 제공

잠재적 위험 요소:

목록의 첫 번째 일정은 기본 일정으로 모든 신규 티켓에 적용됩니다. 일정을 재배열할 수 없습니다. 즉, 신규 또는 기존 일정을 기본 일정으로 설정할 수 없습니다. 새 일정을 기본 일정으로 설정하려면 그 위의 모든 일정을 삭제하거나 그 이름 및 특성을 변경해야 합니다.

일정에 휴일을 추가할 수 있지만 이러한 휴일이 다른 해로 이월되지 않습니다. 즉, 매년 휴일을 수동으로 입력해야 합니다.

휴일은 업무 일정에서 제외되는 날짜입니다. 즉, 반나절만 근무하는 경우 업무 시간 기반 SLA가 하루 종일 일시 중지됩니다. (보는 방식에 따라 이런 방식이 유용할 수 있습니다.)

일정을 복제할 수 없습니다. 즉, 매년 각 일정에 대해 수동으로 휴일을 입력해야 합니다.

반드시 시간대를 설정하세요! 일정이 올바른 시간대에 있는 경우에만 유효합니다. 일부 플랜 유형에서는 각 개별 일정에 시간대를 설정할 수 있습니다. 다른 플랜 유형의 경우 여기에서 일정을 설정할 수 있습니다.

성공 사례:

일정을 입력하기 전에 계획을 세우세요. 기본 일정(있는 경우)을 먼저 입력하세요. 이 일정은 기본적으로 모든 신규 티켓에 적용됩니다. 즉, 업무 시간을 사용하여 티켓에 적용된 모든 SLA가 이 일정을 따르게 됩니다.

여러 일정을 사용하는 경우에는 티켓에 일정을 배정하는 트리거를 참조하세요. 예를 들어 티켓이 그룹 x에 배정될 때 일정 x에 배정하는 트리거를 만들 수 있습니다. 모든 일정에 대해 이렇게 하는 경우에는 어떤 일정이 기본값으로 설정되어 있는지는 중요하지 않습니다.

일정은 복제할 수 없지만 휴일은 복제할 수 있습니다. 여전히 수동으로 입력해야 하지만 최소한 복제하여 날짜를 변경할 수 있습니다. 이는 정기 휴일을 입력하는 가장 좋은 방법입니다.

휴일을 만들 때 하루 중 일부 시간만 설정할 수 없고 하루 전체가 일정에서 제외됩니다. 이러한 날을 사용하면 볼륨이 적어질 가능성이 있습니다.

스스로에게 물어볼 질문:

1. 최종 사용자를 연중무휴 지원하나요?
2. 특정 시간이나 특정 날에만 대화 가능한 팀이 있나요?
3. 단축 업무를 하는 휴일이 있나요?
4. 몇 개의 서로 다른 일정을 만들어야 하나요?

Team 플랜에서는 업무 일정을 사용할 수 없습니다. 여기에서 일정을 만들고 관리하는 방법에 대해 자세히 알아보세요.

SLA 정책

많은 기업이 특정 이벤트에 대해 고객이 예상할 수 있는 시간에 대한 공약을 가지고 있습니다.

Zendesk 서비스 수준 계약은 서비스 목표를 티켓에 추가함으로써 티켓에 우선 순위를 정할 수 있도록 합니다. 사용할 수 있는 목표는 다음과 같습니다.

• 첫 번째 응답 시간(티켓을 만든 후부터 상담사의 첫 번째 공개 댓글 시간까지 걸린 시간)
• 요청자 대기 시간(신규, 등록 및 대기 상태에서 티켓이 소모한 총 시간)
• 상담사 작업 시간(신규 및 등록 상태에서 티켓이 소모한 총 시간)
• 다음 응답 시간(최종 사용자가 댓글을 달고 상담사가 다음 공개 댓글을 달 때까지 걸린 시간)
• 정기 업데이트(상담사가 공개 댓글을 달고 상담사가 다음 공개 댓글을 달 때까지 걸린 시간)
• 일시 중지 가능한 업데이트(티켓이 신규, 등록 및 대기 상태일 때 상담사의 각 공개 댓글 사이의 시간으로 티켓이 보류 상태에 놓일 때마다 일시 중지됨)

잠재적 위험 요소:

Zendesk SLA에서는 시스템 우선 순위 필드를 사용해야 합니다. 티켓에 우선 순위가 배정되지 않으면 SLA 정책이 적용되지 않습니다.

SLA가 업무 시간을 기반으로 하며 여러 개의 일정이 있는 경우에는 반드시 각 티켓에 적절한 일정이 적용되도록 해야 합니다. 별도로 지정하지 않으면 각 티켓은 기본 업무 일정을 사용합니다.

상담사가 티켓을 만들면(요청자를 최종 사용자로 설정하는 경우에도) 바로 첫 번째 응답 시간 목표가 충족됩니다. 이는 티켓 설명이 상담사의 첫 번째 공개 댓글로 간주되기 때문입니다. 이 목표는 바로 충족되므로 티켓이 처리된 것으로 나타납니다.

내부 티켓에 대해서는 다음 응답 시간 목표가 작동하지 않습니다. 목표는 최종 사용자 댓글과 상담사의 다음 공개 댓글 사이의 시간을 측정하므로 이 목표는 상담사가 요청한 모든 티켓을 무시합니다.

하나의 정책에서 모든 목표를 사용하지 마세요. 요청자 작업 시간과 상담사 작업 시간 중 하나를 선택하거나 둘 다 선택하지 마세요. 동일한 정책에서 이 두 개 목표를 모두 사용하는 것은 불필요하며 작업을 지나치게 복잡하게 만듭니다.

SLA 위반은 트리거에서 사용할 수 있는 적격 이벤트로 사용할 수 없습니다. 다시 말해서, 즉각적인 위반 알림 트리거를 구축할 방법이 없습니다.

성공 사례:

6가지 서로 다른 목표를 사용할 수 있습니다. 그러한 6가지 모두를 한 정책에서 사용할 필요가 없으며 사용해서도 안 됩니다.

첫 번째 응답 시간 목표는 모든 신규 티켓이 합당한 시간 내에 처리되도록 보장하는 훌륭한 방법입니다. 다음 응답 시간 목표 역시 같은 이유로 중요합니다. 일반적으로 동일한 정책 내에서 FRT(첫 번째 응답 대기 시간) 목표와 거의 비슷하거나 동일하게 NRT 목표를 구축하는 것이 좋습니다.

상담사 작업 시간과 요청자 대기 시간 둘 다 티켓을 해결하는 데 걸리는 시간을 측정하므로 둘 중 하나를 선택하거나 둘 다 선택하지 마세요. AWT는 상담사의 관점에서 이 시간을 측정하므로 티켓이 대기 및/또는 보류 상태일 때 일시 중지됩니다. RWT는 요청자의 관점에서 이 시간을 측정하므로 티켓이 보류 상태일 때만 일시 중지됩니다.

정기 업데이트와 일시 중지 가능한 업데이트 둘 다 상담사의 공개 댓글 사이의 시간을 측정하므로 둘 중 하나를 선택하거나 둘 다 선택하지 마세요.

스스로에게 물어볼 질문:

1. 특정 서비스 목표를 달성해야 하는 계약적 책임이 있나요?
2. 내부 서비스 목표가 있나요?
3. 여러 정책이 필요한가요 아니면 하나의 포괄적 정책이 필요한가요?
4. 티켓의 우선 순위를 어떻게 정하나요?
5. 티켓 해결에 걸리는 시간과 관련하여 서비스 목표가 있나요?
   있다면 요청자와 상담사 중 누구의 관점에서 측정해야 할까요?
6. 모든 고객에게 연중무휴 지원을 제공하나요?

캘린더 시간이나 업무 일정 중 어느 것을 기준으로 목표를 확인하시겠어요?

Team 플랜에서는 SLA 정책을 사용할 수 없습니다. 여기에서 SLA를 만들고 관리하는 방법에 대해 자세히 알아보세요.

3부: 매크로 및 보기

매크로

매크로는 상담사가 활성화하는 스크립트로 티켓에서 한 번에 여러 작업을 수행할 수 있습니다. 매크로는 상담사가 할 수 있는 작업만 할 수 있으며 상담사가 티켓을 업데이트한 후에만 티켓 변경 내용이 저장됩니다.

매크로를 사용하면 클릭 수를 줄여 상담사의 생산성을 높일 수 있습니다.

매크로는 다음과 같은 작업을 할 수 있습니다.

• 댓글 텍스트 추가
• 티켓 필드(드롭다운 및 확인란만) 업데이트
• 티켓 태그 추가 또는 제거
• 참조 추가
• 담당자 변경
• 티켓 제목 설정
• 티켓 댓글에 첨부 파일 추가

잠재적 위험 요소:

매크로는 기본적으로 상담사를 위한 바로 가기입니다. 매크로는 현재 사용자가 할 수 있는 작업만 할 수 있습니다. 예를 들어 상담사에게 티켓 태그를 편집할 수 있는 권한이 없는 경우 해당 상담사가 매크로를 실행할 때 매크로는 태그를 추가하거나 제거하지 않습니다.

매크로는 텍스트, 여러 줄 텍스트, 날짜, 숫자 또는 정규 표현식 티켓 필드를 업데이트하지 않습니다.

성공 사례:

드롭다운 필드와 마찬가지로 매크로를 중첩할 수 있습니다. 매크로를 중첩하면 매크로를 체계적이고 깔끔하게 정리 및 유지할 수 있습니다.

한 번의 티켓 업데이트에서 여러 개의 매크로를 실행할 수 있습니다. 이는 모든 가능한 상황에 대해 매크로를 구축할 필요가 없다는 뜻입니다. 단순하게 유지하세요.

자리 표시자를 사용하세요! {{requester.first_name}}으로 댓글을 시작하면 가장 일반적인 응답도 개인화된 것처럼 보입니다. 티켓의 제목을 설정할 때 자리 표시자를 사용할 수도 있습니다.

모든 상담사나 특정 그룹에 매크로를 배정할 수 있습니다. 매크로가 소수의 상담사에게만 표시되어야 하는 경우 혼란을 줄이기 위해 그러한 상담사만 볼 수 있게 매크로를 제한하세요.

매크로를 검색할 수 있습니다. 티켓 내부의 매크로 메뉴에서 매크로 제목을 입력하기 시작하면 메뉴에서 매크로가 필터링됩니다.

매크로를 쉽게 검색할 수 있도록 하려면 이름 지정 규칙을 만들고 그 규칙을 따르세요.

매크로를 사용하여 여러 티켓을 한 번에 업데이트하세요. 여러 티켓 옆의 확인란을 선택하고 오른쪽 위에 있는 검은색 티켓 편집 버튼을 눌러 보기 화면에서 매크로를 적용하고 제출하면 됩니다.

매크로와 함께 나란히 트리거와 자동화를 사용할 수 있습니다. 예를 들어 트리거를 즉시 활성화하는 태그를 추가하는 매크로가 있을 수 있습니다. 모든 가능성에 대해 생각해 보세요!

스스로에게 물어볼 질문:

1. 최종 사용자가 티켓을 제출하는 데 있어 가장 일반적인 문제가 무엇인가요?
2. 댓글 텍스트에 무엇을 작성해야 하나요?
3. 매크로가 공개 또는 비공개 댓글을 남겨야 하나요?
4. 어떤 상담사가 어떤 매크로에 액세스해야 하나요?

매크로는 모든 플랜에서 사용할 수 있습니다. 여기에서 매크로를 만들고 관리하는 방법에 대해 자세히 알아보세요.

 

보기

이제 이제 워크플로우에서 가장 중요하다고 할 수 있는 보기에 대해 살펴보죠. 보기는 상담사가 어떤 티켓을 볼 수 있는지, 그리고 어떤 순서로 작업해야 하는지를 결정합니다.

보기는 폴더가 아니라 저장된 검색 또는 필터링된 데이터베이스입니다. iTunes의 스마트 재생 목록이라고 보면 됩니다.

잠재적 위험 요소:

너무 복잡한 보기를 만들지 마세요. 보기에 조건이 많을수록 결과가 더 많이 필터링됩니다. 이는 유리할 수도 있지만 동시에 위험하기도 합니다. 조건이 너무 많으면 티켓을 놓칠 수도 있기 때문입니다.

보기가 너무 많으면 상담사가 원하는 방식으로 티켓의 우선 순위를 정하지 못할 수도 있습니다. 보기를 꼭 필요한 것에 연결함으로써 그런 일을 피하세요.

브라우저를 보기에 열어 두면 자동으로 업데이트되지 않습니다. 보기를 클릭하거나 페이지를 새로 고칠 때마다 업데이트됩니다.

보기는 페이지당 최대 30개의 티켓만 표시할 수 있습니다. 보기가 올바르게 정렬되지 않으면 중요한 티켓을 놓칠 수도 있습니다.

성공 사례:

매크로와 마찬가지로 모든 상담사나 특정 그룹에 보기를 배정할 수 있습니다. 대부분의 경우 각 그룹에 사용자 지정 보기를 만들면 각 상담사가 관련 정보만 보게 되므로 매우 효율적입니다.

SLA를 사용하는 경우 다음 SLA 위반별로 보기를 정렬하는 것이 좋습니다. 이렇게 하면 모든 티켓이 결국 맨 위로 필터링됩니다.

Play 버튼을 사용하세요! 보기 페이지의 오른쪽 위에 있는 Play 버튼을 사용하면 보기에서 사용 가능한 다음 티켓으로 바로 이동합니다.

스스로에게 물어볼 질문:

1. 티켓 우선 순위가 어떻게 정해져야 하나요?
2. 각 그룹은 어떤 티켓을 볼 수 있나요?
3. 티켓을 어떻게 분류하나요?

여기에서 보기를 만들고 관리하는 방법에 대해 자세히 알아보세요.