Choosing what to show
The team needed a current view of tickets, SLAs, and alerts. Compiling the information manually meant moving between systems, and the figures could change while the report was being assembled.
I built a Python pipeline to collect and transform data through the source APIs, with Plotly for the charts. The dashboard tooling varied by client environment and display setup.
02
Live demo: operations dashboard
SLA compliance
N/A
Open tickets
N/A
First response
N/A
Table view
The figures here are generated in your browser. The original dashboard read ticket, SLA and alert data from client systems, none of which can be published. What is shown is the layout and the thresholds, which is what the work actually was.
Designing for the office
The display was intended for passive monitoring. People needed to read it from across a room, so I kept the layout simple and limited the metrics to questions the team was already asking.
That constraint helped decide what to leave out. Detailed investigation could stay in the source tools; the shared screen provided a view of service performance without someone having to compile a report first.