Admin Pro Tip: Team Hierarchy - How to Build It the Right Way – Available ApS

A well-designed team hierarchy in Zendesk is a central prerequisite for an effective support organisation. It is not just an exercise in organising names into lists; it is the foundation for how tickets flow, how performance is measured, and how support scales as the company grows. An unsuitable hierarchy creates confusion and bottlenecks and makes it difficult to extract meaningful data. A well-functioning hierarchy creates clarity and efficiency and provides the necessary framework for delivering a strong customer experience.
Experience from many Zendesk instances shows that the same mistakes are often repeated, and that there are at the same time clear patterns for what works when the setup is correct. This article gathers these experiences into a practical guide for building a team hierarchy that works now and is at the same time robust enough to grow with the organisation. The focus is on central decisions about groups, organisations and light agents, as well as concrete examples and checklists for direct use.

The Foundation: Groups vs. Organisations - When Should You Use Which?

This is the most fundamental and often misunderstood part of the Zendesk hierarchy. Confusing groups and organisations is the cause of many hierarchy problems. The distinction is, however, simple once the principle is in place.

What Are Groups?

Groups can be regarded as the internal team structure. They function as "boxes" where agents are placed in order to define areas of responsibility and route tickets to the right people.

Purpose: Internal organisation of agents.
Use: Routing tickets, assigning ownership, distributing work.
Visibility: Only visible to agents and administrators in Zendesk. Customers cannot see which group a ticket belongs to.
Examples:
- Level 1 Support
- Level 2 Teknisk Support
- Billing Team
- Customer Success Managers
- Nordic Support
- Premium Support

An agent can be a member of several groups, but a ticket can only belong to one group at a time (the group that the assigned agent belongs to). This is crucial for routing and reporting. When a trigger, for example, says "Assign ticket to 'Level 2 Teknisk Support'", it is pointing to a group.

What Are Organisations?

Organisations can be regarded as the external customer structure. They function as "boxes" where customers (end users) are typically placed based on the company they work for.

Purpose: To group external customers.
Use: Sharing tickets between colleagues from the same company, organisation-specific SLAs, organisation notes.
Visibility: Customers can see that they are part of an organisation, and can see colleagues' tickets if "shared tickets" is enabled.
Examples:
- ACME Corporation
- Globex Inc.
- Initech
- Premium Kunder
- Partnere

When an end user is created in Zendesk, they can be assigned to an organisation. The most important function is "shared tickets": if two colleagues from ACME Corporation contact support, agents can see both tickets and understand the connection. This reduces the risk of several agents working on the same underlying problem for the same company without knowing it.

The Golden Rule: Groups = Internal, Organisations = External

If only one rule is to be remembered, it is this one. It is the quickest way to decide what to use in a given situation.

Property	Groups	Organisations
Purpose	Internal team organisation	External customer organisation
Who is in it?	Agents	End users (customers)
Primary function	Routing and assigning tickets	Sharing tickets and SLAs
Example	"Teknisk Team"	"Microsoft"
Question to ask	"Who should work on this ticket?"	"Who is the customer?"

A classic mistake is to create a group for each customer. This creates an unmanageable number of groups, no agent can be a member of all of them, and routing becomes unrealistic. Organisations should be used for that purpose. Conversely, it is a mistake to use organisations to define internal teams, since agents cannot be assigned to an organisation.

Light Agents - A Hidden Tool (and a Double-Edged Tool)

Light agents are an underrated and at the same time often misused feature in Zendesk. Used correctly, it is a powerful tool for involving expertise without disrupting the ticket flow. Used incorrectly, it creates bottlenecks and a lack of clarity.

What Is a Light Agent?

A light agent is a user type with limited access. Light agents can:

See tickets where they are CC'd.
Add internal notes (private comments).
Edit their own comments.
See and add tags.

A light agent cannot:

Be assigned a ticket (assignee).
Edit public comments that they did not write themselves.
Use apps that require editing permissions.
Follow tickets (the CC function is used instead).

