In the role of Zendesk administrator, it is easy to assume that it is obvious what is best for the support team. There may be a gut feeling, agent feedback and individual tickets that appear unnecessarily complex. Gut feelings, however, are not a strategy. Guesswork can lead to misguided investments, demotivated teams and, ultimately, a poorer customer experience. Zendesk Explore acts as a counterweight to this by supporting decisions based on data. This article describes how administration can be moved from reactive work based on assumptions to proactive work based on concrete measurements.
Why data > guesswork in Zendesk administration
Before starting work on dashboards and metrics, it is central to understand the shift from guesswork to data. It is not only about visualisations, but about changing the basis for decisions in the support organisation.
From gut feelings to measurable results
Subjective statements such as:
- "It always takes too long to get an answer from the finance department."
- "It feels as though the team has become slower in the past month."
…may contain a kernel of truth, but are difficult to translate into systematic actions.
What does "always" mean? What does "slower" mean? Without data, the dialogue easily turns into an exchange of opinions, where the most convincing voice carries the most weight. Decisions about changes to workflows, purchasing apps or reorganisations risk being based on anecdotes.
With data, the conversation changes, e.g.:
"Tickets tagged with venter_på_finans have, on average, a waiting time of 48 hours, which is 300% higher than the average internal reply time. This negatively affects the overall First Reply Time. Can the cause of the long waiting time be investigated?"
The statement thereby becomes a fact with a measurable consequence. This makes action possible, e.g. dialogue with the finance department based on data, measurement of the effect of changes and documentation of the value of initiatives.
The consequences of guesswork
Administration based on guesswork can have concrete negative consequences:
- Misplaced resources: Time and budget are spent on problems that are not necessarily the most pressing. For example, investment may go into training in "effective communication", while the real cause is a defective workflow that costs 15 minutes per ticket.
- Demotivation among agents: When agents' real challenges are overlooked in favour of management's assumptions, trust can decline, and productivity and morale are negatively affected.
- Lack of ROI: Return (ROI) is difficult to document without a baseline. For example, time savings from a new macro package cannot be proven without measurements before implementation.
- Degraded customer experience: Slow responses, inconsistent quality and unresolved problems can often be traced back to internal inefficiencies that have not been identified and corrected.
The benefits of a data-driven culture
A data-driven approach typically produces the opposite outcome:
- Precise interventions: Efforts can be targeted where the effect is greatest, e.g. ticket types with high handling time, agents in need of support, or customer groups with low satisfaction.
- Objective conversations: Performance discussions can be based on facts rather than feelings, which supports a fairer and more constructive culture.
- Demonstrable value: Business cases for tools or more resources can be substantiated by showing the impact on key metrics such as CSAT or resolution time.
- Continuous improvement: Data creates a feedback loop: a change is implemented, the effect is measured, learning is captured, and the process is repeated.
The most important dashboards to start with
Explore can seem overwhelming with its many reporting options. A practical approach is to start simple and build up gradually. The three dashboards below cover three central perspectives: agent performance, ticket volume and customer satisfaction.
Dashboard 1: Agent Performance Dashboard
The dashboard is used as a daily tool for team leads and provides a quick overview of performance per agent and team. The purpose is not surveillance, but to identify trends, highlight successes and detect the need for support.
Key metrics
- Tickets handled (per agent): Bar chart with the number of resolved tickets per agent in a selected period (e.g. the past 7 days). Indicates productivity, but should be seen together with other metrics.
- Average handling time (per agent): Average time from assignment to closure. Indicates efficiency, but should not be used in isolation, since a low time may also be due to compromised quality.
- Customer satisfaction (CSAT score): Average CSAT for tickets handled by the agent. A central metric, since it reflects the customer's experience.
- First Reply Time (FRT): Average time to the first reply on a new ticket. Critical for the customer's first impression.
- First Contact Resolution (FCR): The proportion of tickets resolved in the first interaction without follow-up. High FCR indicates competence and efficiency.
Application
The dashboard is typically reviewed in weekly team meetings. First, overall team performance is assessed, then the individual level. With low CSAT, the other metrics can indicate causes, e.g. high volume and low handling time, which may point to haste. This can form the basis for coaching with a focus on quality. Conversely, high CSAT and low productivity can indicate a need for tools or training in faster handling of complex cases.
Dashboard 2: Ticket Volume & Trends Dashboard
The dashboard provides a strategic overview of what comes in, when it comes in, and how it develops over time. It supports capacity planning and resource allocation.
Key metrics
- New tickets over time: Line chart with the number of new tickets per day/week/month. Used to identify seasonal fluctuations, sudden increases (e.g. product problems) and growth trends.
- Tickets by group/support level: Distribution of new tickets across support groups (e.g. Tier 1, Tier 2, Technical Support). Supports the assessment of work distribution.
- Tickets by channel: Distribution by channel (email, chat, web form, voice). Shows customers' preferred contact routes and resource needs per channel.
- Tickets by brand/organisation: Shows which brands or B2B customers generate the most enquiries, which can indicate a need for training or specific problems.
- Top 10 ticket topics (via tags): Bar chart with the 10 most-used tags on new tickets in a period. Provides a quick picture of the most frequent enquiries.
Application
The dashboard is often a fixed item at monthly meetings with management. An increase in tickets with the tag login_problem can, for example, be used for proactive dialogue with the product team: "There is a 20% increase in login problems over the past month. Are there any changes in the latest release?" This moves the function from reactive to proactive. Historical data is also used to forecast busy periods (e.g. after a product launch) and to plan staffing.
Dashboard 3: Customer Satisfaction (CSAT) Dashboard
The dashboard focuses on understanding the causes of satisfaction and dissatisfaction and acts as a barometer for the customer experience.
Key metrics
- Overall CSAT score over time: Line chart with the average CSAT (e.g. proportion of "good" ratings) over time. Used to track weekly and monthly trends.
- CSAT score per agent: Identifies variation in customer experience at the agent level.
- CSAT score per group: Shows which teams deliver the best customer experience and can support knowledge sharing.
-
CSAT score per ticket topic (via tags): Comparing CSAT across tags shows which topics drag the score down. Example:
fakturering(invoicing) with low CSAT can indicate problems in the invoicing workflow or knowledge level. - Dissatisfied comments (word cloud): A word cloud based on comments from "bad" ratings gives quick insight into frequent complaints such as "slow", "waiting time" and "complicated".
Application
The dashboard is used to find explanations for changes in CSAT. When the overall CSAT drops, the first step is to investigate whether it relates to a specific agent, a team or a type of enquiry. The word cloud can provide the qualitative explanation that the numbers alone do not show. Insights are used for targeted training, e.g. training in setting expectations and providing status updates if "waiting time" features heavily.
Bonus: SLA Performance Dashboard
When working with Service Level Agreements (SLAs), an SLA dashboard is central to following up on customer commitments.
Key metrics
- SLA compliance percentage: Overall proportion of met SLAs.
- SLA performance per metric: Compliance per SLA metric (e.g. First reply, Next reply, Resolution time).
- SLA performance per group: Compliance distributed across teams.
- SLA breaches over time: Line chart with the number of breaches over time; an increase indicates a clear warning signal.
Common errors in reporting and how to avoid them
Access to data is not the same as correct interpretation. Below are typical pitfalls and ways to avoid them.
Error 1: Measuring too many things at once
Dashboards can become overcrowded with many graphs, colours and numbers, which often means they are not used.
How to avoid it:
- Start with a purpose for each dashboard.
- Clarify which specific question the dashboard should answer.
- If the dashboard answers more than 2-3 central questions, it is often too complex.
- Keep it simple and suitable to be understood in under 60 seconds.
- Use detailed reports for deep dives when needed.
Error 2: Ignoring context
Numbers without context provide information, but not insight. Example: "FRT has increased by 2 hours" requires an explanation (product release, public holiday, holiday period, system downtime).
How to avoid it:
- Compare with the previous week, the same week last year and target values.
- Note external factors that may affect the numbers.
- Add a short context section to weekly reports, e.g.: "Week 32 was affected by the holiday period, which lowered ticket volume by 15%."
Error 3: Incorrect use of time frames
Time frames that are too short can lead to misleading conclusions. A single day's CSAT can be heavily affected by a few dissatisfied customers.
How to avoid it:
- Use rolling averages, e.g. "the past 7 days" rather than "yesterday".
- For strategic decisions (e.g. capacity planning), typically at least 3-6 months of data are used to identify real trends.
Error 4: Blindly trusting the standard reports
Standard reports in Explore are a starting point, but are not tailored to specific workflows, tags or internal SLAs.
How to avoid it:
- Use standard reports as inspiration.
- Build your own reports that reflect concrete workflows and goals.
- Establish a consistent and well-defined tag strategy.
- Ensure data quality (tags, custom fields, etc.), since reports otherwise become useless: "garbage in, garbage out".
5 must-have metrics for support teams
There are many metrics, but the following five cover central aspects of support performance and balance efficiency, quality and customer experience.
1. First Reply Time (FRT)
What it is: The average time to the first public reply on a new ticket.
Why it is important: FRT affects the customer's first impression. A quick response signals that the enquiry has been received and is being handled, and reduces impatience and uncertainty.
Target: Reply within the defined FRT SLA, typically within 8 working hours. Both the average and the median are monitored, since individual complex cases can distort the average.
2. Average Handle Time (AHT)
What it is: The total time from assignment to closure, incl. research, customer communication, internal communication and internal notes.
Why it is important: A direct measure of efficiency and cost per ticket. It should not be used in isolation, since a focus on low AHT can lead to inadequate responses or premature closure.
Target: Used as a benchmark rather than a strict KPI. Sudden increases can indicate complex cases or knowledge gaps and are used as a basis for coaching.
3. Customer Satisfaction (CSAT)
What it is: The proportion of customers who give a "good" rating in the CSAT survey after a closed ticket.
Why it is important: The direct voice of the customer and a central indicator of helpful and satisfactory service. High CSAT correlates with loyalty.
Target: Over 90% CSAT. The trend is considered more important than individual levels, with a focus on ongoing improvement week by week.
4. First Contact Resolution (FCR)
What it is: The proportion of tickets resolved in the first interaction without the customer replying again or creating a new ticket about the same topic.
Why it is important: Drives both satisfaction and efficiency. Follow-ups cost time and create frustration. High FCR indicates competent agents, a good knowledge base and efficient processes.
Target: Measurement can be difficult in Explore. One method is a custom dropdown field where the agent marks whether the case was resolved at first contact. Target: over 75% FCR.
5. Reopen Rate
What it is: The proportion of closed tickets that the customer reopens.
Why it is important: Indicates that the problem was not solved correctly the first time. A high reopen rate can point to competence gaps, unclear responses or technical problems that have not been addressed.
Target: Monitored continuously, with a response when it increases above a fixed threshold (e.g. 5%). Reopened tickets are analysed for common causes.
How to use data to optimise workflows
Data should not only be observed, but translated into action. Below are four examples of how data from Explore can be used to optimise workflows in Zendesk.
Case 1: Identifying bottlenecks in the ticket flow
The problem: A perception that many tickets "got stuck", without a clear cause.
The data analysis: A report showed the average time in each status (New, Open, Pending, Solved). The time in "Pending" was almost as high as in "Open".
The action: Further analysis showed that over 60% of "Pending" tickets were waiting for a reply from a specific internal department. The data was presented in a meeting, and an internal SLA was established. In addition, an automation was created that sent a reminder to the internal group if a ticket had been "Pending" for more than 24 hours.
The result: The average time in "Pending" fell by 40% within a month, and the overall resolution time fell markedly.
Case 2: Optimising macros and automations
The problem: Many macros were old, overlapping, and it was unclear which were being used.
The data analysis: A report showed macros and the number of uses in the past month. 20% of the macros accounted for 80% of the uses (Pareto). Many macros had never been used.
The action: A clean-up was carried out: unused macros were deleted, popular macros were reviewed for efficiency and accuracy, and less popular but useful macros were assessed for merging or updating.
The result: The macro menu became clearer, it became quicker to find the right macro, and responses became more consistent, which saved time per ticket.
Case 3: Proactive training of agents based on data
The problem: Training was often generic and based on assumptions about needs.
The data analysis: Data from the Agent Performance Dashboard was combined with ticket topics. An agent with low CSAT had many low-rated tickets related to a specific complex product.
The action: Coaching was targeted at the product: "There are challenges with tickets related to 'Product X'. An hour is set aside to review the most common problems." A workshop for the whole team was also held, since several agents had challenges in the area.
The result: The agent's CSAT rose markedly in the following weeks. The training became more relevant and effective.
Case 4: Adjusting SLAs based on real data
The problem: SLAs had been set long ago based on an estimate. The SLA for "Next reply" was often not met.
The data analysis: A report showed the actual reply time on customers' follow-up messages. The 2-hour SLA was unrealistic; the average was closer to 5 hours, partly because follow-ups often required deep research.
The action: The data was presented to management, and the SLA for "Next reply" was adjusted to 8 working hours. At the same time, the SLA for "First reply" was tightened, and the focus was on clear expectation-setting about reply times for follow-ups.
The result: SLA compliance improved markedly. The overall customer experience was improved through more realistic expectations, and the stress level among agents fell.
Red flags: When reporting becomes too complex
Too much or overly complex reporting can become a burden. Below are typical warning signs.
Red flag 1: Dashboards that take minutes to load
If a dashboard takes more than 10-15 seconds to load, it is often too complex, and usage drops.
- Cause: Too many complex metrics on large volumes of data over long periods.
- Solution: Split into smaller dashboards, use Explore's pre-aggregated data where possible, and optimise queries.
Red flag 2: Too many pie charts
Pie charts are often difficult to read, since angles and sizes are hard to compare quickly.
- Cause: They are easy to make and often look "nice".
- Solution: Use bar charts for category comparison and line charts for trends. Only use pie charts for very simple proportions (e.g. "good" vs. "bad" CSAT ratings).
Red flag 3: Nobody knows what the numbers mean
A dashboard can be well designed, but without a shared understanding of the metrics, it will not be used.
- Cause: A lack of communication and training; an assumption of a shared "data language".
- Solution: Add a glossary or explanatory notes to the dashboard (text fields in Explore). When introducing new dashboards, go through the metrics, their meaning and relevance. Incorporate this as part of onboarding.
Red flag 4: Data silos and conflicting reports
Different systems can show different numbers, e.g. the number of customers or CSAT, which creates uncertainty.
- Cause: Different systems, definitions and a lack of alignment.
- Solution: Establish shared definitions (e.g. "customer", CSAT measurement), work towards integration where possible, and be aware of differences as well as able to explain them.
Green flags: Healthy data practices
Signs of a well-functioning data-driven approach include the following.
Green flag 1: Simplicity and clarity
Dashboards are easy to read, have a clear purpose, and the most important insights are quickly apparent without the need for data expertise.
Green flag 2: Regular review process
Reviewing dashboards is a fixed part of weekly and monthly meetings, which shows that data is used on an ongoing basis and is embedded in the organisation's practice.
Green flag 3: Shared ownership of data
Data is used widely: team leads for coaching, agents for their own performance, and management for strategic planning. This supports accountability and shared goals.
Green flag 4: Data leads to action
Dashboards and reports are considered successful when they lead to concrete changes, e.g. updating a macro or restructuring a team. Data acts as a catalyst for improvement.
Conclusion: From data to knowledge
Zendesk Explore is a powerful tool, but the value only emerges when raw data is translated into meaningful knowledge and then into action. This requires patience, curiosity and a willingness to challenge assumptions.
A practical approach is to start simple with three basic dashboards: Agent Performance, Ticket Volume & Trends and CSAT. The five central metrics should be understood, including their interrelationships. At the same time, it is important to be aware of pitfalls and to maintain healthy data practices when green flags appear.
A data-driven approach can change support work from reactive to proactive, strengthen efficiency and quality, and ultimately improve the customer experience through more targeted and documentable decisions.