Hundreds of tickets a launch, finally counted

It saves nobody a day of work

That is the point. It answers a question the operation could not answer about itself.

Two readings of one launch

I took the correction tickets from one brand and built two views of them. The first counted, page by page, how many corrections it took, how many were priorities, how many became tickets, how many were bugs. The second measured time: how long the corrections took, split by type, by priority and by kind of page. Between them they were the first numbers anyone had for what a launch actually costs.

From a tab to a panel to an app

That became a panel for one person's work, week to week and month to month: pages updated, SLA, delivery time, mistakes, and the blockers that came from outside the team. Then it became a web app, built in Apps Script, where everyone sees their own tickets against KPIs we chose ourselves.

Two of them carry most of the weight. Right the first time counts the tickets that needed no rework, which is a different question from how fast they closed. And a complexity point system prices the work, so a team holding twenty hard tickets stops looking lighter than a team holding thirty easy ones.

What it gives a manager

Productivity by quadrant, which stakeholders generate the most rework, which type of task eats the most time, where the delays are actually coming from. None of that makes a single process faster. What it does is make the operation arguable: feedback stops resting on impression, a headcount request stops resting on tone, and the conversation between areas has something in it besides what everyone remembers.