What is deliberately wrong with support-tickets

What is deliberately wrong with support-tickets.

4,000 rows, 10 columns, one row per ticket. Four thousand support tickets with free-text subjects, priorities, queue routing, first-response and resolution times, and SLA breaches concentrated in exactly the places you would not guess.

Resolution time is heavily right-skewed and censored: tickets still open at the extract date have a blank resolved_at, and they are disproportionately the hard ones. Report a mean resolution time over closed tickets only and you will publish a number that gets better every time your team falls further behind.

Something to try: Handle the open-ticket censoring properly — survival analysis, not filtering. The SQL playground has it loaded already, and the data explorer will profile every column in one pass if you would rather look before you query.

select *
from support_tickets
limit 20;

The file is generated from a fixed seed, so the CSV you download today is byte-identical to the one from last year. That matters more than it sounds: it means a lesson can say "row 412 is the interesting one" and still be right in eighteen months.

Download it, break it, keep it. CC0 — no attribution required, no account, no email.