Do not begin a data analysis because someone asks for “a dashboard,” “some insights” or “an AI model.” Begin when the requester, analyst and decision owner can agree on what decision must be made, what evidence is acceptable and how the result will be checked.

The practical tool in this guide is ANALYSE-12, a copyable data-analysis request brief with twelve fields, a readiness score and a worked example. It is designed for analysts, managers, product teams, finance teams and internal customers. It works for descriptive reporting, diagnostic analysis, forecasting and bounded AI-assisted work. It is not a substitute for legal, privacy, security or domain review.

Why analysis requests fail before the analysis starts

Many analytical problems are specification problems in disguise. The requester names an output instead of a decision. The analyst guesses the population. Two teams use different metric definitions. A deadline arrives before the necessary data. A model is judged by accuracy although the business cost of errors is asymmetric. A dashboard launches without an owner for exceptions.

Public questions from working analysts and learners repeatedly mention vague stakeholder requests, changing requirements, messy data, unrealistic expectations and uncertainty about how analytical effort should be measured. These are not solved by a more complex algorithm. They are reduced by an explicit agreement about purpose, scope, evidence and responsibility.

ANALYSE-12: the copyable request brief

Use the following template before work is scheduled.

  1. Accountable decision owner:
  2. Decision and deadline:
  3. Action options available:
  4. Population, unit and period:
  5. Primary metric and guardrails:
  6. Comparison or counterfactual:
  7. Data sources and access owner:
  8. Assumptions, exclusions and constraints:
  9. Method class and proportionality:
  10. Validation, reconciliation and review:
  11. Output, audience and delivery format:
  12. Monitoring, expiry and change control:

The template is short enough for a one-page intake. The sections below explain the evidence required for each field.

1. Accountable decision owner

Name one person who owns the business decision. The requester, data owner and analyst may be different people. A committee can advise, but a request without a decision owner often produces an orphaned output.

Record:

  • name or role;
  • authority to act;
  • budget or policy boundary;
  • conflicts that require escalation;
  • delegate when unavailable.

Weak: “Sales team.”
Strong: “Regional Sales Director; may change territory rules and coaching cadence, but pricing changes require the CCO.”

The analyst remains accountable for methodological integrity. Ownership of the business decision does not authorize changing inconvenient results.

2. Decision and deadline

Write the decision as a verb with a date. “Understand customers” is a research theme. “Decide by 15 October whether to extend the onboarding intervention to all European accounts” is a decision.

Separate three dates:

  • decision date;
  • latest useful delivery date;
  • data-complete date.

If the latest reliable data arrives after the decision, the request needs a provisional method, a delayed decision or a different scope.

3. Action options available

Analysis is valuable when it changes a choice. List the realistic options before work begins. Examples include scale, stop, continue with conditions, run an experiment, request more evidence or make no change.

Also state the cost of the wrong action. A false positive might fund an ineffective campaign. A false negative might stop a useful intervention. This informs sample size, thresholds and review intensity.

If no action can change, label the work as monitoring, statutory reporting or learning rather than pretending it is decision support.

4. Population, unit and period

Define who or what is counted, at what grain and during which period.

Ask:

  • Is the unit a person, account, transaction, case, order or day?
  • Can one entity appear several times?
  • Which statuses qualify?
  • Which geographies, products or channels are included?
  • Which time zone and calendar apply?
  • How are late events handled?

“Conversion rate for Q3” is incomplete. A defensible definition might be: “Share of accepted opportunities created from 1 July through 30 September, measured at account-opportunity grain, that reached signed contract within 90 days; renewals and partner-sourced duplicates excluded.”

5. Primary metric and guardrails

Choose one primary metric connected to the decision and a small set of guardrails that prevent local optimisation.

The metric contract should include:

Component Required statement
Meaning What the metric represents
Formula Numerator, denominator and aggregation
Eligibility Included and excluded records
Timing Event date, attribution window and refresh
Source System and field lineage
Owner Person responsible for definition
Guardrail Harm or trade-off that must not worsen

For an onboarding intervention, the primary metric could be 60-day retention. Guardrails could be complaint rate, support cost and refund rate. More metrics do not automatically create a better analysis; they can make the decision impossible to interpret.

6. Comparison or counterfactual

Every claim needs a reference. State what the observed result will be compared with:

  • prior period;
  • plan or threshold;
  • matched segment;
  • untreated group;
  • randomized control;
  • baseline forecast;
  • external benchmark with comparable definitions.

