회사에는 서로 다른 프로세스, 보안 요구 사항 및 워크플로우를 담당하는 다양한 부서가 포함된 여러 조직이 있을 수 있습니다. 이러한 상황에서 Zendesk 인스턴스 하나를 사용하는 것이 적합할지 아니면 여러 개를 사용하는 것이 적합할지 고려하는 것이 좋습니다. 이 문서에서는 Zendesk 인스턴스를 하나만 사용하는 대신 여러 개의 Zendesk 인스턴스를 사용할 때의 장점, 고려 사항 및 결과에 대해 설명합니다. 이 문서에서는 다음과 같은 주제를 다룹니다.

  • 기능 고려 사항
  • 최종 검토를 위한 질문
  • 요약

기능 고려 사항

이 주제에서는 여러 팀에서 다음과 같은 기능을 위해 하나의 Zendesk 인스턴스를 사용할 때의 영향에 대해 설명합니다. 

  • 전체 설정
  • 비즈니스 규칙
  • 연동 서비스
  • 인증 및 액세스
  • 최종 사용자 관리
  • 상담사 권한 및 티켓 액세스
  • 리포팅
  • 웹 위젯(클래식) 및 Chat 위젯
  • Guide

전체 설정

이 섹션에서는 전체 설정 측면에서의 고려 사항에 대해 설명합니다. 

  • 플랜
    Zendesk 인스턴스 하나를 사용하는 경우에는 모든 상담사가 동일한 플랜 유형에서 Support, Guide, Talk 및 Chat을 사용해야 합니다. 특히 Guide의 경우 모든 Support 상담사들은 Guide 상담사여야 합니다. 하나의 팀에서만 Guide를 사용하는 경우에는 비용을 절감할 수 있습니다.

  • 상담사 서명
    Zendesk 계정당 기본으로 사용되는 전체 상담사 서명이 하나 있습니다. 이 문제를 해결하려면 트리거의 서명 또는 유동 마크업 조건을 사용하여 각 팀의 트리거를 사용자 지정할 수 있습니다.
  • 이메일 기본서식
    Zendesk 계정당 기본으로 사용되는 이메일 기본서식이 하나만 있습니다. HTML, CSS 또는 유동 마크업을 지원하는 모든 비즈니스 규칙을 사용자 지정하여 여러 개의 이메일 기본서식을 사용할 수 있습니다. 유동 마크업 및 Zendesk Support 이해하기를 참조하세요.

  • 환영/확인 이메일
    설정 > 계정에 추가된 계정 이름으로 된 기본으로 사용되는 최종 사용자의 환영/확인 이메일이 하나만 있습니다.

  • 하위 도메인
    모든 상담사가 쉽게 기억하고 사용할 수 있도록 하위 도메인을 하나만 사용할 수 있습니다. 상담사 하위 도메인을 팀 이름으로 사용자 지정할 수 없습니다.

  • 누구나 요청 제출 가능 여부
    Zendesk 계정 하나를 모든 사용자에게 개방하거나 모든 사용자에 대해 폐쇄해야 합니다. 이 계정이 개방되어 있으면 누구나 요청을 제출하거나, Guide에 로그인하거나, 위젯을 사용해서 티켓을 제출할 수 있습니다. 이 계정이 폐쇄되어 있으면 Support의 기존 사용자만 요청을 제출하거나 Guide에 액세스할 수 있습니다. 최종 사용자의 Zendesk Support 액세스 및 로그인 방법 구성하기를 참조하세요.

  • 계정 이름
    • 계정 이름은 하나만 있습니다. Zendesk Support에서 내 계정 이름을 변경하려면 어떻게 해야 하나요?를 참조하세요.
    • 형식 있는 자리 표시자를 사용하는 경우 계정 이름을 이메일에서 볼 수 있습니다. 계정 이름은 전송되는 이메일에 포함되며 최종 사용자에게 표시됩니다. 이를 무시하려면 형식 있는 자리 표시자를 사용 중지하고 서식 있는 텍스트를 지원하는 서식 있는 콘텐츠 자리 표시자를 대신 사용해야 합니다. 하지만 이렇게 하면 형식 있는 자리 표시자의 모양이 올바르게 표시되지 않습니다.
    • 마지막으로 계정 이름은 로그인 페이지/프롬프트에 표시되며 편집할 수 없습니다.
  • 사용자가 여러 조직에 속할 수 있도록 허용
    여러 팀에서 Zendesk 인스턴스 하나를 사용하려는 경우에는 전체에 적용되는 설정 하나를 전체 인스턴스에 대해 사용 설정하거나 사용 중지할 수 있습니다.

  • 만족도 설문조사
    만족도 설문조사가 전체 Support 인스턴스에 사용 설정되어 있거나 사용 중지되어 있어도 비즈니스 규칙을 편집하여 특정 그룹에 사용하지 않을 수 있습니다. 자리 표시자를 사용해서 모든 티켓에 대해 만족도 링크를 생성할 수 있습니다. 고객 만족도 평점 자리 표시자 사용하기를 참조하세요.

  • 데이터 내보내기
    티켓, 사용자 및 조직의 데이터 내보내기는 전체 계정에 적용됩니다. 하지만 Zendesk 핵심 API를 사용해서 특정 데이터를 더 가져올 수 있습니다.

  • 태그
    여러 팀이 포함된 인스턴스에서는 여러 워크플로우 또는 리소스에 태그를 재활용하지 않아야 합니다.

