One Screen to Run the Day

One dashboard for a department that runs on live operational data

The operating context

My team verifies education documents. A case arrives against a client, is validated, may require an insufficiency follow-up, may be corrected after a quality finding, and sometimes has to be answered back to the applicant. Every case carries a turnaround commitment that is defined by client, stage and case type, and every client carries a daily target. The department of 80 performers works in parallel across Validation, Insufficiency, Error Correction, Post, applicant responses and additional assigned tasks.

All of that data already existed, and most of it was already live: the validation and insufficiency working sheets carried the case records and the elapsed-time fields that the team itself maintained. The daily reporting workflow, the client and stage SLA rules, the error taxonomy and the daily analytics outputs had been built in earlier work.

What did not exist was anywhere to see those signals together, while the day was still running. The reporting layer was retrospective by design: it described yesterday well and told me nothing about the performer sitting three cases away from a breach at 14:00.

What I built, and what it changed

I built a live operations dashboard in Google Apps Script that gives one manager a single screen for an 80-performer department: who is working, who is not, who is moving too fast, which cases are approaching their turnaround limit, and which errors were made today — with every signal classified automatically by rules I defined.

How it works

The dashboard creates nothing and fetches nothing new. It reads the same live working sheets the team works on, so its figures move as the sheets move — continuously, without a manual refresh. For whole-month views it reuses the daily analytics outputs my reporting workflow already produces. A rules engine sitting between the data and the screen does the interpreting: minutes since the last recorded case completion become a live status; hourly throughput is compared with the expected pace and with the pace at which quality is actually achievable; each open case is measured against the SLA rule for its client, stage and case type; and errors logged today are grouped by stage, field and category.

What I personally contributed

• Requirements. I defined what a supervisor needs to see, in what order, and at what frequency.
• Decision rules. I set the operational thresholds — the 15 and 30 minute status bands, the under-four and over-ten hourly bands against a normal six and a quality-achieving five, the SLA and daily-target logic — and wrote them as explicit, testable statements before any code existed.
• Interface and views. I designed the three-view structure, the layout of the Live Monitor, the per-performer drill-down, the date-range control and the CSV export.
• Implementation. I directed AI-assisted code generation inside Google Apps Script, reviewed the output, tested the rules against the live sheets, corrected the defects I found and extended the application as my own use revealed gaps — the click-through performer view and the productivity trend graph at the top of the board were both added after using it daily.
• Operation. I run the board every day and act on what it surfaces.

What it changed

Before the dashboard, my supervision routine began with assembling a picture: open the live validation sheet, open the live insufficiency sheet, find the quality numbers, check the turnaround report, then reconcile them. Feedback on an error made at 11:00 typically reached me through a report cycle. After it, the board is the first thing I open, the signals are already classified, and the questions arrive while they are still answerable — who has gone quiet, who is rushing, which case is about to expire, which rule did this performer misread this morning.

I estimate that consolidating the required information into one place removed roughly 70% of the time I used to spend searching for the right sheet and re-reading the same numbers. That is my own estimate from daily experience, not a measured time study, and I present it as such. What I can state as observed is behavioural: I now detect an inactive performer within the half hour the rules allow instead of noticing it later in the day; I raise a same-day error with the performer while the case is still fresh; and I catch rushed work before it reaches quality review.

The operating picture was scattered, and the feedback was late

How work actually ran

Each performer works from their own case records, maintained in the live working sheets, across the stages that apply to the client and case type. Two things make a supervisor's job harder than simply counting cases. First, a case is not one event: it is a start, a wait, a decision, and a closure, and the elapsed time that matters includes the waiting. Second, the same performer is doing several kinds of work at once — validation cases, first- and second-level reviews, applicant responses, additional assigned tasks — so a single total tells a manager very little.

Who was affected, and how

Constraints that shaped the solution

• Environment. The work runs entirely inside Google Workspace, and no other programming environment is available to me in the company environment. Google Apps Script with Google Sheets was the only viable host, so the solution had to be a web app that reads the existing sheets rather than a new system with its own database.
• Data governance. The sheets are the operational record of record. Duplicating data into the dashboard would have created a second, competing version of the truth and a new reconciliation burden — the opposite of the goal.
• Scale. With 80 performers across parallel stages, an undifferentiated list is itself a distraction. Any single view has to narrow itself to the part of the department a manager is responsible for.

The data was never the problem — the absence of composition was

My first step was to inventory what already existed rather than to request new data: the live validation and insufficiency sheets and the elapsed-time fields within them, the quality and productivity daily records, the client and stage SLA rules, the daily target per case type and stage, the error taxonomy used in Post, Validation and Insufficiency, and the daily analytics outputs already produced by my reporting workflow. The conclusion was that the department was already data-rich and report-poor: the signals existed, but nothing joined them into a decision.

I did not treat this as a quality problem in the performers, a client problem, or a sheet-layout problem. The evidence pointed to a supervision-visibility problem, and the solution was built to address exactly that.

One application, three views, one rules engine

Design decisions I made