A before-and-after comparison may be descriptive, not causal. Record plausible confounders such as seasonality, channel mix, price changes or instrumentation changes. If causal confidence matters, design the test before implementation.

7. Data sources and access owner

List sources, owners, access conditions and expected readiness.

  • Source:
  • Business owner:
  • Technical owner:
  • Relevant tables or files:
  • Personal or restricted data:
  • Retention and approved environment:
  • Expected refresh:
  • Known quality issue:
  • Access approved by:

Do not move sensitive data into an unapproved notebook or AI service to meet a deadline. If required fields cannot be accessed lawfully, the request is blocked or must be redesigned.

8. Assumptions, exclusions and constraints

Create an assumption log. For each assumption, state its owner, evidence, consequence if false and check date.

Example:

Assumption record A

  • Assumption: CRM close date is final.
  • Evidence: finance reconciliation was within 1.2% last month.
  • If false: conversion timing is biased.
  • Owner: RevOps.
  • Check: reconcile before delivery.

Assumption record B

  • Assumption: excluded test accounts are complete.
  • Evidence: a maintained account flag exists.
  • If false: volume is slightly overstated.
  • Owner: CRM administrator.
  • Check: complete a sample review.

Constraints may include time, computing resources, privacy, minimum group size, accessibility, contractual use rights or inability to identify a true control group. Constraints belong in the brief, not in an appendix discovered after the result is challenged.

9. Method class and proportionality

Choose the lightest method that can support the decision. The brief need not prescribe an algorithm, but it should identify the class:

  • descriptive measurement;
  • diagnostic comparison;
  • experiment or causal design;
  • forecast or scenario;
  • classification or prioritisation;
  • qualitative coding;
  • optimization;
  • mixed method.

Complexity creates maintenance and validation obligations. A transparent cohort comparison may be better than a predictive model when the decision is about a one-time policy and the sample is small.

If AI will assist, record the task boundary: query draft, text classification, documentation, anomaly suggestions or another bounded use. NIST's AI Risk Management Framework calls for defined scope, roles, testing, evaluation, verification, validation and human oversight. The brief should say who checks machine-generated work and what evidence is retained.

10. Validation, reconciliation and review

Define acceptance tests before results exist. Typical tests include:

  • row-count and uniqueness checks;
  • reconciliation to a trusted total;
  • missingness and range rules;
  • code review;
  • holdout or back-test;
  • sensitivity to exclusions;
  • segment stability;
  • fairness or harm review where relevant;
  • domain-owner review;
  • reproduction by a second analyst.

Write tolerances. “Check against Finance” is vague. “Monthly recognised revenue must reconcile to the Finance ledger within 0.5%; larger differences stop publication” is operational.

Validation does not guarantee truth. It makes known failure modes visible and assigns responsibility for resolving them.

11. Output, audience and delivery format

Name the smallest useful output. It might be a decision memo, monitored table, dashboard, reproducible notebook, API, slide or model score. Identify the audience's decision literacy and accessibility needs.

For executives, lead with recommendation, evidence, uncertainty and action. For analysts, add code, lineage and diagnostics. For operators, show exceptions, owners and next steps. One giant dashboard rarely serves all three.

Record whether the output is a draft, recurring product or controlled record. Specify where it will live, who may access it and how long it remains valid.

12. Monitoring, expiry and change control

An analysis can become wrong as definitions, behaviour and data systems change. State:

  • review frequency;
  • performance or data-quality signals;
  • owner of monitoring;
  • threshold for investigation;
  • expiry date;
  • conditions requiring reapproval;
  • retirement and archive process.

For a one-time memo, expiry may be the decision date. For a model, monitor input drift, output performance and harm indicators. For a dashboard, monitor freshness, reconciliation and use. A product without an owner or expiry accumulates silent risk.

The ANALYSE readiness score

Score each field from zero to two:

  • 0 — absent or disputed;
  • 1 — provisional, with an owner and resolution date;
  • 2 — agreed and evidenced.

Maximum: 24.

Apply three gates regardless of total:

  1. no lawful data access means do not start;
  2. no accountable decision owner means return the request;
  3. no validation rule means the output cannot be approved.

Suggested interpretation:

  • 0–10: discovery only; do not commit to delivery;
  • 11–17: conditional start with explicit resolution tasks;
  • 18–24: ready for planned analysis, subject to governance.

The score is a workflow convention, not a statistical guarantee. A high score can still support a flawed question. It simply shows that the request is specified enough to review.

Worked example: falling enterprise conversion

Original request

“Build a dashboard showing why enterprise conversion fell and use AI to predict which deals will close.”

