Define scope, grain and fair comparison windows

Understand the method

Scope turns a broad request into a reproducible population. It specifies what one row represents, which rows belong, which time boundaries apply and what the analysis excludes. Without that contract, two analysts can produce different numbers while both believing they answered the same question. Write the population before choosing a chart or calculation.

One ticket, one row

In tickets.csv, each row represents one fictional support ticket, identified by ticket_id. It does not represent a message, a unique customer, a staff member or a routing event. A customer could create multiple tickets in a real system; this file contains no customer identifier. Do not rename ticket counts as customer counts. The supplied 24 rows are a deliberately constructed teaching extract, not a random sample that represents Harbor's whole business.

Retain the source unchanged and record the filename, version, row count and dictionary. All timestamps are UTC. The extract snapshot is 22 June 2026 at 00:00 UTC. “Week 1” means tickets created at or after 1 June 00:00 and before 8 June 00:00. “Week 2” means at or after 8 June 00:00 and before 15 June 00:00. These half-open boundaries include the full final day without needing a guessed final second.

Choose the right time population

A creation-cohort report follows tickets arriving in each week. A completion-period report counts work resolved during a week, including older tickets. These answer different questions. For this task, compare creation cohorts. A ticket created late in Week 1 and resolved in Week 2 still belongs to Week 1. Assigning it by resolution date would change the denominator and confound arrival performance with backlog clearance.

For a 72-hour outcome, each eligible ticket needs at least 72 hours of follow-up at the snapshot. Check that created_at plus 72 hours is no later than the cutoff. The supplied cohorts satisfy that rule. In a live rolling report, recent tickets might be immature; report them separately rather than treating every unresolved recent ticket as a failure. Do not discard old unresolved tickets simply because they have no resolution timestamp: after a full observation window, they have no recorded first resolution within that window under this case's dictionary.

State inclusions and exclusions

Include the supplied general and billing tickets in email and chat within the creation window. There are no documented test tickets, spam or duplicates in this prepared teaching extract. Do not invent exclusions to improve the rate. In a real system, ask for documented flags and a consistent exclusion rule. Log excluded counts by reason and reconcile source rows to retained rows.

Comparable duration is not the same as comparable conditions. Both cohorts cover a full seven-day window, but channel composition changes. Routing exposure, staffing and demand complexity are incompletely observed. Plan an overall comparison plus channel-level checks. A group with no eligible tickets should have count zero and rate unavailable, not a fabricated zero-percent performance score. If you later change periods or eligibility, update the contract and recalculate every dependent denominator.

Write a scope boundary

A suitable statement is: “This exercise describes the supplied ticket cohorts and recorded timestamps only. It does not estimate unique-customer satisfaction, staff productivity, routing causality or financial return.” Such a boundary prevents an accurate small table from becoming a misleading broad claim.