Valentina Akpan: Founder, Rellatech. Admin and technical virtual assistant for businesses and startups with teams.
The Challenge
The support team at a telecommunications company managed a high volume of tickets across support, engineering, provisioning, porting, shipping, and accounting. Every ticket carried a long history of customer replies, internal notes, technical updates, attachments, ownership changes, and status moves.
The important details were scattered through those histories. That made it hard to spot tickets with stalled engineering work, customers waiting for an update, missing ownership or priority, incomplete testing, or cases marked solved without real closure evidence. They also had an automated risk-reporting tool, but its flags still needed to be checked against the full ticket history before anyone could trust them.
They needed a single command centre that showed what needed attention, who owned the next action, and whether a ticket was genuinely ready to close.
What I Built
I designed and built a live Google Sheets operations dashboard connected to Zendesk through a read-only API workflow. The system pulls every active ticket and its full comment history, then organizes the information into several purpose-built views.
The dashboard refreshes hourly and updates as ticket activity changes. New comments and ticket changes are added. Tickets are removed from the live view only after Zendesk confirms they are solved or closed. The workflow also tracks meaningful changes in status, ownership, risk, and next action, and redacts any detected passwords, credentials, or API tokens before the data reaches the sheet.
The Executive Dashboard
The main dashboard gives an immediate overview without forcing anyone to read every ticket. It includes:
Active tickets
A live count of all open work, sorted by urgency so the team knows the size of the queue before they start.
High-risk cases
Tickets flagged by the risk tool or by missing information, pulled to the top so they do not get buried.
Customers awaiting follow-up
A clear list of tickets where the last action came from the customer and the next reply belongs to the team.
Unassigned tickets
Open tickets with no owner, which is often where work gets lost.
Tickets ready for closure
Cases that look solved but still need enough evidence before the agent marks them done.
Pending and on-hold work
Items waiting on a customer, vendor, or internal handoff, grouped by how long they have been idle.
Engineering-owned actions
Tickets that need a developer or network engineer, separated from general support work so they get the right eyes.
Missing priority fields
Tickets that lack priority or urgency, which makes triage harder than it should be.
Closure blockers
Cases that are close to done but missing a test, a document, or a confirmation from the customer.
Workload by owner
A simple distribution of open tickets per assignee, used for daily standups and load balancing.
Ticket distribution by status and risk
A snapshot view for managers and leads who need the overall picture without reading every line.
A priority-attention section sits at the top and highlights the tickets that need the most immediate operational action, so the daily review starts in the right place.
Full Ticket History View
I also built a dedicated analysis view containing every public reply and internal note for each active ticket. Each record includes the ticket number and subject, the customer, current status and assignee, priority, comment timestamp, comment author, whether the comment is public or internal, the full comment text, attachments, ticket update time, and a direct Zendesk link.
This lets the team review the complete history without repeatedly opening individual tickets. The risk tool's flags can be verified against the actual conversation instead of acting on a short summary alone.
Operational Follow-Up Views
The dashboard separates tickets into focused working lists so the team can distinguish a real technical gap from a ticket that is simply waiting for customer confirmation:
- ●Engineering follow-ups: tickets that need a developer or engineer to take the next step
- ●Customer follow-ups: tickets where the customer is waiting for a response from the support team
- ●Closure candidates: tickets that may be ready to close, but still need proof before the agent marks them solved
- ●Hourly ticket changes: a feed of meaningful changes in status, ownership, risk, and next action since the last refresh
Automation and Data Protection
The workflow is read-only. It cannot change or close Zendesk tickets. Any customer communication, reassignment, or closure decision remains subject to human review and approval. The dashboard is stored in the company-controlled Google Drive, and the workflow redacts detected passwords, credentials, and API tokens before they are written into the sheet.
This was a deliberate choice. The goal was to support the team's judgment, not to replace it. The dashboard gives them the information they need to make better decisions faster, while keeping the actual customer-facing actions in human hands.
My Role
I led this project as the Client Success Tech Coordinator. The daily check was part of my own workflow, so I designed the dashboard around what I actually needed each morning: a fast way to see active tickets, spot stalled work, verify risk flags, and know who owned the next step. I defined the ticket-review and closure-hygiene framework, mapped the fields required for meaningful daily reviews, designed the dashboard structure and visual hierarchy, established the risk and follow-up categories, created the Zendesk data workflow, built the full-history analysis view, designed the safeguards for credentials and sensitive information, configured the hourly refresh process, validated the dashboard against real support-ticket histories, and moved the completed system into the company-controlled Drive environment.
Outcome
The completed dashboard gives the support team a single source of truth for active-ticket oversight. It makes it easier to find genuine customer and engineering risks, understand a case without relying on a short automated summary, identify the true owner and next action, prepare for daily operations meetings, monitor customer touchbacks, review engineer workloads, maintain stronger closure hygiene, reduce the risk of tickets being overlooked, and preserve human control over customer-facing actions.
A good operations dashboard does not replace the team. It gives them a place to start.
Tools Used
Who This Is For
This case study is worth reading if you are:
- ●A support or operations manager with ticket data spread across too many screens and reports
- ●A team using Zendesk and looking for a lightweight, shareable dashboard without a full BI tool
- ●A business where automated risk flags need human verification before anyone acts
- ●Anyone who needs a daily command centre for tickets that separates queue size from actual priority
Work with Rellatech
I build dashboards and operational views that turn scattered ticket data into a clear daily starting point. If your support team is spending more time finding problems than fixing them, a short call is the fastest way to see whether this approach fits.
Contact MeRelated Services