비즈니스 규칙

이 섹션에서는 비즈니스 규칙 측면에서의 고려 사항에 대해 설명합니다.

  • 트리거, 자동화, 보기 및 SLA
    • 비즈니스 규칙은 모든 티켓에서 실행되지만, 티켓 그룹 또는 브랜드에 적용되는 조건으로 쉽게 제한될 수 있습니다. 비즈니스 규칙에서 그룹 사용하기를 참조하세요. 관리자의 작업은 전체에 적용되며 관리자는 관리하는 그룹 외부의 다른 그룹에 대한 규칙을 만들 수 있습니다. 이렇게 하면 다른 팀의 티켓과 워크플로우에 영향을 주는 규칙을 편집하는 팀을 관리하는 데 어려움이 있을 수 있습니다. 
    • 동일한 Zendesk 인스턴스 내에 여러 팀이 포함되어 있으면 관리해야 할 규칙 수가 점점 더 늘어납니다. 관리가 복잡해지면 관리 전략과 진행 중인 팀 공동 작업에 변화를 주어야 합니다. 또한 티켓이 올바르지 않은 그룹으로 잘못 라우팅될 위험이 높아지며 이는 SLA에 영향을 줄 수 있습니다.
    • 기밀 또는 보안 정보에 액세스할 권한이 없는 상담사들에게 이러한 정보가 표시된다는 점도 고려해야 합니다. 그룹별로 비즈니스 규칙을 체계적으로 정리할 수 있는 기본적인 방법은 없습니다.
    • 자리 표시자 트리거 또는 자동화를 만들면 비즈니스 규칙을 체계적으로 정리하고 그룹화하는 데 도움은 되지만, 이름에 따라 팀별로 규칙을 편리하게 분류할 수 있다는 점 외에는 특별한 기능이 없습니다.

  • 매크로
    모든 상담사 또는 그룹 내의 상담사들에 대해 매크로 액세스를 구성할 수 있습니다. 자세한 내용은 티켓의 개인용 매크로 만들기를 참조하세요.

  • 티켓 필드 및 티켓 양식
    • 티켓 필드 및 티켓 양식은 전체 인스턴스에 적용됩니다. 모든 팀에서 모든 양식과 필드를 볼 수 있습니다. 사용자 지정 티켓 양식은 여러 팀과 최종 사용자에게 고유한 양식을 사용하려는 경우에 필요합니다.
    • 상담사 인터페이스에서 현재 티켓을 보고 있는 상담사에 따라 사용자 지정 앱에서 특정 필드를 표시하거나 숨길 수 있습니다. 티켓 양식 제한하기 문서에 설명된 사용법을 구현해 보는 것도 고려할 수 있습니다.
    • 헬프 센터 코드를 사용자 지정하여 요청 양식에서 최종 사용자가 편집 가능한 불필요한 필드를 숨길 수 있습니다.

연동 서비스

이 섹션에서는 연동 측면에서의 고려 사항에 대해 설명합니다.

  • JIRA
    Zendesk JIRA v3는 일대일 방식으로 연동됩니다. Zendesk Support 계정 하나에 여러 개의 JIRA를 연동할 수 없습니다.

  • 사용자 지정 연동
    여러 개의 Support 인스턴스를 사용하려면 사용자 지정 연동을 각각 설정하고 구성해야 합니다. 예를 들어 데이터 내보내기를 실행하거나 사용자 데이터베이스에 연결하려면 Support 인스턴스마다 양쪽 모두에 연동을 설정하고 구성해야 합니다.

  • 앱(ZAF)
    각 Support 인스턴스에 앱을 설치하고 구성해야 합니다. 기본 옵션으로는 필요한 요건을 충족할 수 없는 경우 사용자 지정 앱을 코딩하여 사용자 그룹을 확인하고 앱을 표시하거나 숨길 수 있습니다. 기본적으로 그룹 또는 사용자 지정 역할에 따라 앱에 대한 액세스를 지정할 수 있습니다. 그룹별로 앱 표시 대상 제한하기를 참조하세요.