Light agents function in practice as contributors/consultants, not as owners of tickets.

Green Flags: When Light Agents Make Sense

Light agents are often used successfully in the following scenarios:

Subject Matter Experts (SMEs): A senior developer who is not meant to handle day-to-day support, but who is to contribute technical answers to complex bug reports. Instead of a full agent licence, they are CC'd on the relevant ticket. The answer is given as an internal note, and the Tier 1 agent conveys the answer to the customer.
Managers and middle managers: A team lead who wants transparency into the team's tickets without taking part in the day-to-day routing. As a light agent, the manager can follow along, add guiding notes and monitor quality without taking tickets out of the queue.
Special roles: People from legal, marketing or sales who occasionally need to see a ticket or give input. There is no need for full access, but there is a need for context and the ability to add internal comments.
External consultants: When collaborating with freelance developers or external consultants on a specific project, light agent access can be given to the relevant tickets. This provides the necessary insight without access to the whole of Zendesk.

The common denominator is that the role should contribute knowledge, not own the process.

Red Flags: When Light Agents Should Be Avoided

Misuse typically arises when light agents are used as a cheap replacement for full agent licences.

As the primary contact: Product specialists are made light agents, and a rule CC's them on all tickets about a particular product. Since light agents cannot be assigned tickets, tickets end up in "Pending" and wait for a reply from a person without formal ownership. This creates bottlenecks.
To save licence costs: There is a need for 10 agents, but 8 full licences and 2 light agent licences are purchased. The result is that the two cannot take tickets from the queue, the workload is distributed unevenly, waiting times increase, and full agents become frustrated. If a person is to handle work in the queue, it requires a full agent licence.
Overuse: If too many internal roles are light agents, responsibility becomes unclear. An agent can CC several light agents, and it becomes unclear who is expected to reply. The number should be limited to the roles where it is necessary.

A light agent can never be the last person in a chain. The role can only be that of a contributor. Workflows should be designed with this as the premise.

Skill-Based Routing - Magic or Nightmare?

Skill-based routing can sound like the optimal solution: each ticket is sent automatically to the most qualified agent. In practice, however, it can quickly develop into an administrative nightmare that makes the system unmanageable and inefficient.

What Is Skill-Based Routing?

In Zendesk, skill-based routing is typically implemented via a combination of:

Custom fields: A field of the type "Multi-select" or "Checkboxes" on the agent's profile for selecting competencies (e.g. "Dansk", "Engelsk", "Billing", "Teknisk", "Produkt A").
Triggers: A trigger that runs on incoming tickets, assesses the need (e.g. via tags or another custom field) and updates the ticket with a "skill" tag.
Omnichannel routing (if available): A more advanced feature that can take account of agents' capacity and skills directly in the routing engine.

When It Works: Simple and Clearly Defined

Skill-based routing can be effective when the setup is kept simple. The key is few, broad and non-overlapping skills.

Good example: Language routing

Skills: Dansk, Svensk, Engelsk.
Setup: A trigger checks the language in the incoming email or chat. If the language is Danish, the tag skill_dansk is added. Another trigger sees skill_dansk and assigns the ticket to an agent in the Level 1 Support group who has Dansk as a skill.
Why it works: Skills are typically exclusive, broad and easy to administer, and they solve a concrete problem.

Good example: Premium routing

Skills: Premium Support.
Setup: Customers from the "Premium Kunder" organisation are automatically tagged premium_support. A trigger ensures that tickets with this tag are routed to agents in the Premium Support group who have the Premium Support skill.
Why it works: The skill is binary and simple to maintain.

Red Flag: The Complexity Trap

Problems arise when too many skills are combined (the "complexity matrix").

Bad example: Hyper-specific skills

