Queue Site Operational Dashboard

A large technical-support operation had useful queue and agent-status data, but most people who could act on it lacked practical access. Phones showed limited context, the richer interface was restricted, and supervisors often learned about problems through later reports.

I built a lightweight internal Queue Site from scratch. Automated telephony exports fed internally hosted HTML/CSS team views that refreshed automatically.

Approximately 75 agents, leads, and supervisors used it to coordinate availability, adjust staffing and breaks, and spot unusual call spikes sooner. The project predates ChatGPT; its value came from proportionate product judgment.

The operation already had data. It lacked shared in-shift visibility. Retrospective reports could not help resequence a break, move coverage, check an unusually long status, or investigate a surge while it was happening.

The solution also could not simply grant everyone the restricted management tool.

I did not control the telephony platform. The solution had to use an available export, separate team views, refresh automatically, and stay clear during a busy shift.

Status duration can support coordination but can be framed as surveillance. The design focused on context that helped employees and leaders protect coverage and recognize abnormal conditions.

Contemporaneous evidence describes me as building the Queue Site from scratch without guidance. I identified the need, used Avaya’s built-in export automation, consumed the data from an internal location, built HTML/CSS pages, implemented refresh and team navigation, hosted it internally, and improved it.

The original source and server configuration are unavailable, so I do not infer a database, another language, a particular server, or undocumented polling.

I reused the existing export rather than replacing Avaya or expanding restricted access. A simple browser layer was proportionate, team views reduced noise, and automatic refresh kept the screen useful.

An older written accomplishment record documents improvement from approximately 120-second refresh to approximately 5-second refresh. That record governs the metric; I do not reconstruct the exact cadence.

The product connected information to decisions: agents coordinated breaks, leads checked long states, supervisors moved resources, and unusual spikes could trigger wider investigation.

Avaya telephony platform → automated export → designated internal folder → HTML/CSS team views → internally hosted Queue Site → automatically refreshed browser.

The site exposed team-relevant context. It did not replace the source system, change routing, or become a workforce-management suite.

Approximately 75 people used the site. Agents gained coverage context; leaders gained in-shift visibility; managers could move resources or resequence breaks; and spikes could signal a wider issue.

Written evidence records refresh improving from approximately 120 seconds to approximately 5 seconds. No recovered telemetry supports SLA, abandonment, occupancy, adherence, uptime, or financial claims.

It changed when information became useful: during the shift, not only after it.

I continued improving refresh behavior and operational usefulness. Surviving evidence does not establish the exact lifespan but documents an important operating tool, not a prototype.

Avaya automated exports, an internal data location, and internally hosted HTML/CSS pages with automatic refresh. The small stack fit the problem.