Zendesk Permission Control Organization and Implementation Examples in Multiple Call Center Environments

Introduction

Recently, there has been an increase in companies operating multiple call centers and support bases. When different organizations exist by region or product under the same brand, proper access control for tickets handled by each organization becomes an important issue. This article organizes the access control features provided by Zendesk (organizations, groups, brands, custom roles, private ticket groups, and brand membership). Additionally, we propose implementation guidelines for environments where multiple call centers exist within the same brand as an example of utilizing these features.

What is Zendesk

Zendesk is a cloud-based platform that comprehensively manages customer service operations. It provides features such as ticket management, knowledge base, community forums, live chat, and phone support to streamline corporate customer support operations.

Target Audience

• Management in internal system development, IT departments, and customer support departments
• Administrators with Zendesk configuration authority who design and operate the organization's overall support structure
• Those who understand basic Zendesk operations and seek solutions for advanced access control and multi-location operation challenges

Overview of Zendesk's Access Control

Zendesk's access control features vary depending on the subscription plan. The major features are organized by plan below.

Features Available in Plans Below Enterprise

• Organization: Customer grouping
• Group: Agent assignment control
• Brand: Customer segment separation

Features Added in Enterprise and Higher Plans

• Custom Role: Detailed permission settings
• Private Ticket Group: Control of visibility/invisibility
• Brand Membership: Cross-brand access management

Basic Concepts of Access Control

Zendesk's access control consists of the following three aspects:

• Visibility Permissions: Which tickets can be viewed
• Edit Permissions: Whether ticket content can be modified
• Administrative Permissions: Whether system settings and other users can be managed

Organization

Organizations are a mechanism for logically grouping customers. Customers belonging to the same organization can view each other's tickets, making it useful for ticket management by corporate customers or departments.

• Ticket sharing options between organization members
• Ticket viewing restrictions from outside the organization
• Application of organization-specific fields or tags

Group

Groups are a mechanism for categorizing agents by function or region and controlling the scope of tickets they handle. Multiple agents belong to each group, and tickets are assigned at the group level.

• Automatic ticket assignment rules
• Ticket sharing settings within groups
• Designation of escalation target groups

Brand

Brands are a mechanism for building independent support environments for different products, services, or regions. Each brand has its own help center, email address, and design, enabling separation of customer and agent touchpoints.

• Automatic brand assignment when tickets are created
• Application of brand-specific workflows and triggers
• Brand-specific aggregation in reporting

Custom Role

Custom roles are a mechanism for defining organization-specific roles beyond the standard Admin, Agent, and End-user. Detailed permission settings at the feature level are possible for each role.

• Detailed control of ticket editing permissions
• Access range specification for admin screens
• Viewing permissions for reports and dashboards
• Control of visibility/invisibility of other agents' tickets

Private Ticket Group

Private ticket groups are a mechanism where only agents belonging to specific groups can view and edit tickets. They are used for highly confidential tickets or closed responses by specific teams.

• Complete invisibility from agents outside the group
• Visibility changes when transferring tickets between groups
• Settings where even administrator privileges are subject to access control### Brand Membership

Brand Membership is a mechanism that controls which brands agents can access. In organizations operating multiple brands, it allows flexible configuration of agent responsibilities.

• Administrator access across all brands
• Specialist agent access limited to specific brands
• Quality manager limited access for audit purposes

Use Case Example: Permission Separation in Multiple Call Centers

Requirements and Design Policy

As an example, we'll consider a case where multiple call centers exist under one brand. We'll formulate implementation policies based on the following requirements.

Basic Requirements

• Ticket invisibility between centers
• Cross-supervision function for supervisors

Design Policy
Based on Enterprise plan usage, we'll adopt a permission design that combines private ticket groups and custom roles. Each call center will be configured as an independent group, with special roles set for cross-supervision.

Implementation Steps

Private Ticket Group Settings

Create five private ticket groups corresponding to each call center.

1. Select Admin Center > Members > Teams > Groups and click "Add Group"
   
2. Set a group name of your choice and check Make private
   
3. Add agents from the right menu "Add group members" and save
   

Custom Role Settings

Create a supervisor role for cross-supervision.

1. Select Admin Center > Members > Teams > Roles and click "Create role"
   
2. Set a name of your choice and configure the following items
   • Permissions > Tickets > Accessible tickets: All tickets within this role's brand membership, including those in private groups
   • Members > Access to end-user profiles: Add, edit, and delete all end users
   • Reports and analytics > Reporting permissions > View, add, and edit### Operation Verification

I created a ticket assigned to "Call Center A" and verified the functionality by changing the role of the test account.

Standard Role
The test account's role was set as "Light Agent".

1. When belonging to the "Call Center A" group, the ticket appeared in the list
   
2. When removed from the "Call Center A" group, the ticket no longer appeared in the list
   

Custom Role
The test account's role was set as "Cross Call Center Account".

1. When belonging to the "Call Center A" group, the ticket appeared in the list
   
2. Even after being removed from the "Call Center A" group, the ticket continued to appear in the list
   

Summary

In this article, I organized the permission control features of Zendesk and proposed implementation strategies for multi-call center environments. While plans below Enterprise can implement basic permission control through organization, group, and brand functions, Enterprise and higher plans allow for more strict and flexible permission settings through custom roles, private groups, and brand membership. As demonstrated in the example, when operating multiple call centers within the same brand and wanting to both prevent ticket visibility between centers while maintaining cross-center supervision capabilities, the combination of private groups and custom roles proves effective.