• No new data store. The application reads the live sheets directly. Anything else would have created a second version of the truth and a reconciliation task of its own.
• Rules before screens. I wrote the decision rules as explicit statements first — "active if a case was completed within 15 minutes", "low output if fewer than 4 cases closed in the hour" — so that what the screen shows was a design decision rather than a formatting outcome.
• Same screen, two horizons. Today comes from the live sheets; the month comes from the daily analytics outputs I already generate. One view, one filter, two data horizons.
• Every view exports. Any tab can be exported to CSV for a chosen date range, so the board supports investigation rather than replacing it.
• Progressive detail. The main table stays compact; the depth sits behind a click on the performer's name.

AI-directed development

My method was to specify the operational logic in language a reviewer could check, then direct AI to implement it inside Google Apps Script, then test the behaviour against the live sheets and correct what did not match. The rules, thresholds, SLA logic, view structure and interaction design were mine; the code was produced with AI assistance and reviewed by me against the behaviour I had specified and against the behaviour I could observe in the live sheets. Where output diverged from the specification, I corrected the rule, not the expectation — several of the persistent defects were analytical rather than syntactic, for example the treatment of waiting time inside a case duration and the boundary conditions of the 15 and 30 minute status bands, and the corrections came from testing against real records. Every feature added after the first release — the per-performer drill-down and the productivity trend graph — came from using the board in a real shift and noticing what was missing.

The main screen: a live view of the whole team

The Live Monitor opens on the current shift. A summary band at the top carries the shift-level figures — how many performers are active, how many validation and insufficiency cases are being worked in the hour per performer, and the team's average TAT. Below it, one row per performer shows the day's output split by task type, the total, the hours the performer actually worked, and the live status. A performer name is a link: it opens that performer's cases, errors, average TAT and shift hours for the day. The left rail carries the three dashboard tabs, a date-range control and the CSV export.

What the dashboard decides, and how

The rules are the substance of the project. Each one turns a raw record into a label, and each label has a defined management response. A rule is written so that it can be tested against the sheets: a threshold, a source, and an interpretation.

One click from a row to the case, and from a tab to the month

Performer drill-down

Clicking a performer name in the Live Monitor opens that performer's day: every case worked today with its client, stage, timings and SLA position, every error logged with the field and category, the average TAT, and the true shift hours. The drill-down exists because the summary row tells a manager that something is worth a look, and only the detail tells them what.

Productivity and Quality views

The second and third tabs carry the productivity and quality analysis, including the whole-month horizon. Their underlying structure, indicators and reporting logic are documented in the separate operational-analytics case study, so this case study does not repeat them; what belongs here is the architectural point — the same views are served inside the same application, and the monthly horizon is served from the daily analytics outputs rather than from a new pipeline. Both views accept the same date-range control and the same CSV export as the Live Monitor.

Building inside a fixed environment, one controlled release

Scope, dependencies and constraints

• In scope. A single live web application with three views, automatic rule evaluation, per-performer drill-down, date-range selection and CSV export, reading the existing live sheets and analytics outputs.
• Out of scope by design. No new data collection, no new API integration, no replacement of the working sheets, and no automated messaging to performers or clients — the board informs a human decision, it does not execute one.
• Dependencies. The live validation and insufficiency sheets, the quality and productivity daily records, the client and stage SLA rules, and the daily analytics outputs from the reporting workflow, each documented in the related case studies in this portfolio.
• Constraints. A single approved development environment, no new infrastructure, and confidential operational data that cannot leave the company environment — which is why every interface in this document is an illustrative mockup rather than a screenshot.

Implementation phases

Risks and how I handled them

Turning a daily manual judgement into a standing control

What makes this preventive rather than corrective is timing and standardisation. The manager no longer has to remember to check each signal, and the signals are no longer only available after the day is over. The controls below are the ones I actually implemented; the recommendations are marked as such.

What I checked, and what remains unverified

There is no formal test record from the company environment — verification was performed during development against the live sheets, and the cases below are the checks I actually ran. They are presented as a test matrix reconstructed from that verification, not as an executed QA report.

What I can evidence, and what I would measure next

What I would do differently, and what comes next

Lessons from running it every day

• Composition beats collection. The value was not in any new report but in putting the data I already had into one place and letting rules do the interpreting. Every hour of effort spent on collecting data that already existed would have been wasted effort.
• A rule needs a number and a meaning. "Productivity" told me nothing; "under four cases an hour against a normal six" told me where to look, and the comparison against the quality-achieving pace of five turned a speed metric into a quality signal.
• Waiting time changes the meaning of duration. Because a case's elapsed time includes waiting, a duration rule judged on elapsed time alone can blame a performer for an upstream hold. The drill-down is what makes the rule safe to act on.
• Live beats comprehensive. The most useful output was not the richest one. The per-hour view and the status column are what changed my morning; the month-level filters are convenience.
• Use it, then build it. The features that mattered most — the drill-down and the trend graph — were not in the original specification. They came from operating the tool during a real shift.
• A dashboard is a routine, not a screen. The tool only produces value when it is part of a manager's daily behaviour. My own adoption is the evidence I have; a tool that is demonstrated once and not adopted has produced nothing, however good it is.

Roadmap

What this project shows I can do