Skills: Dansk, Engelsk, Svensk, Norsk, Billing, Teknisk Level 1, Teknisk Level 2, Produkt A, Produkt B, Produkt C, API Integration, Premium Support.
Setup: A trigger has to find an agent with both Dansk, Teknisk Level 2 and Produkt B.
Why it becomes a nightmare:
1. Tickets get stuck: If the only agent with the combination is absent, the ticket is not assigned and may remain in "Unassigned".
2. Maintenance is unrealistic: New agents require many manual skill additions. Role changes require ongoing updates. Products that are phased out require clean-up of skills and triggers. It becomes an administrative time bomb.
3. Reporting becomes unmanageable: Performance for, say, "Teknisk Level 2" becomes difficult to isolate if tickets are at the same time split across many product tags.

Recommendation: Use groups to define primary areas of responsibility (e.g. Teknisk Level 2, Billing). Use skill-based routing only for 1-2 cross-cutting, broad competencies, typically language. If there is a need to distinguish between products, tags on tickets and views for agents can be used instead. This is more flexible and scalable.

Practical Examples: From Small to Large

Theory is useful, but the following shows how the setup can look in practice across growth phases.

Example 1: The Small Startup (10 agents)

Goal: Simplicity and speed. Avoid over-engineering.

Groups (2-3):
- Support: Main group for 8 agents who handle all first-time enquiries.
- Engineering: 2 developers who are assigned bug reports and technical escalations.
Organisations:
- Used only with a clear B2B focus with few, large customers. With B2C, it can be skipped at the start, since the administration often exceeds the value.
Light Agents (1-2):
- CEO/CTO as light agent, so that critical tickets can be CC'd and followed without taking part in the day-to-day queue.
Skill-Based Routing:
- Not necessary. Instead, use a trigger that routes all tickets to Support, and another trigger that routes tickets with the bug_report tag to Engineering.

Why it works: The setup is minimal and clear. Reporting is simple: performance for Support as well as the number of bugs. Maintenance is easy, and the setup can be scaled moderately.

Example 2: The Medium-Sized Company (50 agents)

Goal: Structure and specialisation. Focus on efficiency at a larger scale.

Groups (4-6):
- Nordic Tier 1: First line for Danish, Norwegian and Swedish customers.
- EMEA Tier 2: Specialised technical support for complex tickets.
- Customer Success: Relationships with larger customers.
- Billing & Finance: Billing and payment questions.
Organisations:
- Central. Create one organisation per B2B customer.
- Consider tags or custom fields for further segmentation (e.g. Enterprise, SMB).
- Set up different SLAs based on organisation type.
Light Agents (5-10):
- Product managers for feedback and product questions.
- Legal for approving replies to sensitive questions.
- Team leads for insight into the team's performance.
Skill-Based Routing:
- Language routing makes sense. Create a Language skill on agents (Dansk, Tysk, Fransk etc.) and use triggers to route tickets correctly to Nordic Tier 1 based on language.

Why it works: The structure reflects specialisation, and ownership is clear. Reporting per team becomes meaningful, and performance can be assessed across customer segments.

Example 3: The Large Corporation (200+ agents)

Goal: Scalability, global coverage and fine-grained control. The hierarchy must be robust and logical.

Groups (15+):
- Structured geographically and functionally, e.g.:
  - APAC Tier 1
  - Nordic Tier 1
  - DACH Tier 1
  - Global Tier 2 - Hardware
  - Global Tier 2 - Software
  - Global Premium Support
  - Strategic Accounts - CSMs
  - Billing EMEA
  - Billing APAC
Organisations:
- Entirely central. Used for customer hierarchies, where a global customer can have a main organisation with sub-organisations per country or department.
- SLAs are complex and vary according to contracts.
- "Shared tickets" is crucial for handling large, global customers.
Light Agents (20+):
- Used across departments (Legal, Marketing, Engineering, Product, Compliance) for expert input without disrupting the ticket flow.
Skill-Based Routing:
- Still kept simple. Primarily language routing and identification of Premium Support agents. Other specialisation is handled via the group hierarchy.

Why it works: The setup is large, but logical. Responsibility per group is clear, routing is predictable, and reporting can be broken down by region, product line and customer type without becoming useless.

