Wait-time SLA tracking

You say tickets sit unassigned until a customer complains; Chip builds a live queue, a history of every wait & a dashboard that puts the longest wait first.

Use case

Tickets sit unassigned and I only hear about it when a customer complains. I want to see what's waiting right now, and whether we're getting slower or faster over time.

What Chip asked

Chip checked the workspace first and found nothing about wait times, then asked the one question that decides the shape of the build:

Chip: When a ticket gets picked up, do you still care how long it waited, or only about what's waiting right now?

Reply: Both. Right now so I can go poke someone, and the history so I can see the trend.

That answer is why there are two tables: what is waiting now & a history of every wait. Chip wrote the intent down before building.

What got built

• The data, kept in three shapes. What is waiting now, the history of every wait with how long it took & an hourly picture by priority: the typical wait, the slow tail & the longest.
• The automations that keep it current. One watches tickets start & stop waiting; the other rolls the history up every hour. Running either again changes nothing.
• A dashboard. A "Waiting now" count up top, a trend line & a table of waiting tickets sorted so the longest wait is first, because that is the one you go & chase.
• Documents that explain it, one per table, automation & screen.

Chip rehearsed both on real past ticket changes, then switched them on.

How it runs now. Open the dashboard & the longest wait is at the top; the trend line says whether the team is getting faster. The history keeps building on its own.

Try it

Paste this into Build:

Tickets sit unassigned and I only hear about it when a customer complains. I want to see what's waiting right now, and whether we're getting slower or faster over time. I want both: the live queue so I can chase the longest wait, and the trend by priority.

The last sentence answers the question Chip asked above.