인증 및 액세스

이 섹션에서는 인증 및 액세스 측면에서의 고려 사항에 대해 설명합니다.

  • 기본 인증
    여러 개의 Zendesk 인스턴스를 사용하는 경우에는 인스턴스마다 로그인 정보(사용자 이름 및 비밀번호)가 다릅니다. 상담사와 최종 사용자는 기본 Zendesk 인증을 사용하는 여러 개의 Zendesk 인스턴스에서 두 개의 자격 증명 집합을 기억하고 관리해야 합니다.

  • API 액세스
    API 토큰은 전체에 적용되므로 API 토큰을 사용하는 모든 사용자들이 계정에 있는 모든 리소스와 데이터에 액세스할 수 있습니다.

  • OAuth
    특정 리소스에만 액세스할 수 있도록 OAuth 토큰의 범위를 지정할 수 있지만 상담사 그룹으로만 범위를 지정할 수는 없습니다.

  • 통합 인증(SSO)
    • 상담사 및 최종 사용자 구성에 대한 기본 통합 인증이 전체 인스턴스에 적용됩니다. 모든 팀의 상담사와 최종 사용자를 통합 인증 ID 제공업체에 구성해야 합니다.
    • 사용자가 다른 인증 방법(Zendesk 인증 및 통합 인증)을 사용하도록 할 수 있지만 이 방법은 고객 시스템에 구성해야 합니다. 이야기 중: 고급 인증 옵션을 사용할 준비가 되었나요? 문서를 참조하세요.

최종 사용자 관리

이 섹션에서는 사용자 관리 측면에서의 고려 사항에 대해 설명합니다.

  • 조직 및 사용자 필드
    조직 및 사용자 필드는 전체 인스턴스에 적용되므로 모든 상담사가 모든 필드를 보고 편집할 수 있습니다. 티켓 필드에서처럼 현재 필드를 보고 있는 상담사에 따라 사용자 지정 앱에서 특정 조직/사용자 필드를 표시하거나 숨길 수 있습니다.

  • 조직 관리
    • 조직은 전체 인스턴스에 적용됩니다. 상담사 그룹별로 조직 또는 조직 보기 권한을 분류할 수 없습니다.
    • 조직 티켓 공유 기능의 액세스 권한은 조직에 있는 모든 티켓에 적용됩니다. 이 옵션이 사용 설정되어 있으면 Support 및 Guide를 사용하는 모든 팀의 티켓에 영향을 줍니다.
    • 조직 이름은 다른 이름과 겹치지 않아야 합니다. 사용자가 여러 조직에 속할 수는 있지만 여러 팀을 수용하는 두 개의 조직은 동일한 이름을 사용할 수 없습니다.

  • 최종 사용자 권한 및 액세스
    • 모든 최종 사용자는 전체 인스턴스에 적용됩니다. 인스턴스에서 최종 사용자가 팀 하나에 요청을 보내도록 허용하고 다른 팀에 요청을 보내지 못하도록 할 수는 없습니다.
    • 최종 사용자의 기본 인증 방법 하나만 지원됩니다. 최종 사용자는 모든 헬프 센터 인스턴스에 로그인할 수 있습니다. 이 동작을 무시하는 워크플로우가 있긴 하지만, 높은 수준으로 사용자 지정해야 하고 고객 시스템에 몇 가지 사항을 설정해야 합니다. 

