Every data team recognises the ticket that reads “need numbers for the board deck.” Three days later a table arrives, the requester says it is not what they meant, and the cycle restarts with a bit less goodwill on each side. The fault is rarely carelessness. The request itself was underspecified, and no one at either end had a template that forced the missing details into the open. This post diagnoses the usual failure modes in data requests and proposes a compact written brief as the remedy, aimed at analysts, engineers and the stakeholders who depend on them.

The problem: a request that cannot be completed, only guessed at

A data request is a small contract. Someone needs an output, someone else produces it, and both assume the same finish line. When the contract is verbal or a single sentence, the producer fills gaps with plausible guesses. Some guesses are right. The wrong ones surface late, usually in front of an audience.

Symptoms are consistent across companies:

• The same ticket is reopened several times with the comment “not quite.”
• Engineers spend the first hour of each task asking who will use the output and for what.
• Two analysts handed the same sentence deliver tables that disagree.
• Requesters stop filing tickets and message people directly, which removes any record of what was asked.
• Deadlines are discovered after the fact, so urgent and routine work are indistinguishable in the queue.

Diagnosis: five missing elements

When you audit a batch of reopened tickets, the same five omissions appear again and again. Treat the list as a diagnostic: the more of these missing from a ticket, the more likely it will bounce.

1. The purpose is absent

“Customer churn by region” could feed a quarterly review, a retention experiment or a regulatory filing. Each implies different history length, different tolerance for lateness and different rigor. Without the purpose, the producer cannot choose sensible defaults.

2. The audience and the form of delivery are absent

A one-time extract for a spreadsheet is a different job from a refreshed table that a dashboard will read each morning. If the output will be recurring, it becomes a pipeline with owners and monitoring, which is a larger piece of work than the requester imagined.

3. The deadline and its reason are absent

A date is useful; the reason for the date is better. “Needed by Thursday because finance locks the pack at noon” lets the team negotiate a smaller, earlier version. “ASAP” lets nobody negotiate anything.

4. Constraints are absent

Which columns are sensitive, which sources are off-limits, what freshness is acceptable and which systems may be queried during business hours are all constraints. Discovering them mid-task forces rework.

5. The acceptance test is absent

This is the largest gap. Few tickets state how the requester will decide that the output is right. A single sentence, such as “totals should reconcile with the finance report for last month within a small tolerance,” converts an opinion contest into a check anyone can run.

The solution: a one-page brief with fixed headings

A ticket template with the following headings costs the requester ten minutes and saves the team hours. Keep each field to a sentence or two.

1. Outcome wanted. The decision or action this data will support.
2. Consumer. A person, report, model or service, and how it will read the data.
3. Needed by, and why. Date, time and the event that creates it.
4. Effort range. How much analyst or engineer time the requester is willing to spend; a rough range is enough.
5. Constraints. Privacy rules, sources, freshness, volume, tools the consumer can read.
6. Done looks like. The check the requester will run and the sample rows they expect to see.
7. Afterwards. One-off, or recurring with a named owner?

Notice that no heading asks for technical design. The brief describes the need; the data team replies with an approach, which may differ from what the requester pictured.

How the brief changes the engineering conversation

Once the acceptance check is written, tests follow naturally. A team that already validates its tables will find it easy to turn that sentence into an assertion; the walkthrough on writing data validation rules in a DataOps workflow shows how such checks are expressed in code. Likewise, if the requested output is a derived table, the stated consumer tells you whether it belongs in a modelled layer. A piece such as building reliable transformations with dbt describes how teams keep derived tables maintainable, and the “Afterwards” field tells you if this request deserves that treatment.

When the answer to “Afterwards” is “recurring,” the brief becomes the first draft of an orchestration requirement: schedule, upstream dependencies, failure behavior and owner. For teams that schedule jobs through a workflow engine, reading how an orchestrator organises messy data jobs helps decide whether the request belongs there.

A worked example, before and after

Original ticket: “Can you pull order data for last year, we need it for planning.”

Rewritten brief:

• Outcome wanted: decide next quarter’s warehouse staffing by site.
• Consumer: an operations manager, working in a spreadsheet; no database access.
• Needed by: Wednesday noon, because the staffing proposal goes to leadership that afternoon.
• Effort range: up to half a day of analyst time; a recurring pipeline is out of scope.
• Constraints: no customer names or addresses; cancelled orders excluded; refreshed no later than yesterday.
• Done looks like: weekly order totals per site, matching the finance summary within a small tolerance, delivered as one file with a short note describing what was excluded.
• Afterwards: one-off; if leadership wants it monthly, a new request will follow.

That ticket can be accepted, estimated or politely challenged within minutes. The original could only be guessed at.

Handling pushback from both sides

Requesters sometimes say the form is bureaucratic. A reasonable reply is that the form is for them: it protects them from receiving something unusable. Offer a short version for small asks, such as outcome, date and done-check, and reserve the full template for anything that exceeds a defined size or touches sensitive data.

Data teams sometimes treat the brief as a shield against work. Avoid that. If every incomplete ticket is bounced with a form letter, requesters will route around you. Instead, fill in the blanks together during a short call, then paste the result into the ticket.

When the work goes outside the team

Not every data task stays in-house. Small companies without a data function often hire a contractor for a dashboard, a migration or a cleanup. The same brief works as the opening message. One place to start is ProfessNow, where visitors pick a profession and a city, scan the profiles shown and send a booking request; attaching the brief means the specialist knows the scope before the first call.

Measuring whether the template works

Keep it modest. After a month, look at how many tickets were reopened for “not what I meant” compared with the month before, and ask the team whether first-hour questions have decreased. You do not need a dashboard; a tally in the ticket tool is enough. If reopen rates have not moved, inspect the briefs themselves. Usually the done-check is too vague, and a sample row or an expected total will tighten it.

Summary

Data requests fail when the finish line is invisible. Diagnose the failure by looking for the five missing elements, apply a one-page brief with fixed headings and make the acceptance check the centrepiece. The effect is practical: fewer reopened tickets, fewer awkward surprises before meetings and a written record that tells everyone what was promised.