Common Hierarchy Mistakes and Solutions

The following mistakes often recur, together with corresponding ways of avoiding them.

Mistake 1: "Organisations for Everything"

Problem: In a B2C company, an organisation is created for each customer "to keep track of them".
Consequence: No real benefit, since "shared tickets" provides no value. It creates thousands of unnecessary organisations, makes administration of end users heavy, and makes meaningful SLAs difficult.
Solution: In B2C, the organisation field should not be used. Segmentation can instead be done via custom fields on the end user (e.g. Customer_Tier, Signup_Date). Organisations are primarily relevant for B2B.

Mistake 2: "The Enormous Group"

Problem: One group, Support, with all 50 agents.
Consequence: Unclear ownership, difficult distribution of work and worthless reporting, since performance cannot be separated between new and experienced agents. Fast agents take the easy tickets, while difficult tickets are left lying.
Solution: Split the group. Even with uniform tasks, splitting can be done by experience (Tier 1, Tier 2) or geography (Support - EMEA, Support - APAC). This improves routing, distribution of work (e.g. round-robin within a group) and reporting.

Mistake 3: Overlooking Light Agent Limitations

Problem: A workflow sets a ticket to "Pending" and waits for a reply from a specific person who is set up as a light agent.
Consequence: The workflow breaks, since light agents cannot be the assignee and therefore cannot "solve" the ticket by taking ownership. The ticket may remain in "Pending" until a full agent steps in.
Solution: Workflows must be designed based on what light agents can and cannot do. If a role is to take part in a formal approval process where a ticket waits for input, it requires a full agent licence. If the input is informal, a light agent can be used, but a full agent must own the ticket all the way through.

Mistake 4: Agents in Too Many Groups

Problem: An agent is a member of 10 groups because they "can do a bit of everything".
Consequence: Lack of clarity for the agent, unclear routing (which SLAs and views apply), and unclear reporting. Performance is spread across many teams and becomes difficult to assess.
Solution: A rule of thumb is membership of 1-3 groups: one primary and possibly 1-2 secondary for specific purposes (e.g. Escalations). Too many areas of responsibility can indicate a need to look at role descriptions rather than the Zendesk setup.

Red vs. Green Flags - Checklist

The checklist can be used to assess whether the hierarchy is becoming unmanageable, and whether there is a need for a revision.

Red Flags: Warning Signs of an Unmanageable Hierarchy

🚩 More than 10 active skills in the skill-based routing setup.
🚩 The "Support" group has more than 20 agents.
🚩 Agents are members of 5 or more groups.
🚩 An organisation has been created for each customer in a B2C business.
🚩 The routing logic requires a trigger to find an agent with 3 or more specific skills.
🚩 Light agents are used as a replacement for full agents in order to reduce costs.
🚩 It is not possible to see who owns a ticket by opening it.
🚩 New agents spend a whole day getting groups, skills and views set up correctly.
🚩 There are several "workaround" rules (e.g. manual assignments) because automatic routing does not work.

Green Flags: Signs of a Healthy and Scalable Hierarchy

✅ There is a clear, written policy for when to create a new group vs. a new organisation.
✅ Each group has a clearly defined purpose and a responsible manager.
✅ Most agents are members of 1-2 groups.
✅ Skill-based routing (if used) consists of 2-3 broad, non-overlapping skills (typically language).
✅ Light agents are used for a limited number of well-defined consultant roles.
✅ It is simple to pull reports for performance per team/group.
✅ A new agent can explain the hierarchy and their role in it in under 5 minutes.
✅ The hierarchy is reviewed and revised once a year (or more often with rapid growth).
✅ There is a clear and predictable process for how a ticket moves from creation to closure.

A well-functioning team hierarchy is not a one-off task, but an ongoing process that develops in step with the organisation. With clear principles for the distinction between groups and organisations, a deliberate use of light agents and a healthy scepticism towards over-complexity, a foundation is created that supports stable operation, scalability and a better experience for customers.