상담사 권한 및 티켓 액세스

  • 최종 사용자를 편집할 수 있는 상담사 권한
    플랜 유형에 따라 몇 가지 고려 사항이 있습니다.
    • 사용자 지정 상담사 역할: 플랜 유형에 사용자 지정 역할이 포함된 경우에는 상담사 그룹 하나만 최종 사용자 프로필을 편집하도록 허용할 수 있지만 다른 그룹은 허용할 수 없습니다. 상담사는 모든 최종 사용자의 사용자 프로필을 볼 수 있습니다. 상담사가 다른 그룹에 있는 티켓에 액세스할 수 있는 권한이 없지만 최종 사용자를 편집할 수 있는 권한이 있는 경우에는 특별한 예외 구성이 필요합니다. 이 구성에는 최종 사용자가 요청한 모든 티켓을 상담사가 볼 수 있는 최종 사용자 가정이 포함됩니다.
    • 상담사 역할: 사용자 지정 상담사 역할이 없는 플랜 유형에서는 모든 티켓에 액세스할 수 있는 상담사만 최종 사용자를 추가, 편집 또는 가정할 수 있습니다.
    • 특별 사용 사례: 한 팀에 소속된 상담사가 다른 팀의 최종 사용자인 경우입니다. 상담사는 헬프 센터를 사용해서 티켓을 제출할 수 없으며, 이로 인해 모든 최종 사용자 양식을 상담사가 사용할 수 없게 됩니다. 그룹 권한과 관계없이 상담사는 본인이 요청한 티켓에 액세스할 수 있으므로 이 상담사가 담당하는 요청자에 대한 모든 내부 커뮤니케이션에 액세스할 수 있습니다.

  • 그룹 관리 및 티켓 액세스
    • 그룹은 전체 인스턴스에 적용됩니다. 여러 팀을 관리하고 그룹별로 티켓 액세스를 제한하도록 그룹을 만들 수도 있습니다.
    • Enterprise 플랜에서는 비공개 티켓 그룹을 만들 수 있습니다. 비공개 티켓 그룹은 비공개 티켓을 볼 수 있는 권한이 없는 상담사에게 비공개 티켓을 완전히 숨겨 그룹 배정에 따라 표시 대상 및 티켓 액세스를 보다 세부적으로 제어할 수 있습니다.
    • 또한 Enterprise 플랜에서는 사용자 지정 상담사 역할을 사용하여 비공개 그룹에 티켓을 배정하는 기능을 포함하여 비공개 티켓 그룹에 대한 상담사 액세스를 제어할 수 있습니다.

리포팅

이 섹션에서는 리포팅에 대한 고려 사항을 설명합니다.

  • 리포팅
    • 인스턴스를 하나만 사용하는 경우에는 한 곳에서 리포팅을 사용할 수 있습니다. 리포팅에 액세스할 수 있는 모든 사용자는 모든 티켓, 사용자 및 조직 데이터를 이용할 수 있습니다.
    • 다른 플랜에서 티켓에 대한 액세스는 리포팅에 대한 액세스를 제어합니다. 리포팅을 보려면 상담사는 모든 티켓에 액세스할 수 있어야 합니다.
    • 기본 리포팅 대시보드는 모든 Support 데이터에 적용되므로, 그룹 또는 몇 가지 티켓 수준 속성(사용자 지정 티켓 필드, 티켓 브랜드 등)별로 나뉜 리포팅은 사용자 지정해야 합니다.

  • 기본 리포팅
    Explore 외의 기본 리포팅 개요, 업무현황표, 지식창고, 커뮤니티, 검색 및 Talk는 전체 인스턴스에 적용되는 애널리틱스입니다.

웹 위젯(클래식) 및 Chat 위젯

이 섹션에서는 웹 위젯(클래식)과 Chat 위젯의 고려 사항에 대해 설명합니다. 메시징 웹 위젯에는 적용되지 않을 수 있습니다.

  • 기본 사용자 지정 항목 및 모양(색상, 위치, 버튼 텍스트)은 전체에 적용됩니다. Widget API를 사용하여 팀당 위젯을 사용자 지정할 수 있지만 이렇게 하려면 사용자 지정 개발이 필요합니다.
  • 각 팀에 맞게 설정된 양식/필드를 사용하려면 티켓 양식이 필요합니다.
  • 위젯의 헬프 센터 검색 기능을 사용하여 전체 지식창고를 검색하거나 지식창고 하나만 검색할 수 있습니다. 하지만 사용자 지정 개발을 통해 검색 결과를 사용자 지정할 수도 있습니다.
  • 위젯에 Chat를 사용 설정하거나 사용 중지할 수 있지만 이 설정은 한 팀에서 Chat을 사용하는 경우에만 의미가 있습니다. Widget API 및 Chat API 사용자 지정 항목을 사용하여 이 설정을 무시할 수도 있습니다.

Guide

