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.<\/p>\n
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.<\/p>\n
Symptoms are consistent across companies:<\/p>\n
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.<\/p>\n
“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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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<\/a> 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<\/a> describes how teams keep derived tables maintainable, and the “Afterwards” field tells you if this request deserves that treatment.<\/p>\n 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<\/a> helps decide whether the request belongs there.<\/p>\n Original ticket:<\/strong> “Can you pull order data for last year, we need it for planning.”<\/p>\n Rewritten brief:<\/strong><\/p>\n That ticket can be accepted, estimated or politely challenged within minutes. The original could only be guessed at.<\/p>\n 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.<\/p>\n 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.<\/p>\nA worked example, before and after<\/h2>\n
\n
Handling pushback from both sides<\/h2>\n
When the work goes outside the team<\/h2>\n