Valentina Akpan: Founder of Rellatech, providing administrative and operations support to executives, founders, business owners and teams. Her background combines technical support, customer success, administration and operations.
·
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 one view that showed what needed attention, who owned the next action, and whether a ticket was ready to close.
What I Built
I designed and built a 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, so it shows the queue as it stood at the last refresh, and Zendesk stays the system of record. New comments and ticket changes are added on each run. Tickets leave the dashboard only after Zendesk shows them as solved or closed. The workflow also tracks meaningful changes in status, ownership, risk, and next action, and redacts the passwords, credentials, or API tokens it detects 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 count of open work as of the last hourly refresh, 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. Redaction covers the patterns the workflow detects, not every possible format, which is why the sheet stays inside the company's own Drive.
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 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 one hourly view for active-ticket oversight, with Zendesk remaining the system of record. 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.
The team now starts each day from one view of stalled tickets, who owns each one, the follow-ups due, and what is blocking closure.
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 one daily view of tickets that separates queue size from priority
Need help with similar work?
Tell me which responsibilities or processes need attention, who is involved and any upcoming deadlines. I provide administrative and operations support, including the connected technical work within our agreed scope.
Request a free consultationRelated Services