이 섹션에서는 Guide 측면에서의 고려 사항에 대해 설명합니다.

  • 상담사의 권한
    • Guide 하나를 여러 팀에서 사용하는 경우에는 공동 전략이 필요합니다. 예를 들어 한 팀에 소속된 상담사가 매니저라면 멀티브랜딩을 사용하고 있더라도 이 상담사는 다른 팀의 콘텐츠를 관리하고 테마를 편집할 수 있습니다.
    • 문서를 만들고 편집할 수 있는 권한은 Support 설정과 Guide 섹션 수준의 설정을 통해 지정됩니다. Zendesk Support 관리자는 기본적으로 Guide 매니저입니다.
    • 사용자 지정 역할이 있는 플랜 유형을 사용하는 경우에는 사용자 지정 역할을 만들고 Guide 매니저 권한을 설정할 수 있습니다. 다른 플랜을 이용하는 경우에는 상담사의 프로필 페이지에서 Guide 매니저 또는 보기 권한자를 제어할 수 있습니다. Guide 역할 이해하기 및 권한 설정하기를 참조하세요.
    • 상담사는 Support에서 보기 권한자로 설정될 수 있지만, 섹션 수준 권한을 가진 매니저 및 상담사에게 설정된 모든 섹션에서 문서를 만들고 편집할 수 있습니다.
  • 최종 사용자 경험
    • Zendesk 인스턴스 하나를 사용하는 경우에는 모든 최종 사용자가 모든 헬프 센터에 로그인할 수 있습니다. 여러 팀에서 Zendesk Support 인스턴스 하나를 사용해서 티켓을 작성할 때 공통되는 최종 사용자가 있을 경우, 팀에서 별도의 여러 Support 인스턴스를 사용할 때 여러 개의 로그인 자격 증명을 사용해야 하는 것과는 달리 이러한 공통된 최종 사용자들은 로그인 자격 증명 집합 하나를 사용하면 됩니다.
    • Support 인스턴스 하나를 사용하면 최종 사용자가 모든 티켓을 한 곳에서 볼 수 있습니다. 하지만 티켓이 다른 브랜드에 있는 경우에는 최종 사용자가 모든 티켓을 한 곳에서 볼 수 없습니다.
    • Support 인스턴스 하나와 연결된 모든 헬프 센터에서 어떤 콘텐츠를 누가 볼 수 있는지 관리하려면 사용자 세그먼트 및 권한 전략이 필요합니다.
    • 마지막으로 한 팀에 소속된 상담사가 다른 팀의 최종 사용자일 경우에는 헬프 센터를 제한적으로만 사용할 수 있습니다. 이러한 상담사가 요청을 보고 제출하려고 하면 Support로 리디렉션됩니다.

최종 검토를 위한 질문

최종 결정을 내리기 전에 다음과 같이 마지막 검토를 위한 질문을 고려해야 합니다.

모든 상담사가 모든 티켓에 액세스할 수 있어야 하나요?

여러 팀에 Support 인스턴스를 하나만 사용하는 경우 모든 티켓에 액세스를 허용할지 여부를 결정할 때 다음과 같은 사항을 고려해야 합니다.

모든 티켓에 액세스 허용:

  • 상담사가 모든 티켓에 액세스할 수 있는 경우, 비즈니스 규칙이 전체 인스턴스에 적용될 때 비즈니스 규칙(보기, 트리거, 자동화, SLA, 이메일 기본서식)을 사용하여 각 팀에 티켓 라우팅을 설정하고 분류하는 작업은 얼마나 확장 가능하며 복잡한가요? 
  • 예를 들어 지원팀과 영업팀 두 팀에서 Zendesk 하나를 사용하는 경우, 각 팀에 대한 최종 사용자 경험을 사용자 지정하려면 각 팀에 개별 자동 응답/댓글 업데이트를 위한 별도의 트리거는 물론 라우팅 트리거가 필요합니다.
  • SLA와 관련하여 티켓이 잘못 라우팅될 위험이 높습니다.

모든 티켓에 액세스 허용하지 않음:

  • 액세스를 제한하려면 그룹 또는 사용자 지정 역할을 구성해야 합니다.
  • 티켓에 액세스할 수 없는 그룹으로 티켓이 잘못 라우팅되지 않도록 하려면 티켓 라우팅을 주의해서 관리해야 합니다.
  • 상담사에게 표시할지 여부는 현재 또는 이전의 다른 요청으로 제한됩니다. 티켓 액세스를 제한하면 리포팅에 대한 상담사의 액세스도 제한할 수 있습니다.
  • 구성에 따라 액세스가 제한된 상담사가 최종 사용자를 가정할 수 있는 경우에는 헬프 센터의 내 활동에서 자신의 그룹 외부에 있는 티켓에 액세스할 수도 있습니다.