This request combines description, diagnosis and prediction. It does not name the decision, population, comparison or error cost.

Completed brief

Owner: VP Sales, Europe. May change qualification policy and coaching cadence; discount policy remains with the CCO.

Decision: by 20 October, decide whether to change qualification rules for new enterprise opportunities or retain the current rules while running a controlled pilot.

Options: keep rules; tighten two entry criteria; create a separate pilot segment; investigate data quality before change.

Population: new enterprise opportunities created from April through September, opportunity grain, European direct-sales teams, renewals and migrated legacy records excluded.

Metric: 90-day opportunity-to-contract rate. Guardrails: average discount, median cycle time, complaint rate and contribution margin.

Comparison: quarter, region and source cohorts; matched comparison where observable characteristics permit. No causal claim from simple period differences.

Sources: CRM opportunity and activity tables, contract system and finance margin extract. Owners named; restricted notes excluded.

Assumptions: stage-history completeness, consistent enterprise definition and contract linkage. Each has a reconciliation test.

Method: descriptive funnel plus diagnostic cohort analysis. Predictive model deferred until data lineage and decision use are agreed.

Validation: opportunity totals within 0.5% of approved sales operations report; duplicate-account sensitivity; code review; Finance confirms signed-contract and margin linkage.

Output: two-page decision memo, funnel table and exception appendix. Dashboard considered only if the metric becomes recurring.

Monitoring: if qualification changes, review conversion, margin and complaint guardrails after 30 and 90 days; reverse if margin or complaints breach agreed thresholds.

Score and decision

Assume 20 of 24 points. Data access is approved, the owner and validation rules exist, and provisional assumptions have resolution dates. Start the diagnostic work. Do not build the model yet. The request brief has already prevented an attractive but premature deliverable.

Change-control log

Requirements will change. Record changes rather than letting them overwrite the agreement.

  • Change date:
  • Requested by:
  • Old statement:
  • New statement:
  • Reason:
  • Effect on population, metric, method, deadline and prior results:
  • Decision-owner approval:
  • Analyst response:

If a metric changes, preserve the old definition and restate history only when the owner approves. Otherwise readers may compare incompatible numbers.

Analyst acceptance checklist

Before accepting work, confirm:

  • the decision can still change;
  • the owner has authority to act;
  • the population and grain are explicit;
  • the metric has one definition;
  • comparison and uncertainty are appropriate;
  • source access is lawful and feasible;
  • major assumptions have owners;
  • method complexity matches the decision;
  • validation has numerical tolerances;
  • the delivery format serves the audience;
  • AI use, if any, is bounded and reviewed;
  • monitoring and expiry are assigned.

If several items fail, schedule a framing session rather than beginning hidden discovery under a delivery promise.

Requester checklist

The requester should bring:

  • the decision and available options;
  • examples of current reports or disputes;
  • people who own definitions and data;
  • constraints and sensitive-data boundaries;
  • deadlines and downstream meetings;
  • known exceptions;
  • an honest statement of what happens if evidence is inconclusive.

The analyst should not be expected to invent business authority. The requester should not be expected to prescribe the statistical method. The brief creates a productive boundary between the two.

Using the brief with AI agents

An agent can help detect empty fields, compare definitions, generate test cases or draft documentation. It should not silently become the decision owner, approve data use or select a convenient conclusion.

Provide only approved information. Require the agent to label assumptions and cite the supplied source. Validate every calculation in the execution environment. Keep a record of the instruction, output, revision and reviewer. When the analysis affects people, money, legal rights, safety or regulated activity, apply the organization's relevant controls and human approval.

How the template improves analytical work

ANALYSE-12 does not remove iteration. Good analysis often loops between business understanding, data understanding and method. The template makes each loop visible. It helps teams distinguish a legitimate discovery from uncontrolled scope change; an estimate from an observed fact; and a technical output from a business decision.

The most valuable field is often not the method. It is the decision. Once the team agrees on the decision, population, metric and validation rule, the appropriate technical work becomes easier to choose and easier to review.

Professionals who want structured practice in requirements framing, data preparation, analysis, validation and communication can compare MTF Institute's Professional Certificate in Data Analysis with their target role and evidence gaps. A course is useful only when it helps the learner produce reviewable work; it does not replace decision ownership or guarantee a career outcome.

Final rule

Start analysis when the request is specific enough to be wrong in a detectable way. If nobody can state what would invalidate the result, the work is not ready. Use ANALYSE-12 to create that test before investing in code, dashboards or models.