Request the evidence and plan quality checks

Understand the method

A data request should explain why each field is needed. “Send everything” increases handling risk and still may omit the one field required to answer the question. Build an evidence inventory: question, required field, available source, grain, owner, expected coverage and action if unavailable. Separate the supplied teaching facts from data you propose to obtain in a real evaluation.

Start with available evidence

The ticket file supplies a unique ticket key, creation and response timestamps, first-resolution timestamp, channel, queue, priority, snapshot status and optional satisfaction. It can support descriptive response timeliness, a mature first-resolution guardrail and respondent-only rating summaries. It cannot show routing exposure, agent workload, paid hours, ticket complexity in detail, reopen history or the true arrival volume of the business. The case notes describe concurrent changes; they are not a row-level assignment log.

Request a dated routing deployment/exposure log if the stakeholder wants an intervention comparison. Ask for staffing and staffed-hours records to understand capacity, plus a longer consistently instrumented baseline and follow-up. A proposed request might cover four comparable weeks before and four after, subject to availability and seasonal context. That is a planning proposal, not evidence that four weeks is sufficient for a powered causal study. A randomized or carefully designed evaluation needs separate feasibility and methodological review.

Specify checks and decisions

For ticket_id, test nonblank uniqueness. If duplicate keys appear, compare records and request authoritative resolution; do not simply keep the first row. For timestamps, test parsing, UTC interpretation, creation within scope, response/resolution not before creation and recorded events no later than the snapshot. For categories, check channel, queue, priority and status against documented allowed values. Count missing values by field and cohort. Reconcile retained records to source records and test outcome maturity.

Each check needs an action. A malformed creation timestamp prevents cohort assignment: quarantine it with a reason and obtain correction. A missing rating does not invalidate a response-time calculation: retain the ticket and exclude the blank only from the respondent-rating denominator. A missing first resolution on a mature ticket is legitimate in this case, where the dictionary defines it as no first resolution recorded by the snapshot. Do not fill it with the snapshot date or claim it was resolved.

The supplied file is intentionally a prepared, internally consistent extract. There are 24 unique ticket keys, 24 observed first responses, six blank first resolutions and eight blank ratings. Those blanks are documented conditions, not deliberate defects to “clean away.” Your task is to write checks and interpret their meaning, not to manufacture a cleaning story.

Keep access proportionate

This exercise contains no names, email addresses or message text. A real response-time analysis usually needs event timings and stable pseudonymous ticket keys, not full customer conversations. Explain the purpose to the data owner, request the minimum necessary fields, agree approved storage/access and a retention period through the organization's process, and avoid sending confidential files through a public enquiry form. These are planning considerations; this course does not certify legal compliance.

Finish with a readiness decision: proceed with a bounded descriptive comparison, pause an unsupported calculation, or ask for a missing dependency. An honest “we can describe the extract, but cannot attribute the change” is a useful outcome. Log unresolved definitions and obtain stakeholder review before moving into a more expensive analysis.