한 곳에서 사용자를 관리할 수 있는 전략이나 기존의 사용자 관리 전략이 있나요?

다음은 상담사와 최종 사용자에 대해 고려해야 할 사항입니다.

  • Zendesk 인증과 관련해서 양쪽 인스턴스의 상담사인 사용자는 두 개의 자격 증명 집합을 사용합니다.
  • 통합 인증을 사용하는 경우에는 Zendesk를 양쪽 인스턴스의 서비스 제공업체로 구성해야 합니다. 사용자 지정 사용자 데이터를 전달하는 경우에는 양쪽 인스턴스에서 사용자 또는 조직 필드를 만들어야 합니다. 모든 사용자 지정 사용자 필드, 조직 및 역할의 ID는 고유하므로 고유한 SAML/JWT 어설션을 구성해야 합니다.

최종 사용자에 대한 추가적인 고려 사항입니다.

  • 최종 사용자에게 양쪽 팀(예: HR과 Support에서 하나의 인스턴스 사용)의 헬프 센터 콘텐츠에 대한 액세스 권한을 부여해야 하나요?
  • 최종 사용자에게 모든 HR 및 모든 Support 콘텐츠에 대한 액세스 권한을 부여해야 하나요?  

요약

여기에서는 하나의 인스턴스를 사용하는 경우와 여러 개의 인스턴스를 사용하는 경우를 비교하여 각각의 장점과 고려해야 할 사항에 대해 요약하여 설명합니다.

Zendesk Support 인스턴스 하나를 사용하면 다음과 같은 장점이 있습니다.

  • 통일된 고객 경험
  • 통합된 리포팅
  • 상담사 비용 절감: 상담사가 양쪽 팀에 있는 경우 라이선스가 하나만 필요함
  • 하나의 Support 인스턴스 내에서 부서간에 보다 쉽게 문제를 에스컬레이션하거나 추적할 수 있음
  • 통합된 사용자 관리 및 인증:
    • 한 곳에서 사용자 관리 및 인증
    • 전방위 고객 파악

다음과 같은 사항을 고려해야 합니다.

  • 특정 플랜 유형에서는 티켓에 대한 액세스를 제한하는 것이 복잡합니다.
  • 다른 팀의 최종 사용자인 상담사의 경험이 제한됩니다.
  • 정의된 변경 관리 프로세스와 전략이 필요합니다.
  • 티켓 라우팅 및 비즈니스 규칙 활용이 더 복잡합니다.
  • 사용자 지정 가능한 다수의 Support 기능이 전체에 적용되도록 구성됩니다(예: 인증, 이메일 기본서식, 계정 이름 또는 환영 이메일).

Zendesk Support 인스턴스 여러 개를 사용하면 다음과 같은 장점이 있습니다.

  • 보다 쉽게 분리할 수 있음
  • 다른 팀에 영향을 주지 않고 유연하게 변경 가능
  • 독립적이며 완전하게 사용자 지정할 수 있는 0급/셀프 서비스 및 지식 워크플로우(KCS, Answer Bot, 팀 게시)
  • 각 팀을 위해 완전하게 사용자 지정할 수 있는 맞춤형 최종 사용자 서비스 경험(다른 팀의 최종 사용자인 상담사에게 적합한 최종 사용자 서비스 경험)
  • 팀에서 티켓 액세스 및 보안 제어

다음과 같은 사항을 고려해야 합니다.

  • 여러 인스턴스에 대한 구성 및 분석에 간접 비용이 소요됩니다.

  • 모든 인스턴스에 통합 인증, 앱 및 연동을 구성해야 합니다.

  • 최종 사용자가 요청을 제출하거나 셀프 서비스를 수행하려면 다른 위치로 가야 합니다.

  • Support 인스턴스 간에 티켓을 공유해야 하기 때문에 상담사의 공동 작업 방식이 더 복잡합니다.

  • 두 개의 Support 인스턴스 간에 상담사 충돌 기능이 작동하지 않습니다.

  • Zendesk를 사용하는 두 팀은 티켓 공유를 통해 공동 작업할 수 있지만, 티켓 업데이트는 한 Support 인스턴스의 티켓에서 다른 Support 인스턴스의 티켓으로 비동기 방식으로 진행됩니다.

  • 특정 플랜 유형에서는 비공개 티켓 그룹을 만들어 단일 인스턴스에서 팀별로 티켓 액세스 및 보안을 제어할 수 있습니다.

Zendesk 제공