KPI Dashboard Requirements and Data Quality Audit

Public field comparison

KPI Dashboard Requirements and Data Quality Audit

KPI Dashboard Requirements and Data Quality Audit

Define dashboard KPIs, metric logic, data sources, data quality checks, stakeholder questions, visualization needs, and dashboard success criteria.

Produce decision-linked KPI requirements, calculation-ready metric definitions, source assessments, executable data quality test specifications, dashboard recommendations, and an evidence-based build-readiness decision.

Planning KPI dashboards by defining decision-ready metrics, data sources, calculation logic, data quality checks, stakeholder needs, and visualization requirements.

Planning KPI dashboards by connecting stakeholder decisions to governed metric definitions, source evidence, data quality controls, visualization requirements, and build-readiness criteria.

KPI Dashboard Planning
Metric Definition Review
Data Quality Audit
BI Requirements Gathering
Stakeholder Reporting Design
Visualization Planning

Decision-linked KPI dashboard requirements
Calculation-ready metric dictionary development
Dashboard source-fitness and lineage assessment
Data quality and reconciliation control design
BI requirements traceability and build-readiness review
Executive or financial dashboard governance planning

Business goal
Dashboard audience
Decisions the dashboard should support
Possible KPIs
Data sources
Current reports
Known data quality issues
Update frequency
Tools available
Stakeholder questions
Definitions or formulas
Definition of done

Business goal
Dashboard audience
Decisions the dashboard should support
Possible KPIs
Data sources
Stakeholder questions
Current reports
Known data quality issues
Update frequency
Tools available
Definitions or formulas
Definition of done

Paste the dashboard goal, audience, stakeholder questions, possible KPIs, data sources, current reports, known data quality issues, update frequency, available tools, formulas, and definition of done. Use the output before building a KPI dashboard in Power BI, Looker Studio, Tableau, Excel, Google Sheets, Metabase, or another BI tool.

Open ChatGPT, replace every bracketed variable with the relevant business context, and provide the available evidence or source materials, such as stakeholder notes, metric definitions, schemas, data dictionaries, report exports, sample data, profiling results, reconciliation outputs, and BI constraints. Remove or mask credentials and unnecessary personal data, then run the prompt. Treat unexecuted tests and dashboard designs as proposals requiring validation and human approval.

A founder wants to build a monthly revenue dashboard for leadership. The prompt defines decision-ready KPIs, metric formulas, source-of-truth rules, data quality checks, dashboard sections, visualization recommendations, and readiness risks before development begins.

A founder is planning a monthly leadership revenue dashboard. They give ChatGPT approved stakeholder questions, existing revenue definitions, warehouse schemas, billing and CRM report extracts, refresh requirements, and prior reconciliation results. ChatGPT produces a decision-to-KPI map, metric dictionary, source-fitness assessment, proposed and executed-control register, dashboard specification, traceability matrix, and evidence-limited readiness decision without claiming database access or completed testing.

Advanced

Advanced

ChatGPT

ChatGPT

analysis

analysis

kpi-dashboard
dashboard-requirements
data-quality
metric-definitions
business-intelligence
reporting
stakeholder-reporting
visualization-planning
data-sources
analytics

kpi-dashboard
metric-governance
data-quality
metric-dictionary
business-intelligence
data-lineage
data-reconciliation
dashboard-requirements
visualization-design
readiness-assessment

KPI Dashboard Requirements and Data Quality Audit Prompt

KPI Dashboard Requirements and Data Quality Audit Prompt

Plan KPI dashboards with metric definitions, data sources, data quality checks, stakeholder questions, visualization needs, and readiness review.

Define governed KPIs, audit source fitness, specify data quality controls, and assess dashboard build readiness with clear evidence boundaries.

Prompt-body line comparison

Removed Added Unchanged context

−You are an expert data analyst and business intelligence consultant specializing in KPI design, dashboard requirements, metric definitions, data quality review, stakeholder reporting, visualization planning, and decision-ready analytics.
−
−Your task is to help define a KPI dashboard and audit whether the available data is reliable, complete, and structured enough to support the decisions the dashboard is meant to guide.
−
−Context:
−Business goal: [Business goal]
−Dashboard audience: [Dashboard audience]
−Decisions the dashboard should support: [Decisions the dashboard should support]
−Possible KPIs: [Possible KPIs]
−Data sources: [Data sources]
−Current reports: [Current reports]
−Known data quality issues: [Known data quality issues]
−Update frequency: [Update frequency]
−Tools available: [Tools available]
−Stakeholder questions: [Stakeholder questions]
−Definitions or formulas: [Definitions or formulas]
−Definition of done: [Definition of done]
−
−Important constraints:
+Develop a KPI dashboard requirements package and data quality audit from the information and evidence supplied below.
 
−* Do not include vanity metrics that do not support a real decision.
−* Do not assume the data is accurate, complete, timely, or consistently defined.
−* Do not invent formulas, benchmarks, targets, data sources, or stakeholder priorities.
−* Separate confirmed information from assumptions.
−* Define each KPI clearly enough that different teams would calculate it the same way.
−* Identify data quality risks before recommending final dashboard visuals.
−* Consider metric grain, filters, segments, refresh frequency, ownership, and source-of-truth issues.
−* Include human review for financial, customer-facing, regulatory, executive, investor, compliance, or high-impact reporting.
−* Keep dashboard recommendations practical for the tools, data, and team capacity provided.
−* If information is missing, state the assumption clearly before continuing.
+Inputs
 
−Task:
+Blocking prerequisites:
+- Business goal: [Business goal]
+- Dashboard audience: [Dashboard audience]
+- Decisions the dashboard should support: [Decisions the dashboard should support]
+- Possible KPIs: [Possible KPIs]
+- Data sources: [Data sources]
+- Stakeholder questions: [Stakeholder questions]
 
−1. Clarify the dashboard purpose.
−   Explain:
+Useful supporting context:
+- Current reports: [Current reports]
+- Known data quality issues: [Known data quality issues]
+- Update frequency: [Update frequency]
+- Tools available: [Tools available]
+- Definitions or formulas: [Definitions or formulas]
+- Definition of done: [Definition of done]
 
−* The business goal
−* Primary dashboard audience
−* Decisions the dashboard should support
−* What the dashboard should help users do
−* What should be excluded because it does not support a decision
−* What success should look like for the dashboard
+ChatGPT operating boundaries
 
−2. Identify stakeholder decisions and questions.
−   Create a table with:
+Use ChatGPT to inspect and synthesize only the text, tables, schemas, query results, report extracts, data dictionaries, screenshots, or files actually made available in the chat through enabled capabilities. State which materials were inspected. Do not imply that ChatGPT connected to a database, queried a BI platform, profiled a full dataset, validated a production dashboard, or changed any system unless direct execution evidence is supplied in the conversation.
 
−* Stakeholder
−* Decision they need to make
−* Question they need answered
−* Metric or evidence needed
−* Frequency of review
−* Action they may take based on the dashboard
+You may propose metric logic, SQL or pseudocode, validation queries, dashboard requirements, test specifications, and visualization designs. Label these as proposed and unexecuted. Do not claim that a test passed or failed from a proposed query alone. Treat supplied query results or profiling outputs as execution evidence only when their source, scope, and run context are identifiable.
 
−3. Review and refine the KPI list.
−   For each possible KPI, classify it as:
+Do not publish, approve, deploy, edit, or certify a dashboard. Final metric approval, source-of-truth designation, access authorization, financial reconciliation, privacy review, and production release remain human responsibilities.
 
−* Core KPI
−* Supporting metric
−* Diagnostic metric
−* Vanity metric
−* Not recommended
+Input triage and missing-information rules
 
−For each KPI, explain:
+1. Check the blocking prerequisites before developing the package.
+2. Request clarification before proceeding when the business goal, audience, supported decisions, KPI candidates, source inventory, or stakeholder questions are absent or mutually incompatible.
+3. If partial progress is safe, continue with a bounded draft. Mark unresolved items as Unknown, Conflict, or Approval required; explain the consequence; and do not invent formulas, thresholds, targets, owners, benchmarks, source fields, or stakeholder priorities.
+4. When definitions conflict, preserve each definition, identify its source, explain the reporting impact, and name the decision owner needed to resolve it.
+5. If only metadata or sample rows are supplied, limit conclusions to that scope. Do not generalize sample observations to the complete dataset.
 
−* Why it matters
−* Which decision it supports
−* Whether it should appear on the main dashboard
−* Whether it belongs in a drill-down or supporting report
+Evidence discipline
 
−4. Define metric logic.
−   Create a metric dictionary.
+Classify material statements using these labels where relevant:
+- Supplied fact: explicitly stated in the inputs or source material.
+- Inspected observation: directly visible in supplied evidence; cite the artifact, table, field, report, or result.
+- Execution evidence: result from an identified query or test that was actually run and supplied.
+- Assumption: a bounded premise used to continue.
+- Hypothesis: a possible explanation requiring a test.
+- Unknown: information not available.
+- Conflict: incompatible definitions or evidence.
+- Recommendation: proposed design or action.
 
−For each recommended KPI, include:
+Keep proposed checks separate from executed checks. Never convert absence of evidence into evidence that data is complete, accurate, timely, unique, or reconciled.
 
−* KPI name
−* Plain-language definition
−* Formula or calculation logic
−* Numerator
−* Denominator
−* Data source
−* Required fields
−* Reporting grain
−* Filters or exclusions
−* Segments or dimensions
−* Refresh frequency
−* Metric owner
−* Known caveats
−* Human review needed, if applicable
+Workflow
 
−5. Audit data sources.
−   For each data source, assess:
+1. Establish the decision contract.
+- Restate the business goal, intended audience, review cadence, decisions, and actions the dashboard must support.
+- Map each stakeholder question to a decision and anticipated action.
+- Define measurable dashboard success criteria from the supplied definition of done.
+- Exclude metrics and content that do not influence a stated decision.
+- Record open questions that could change scope or interpretation.
 
−* Source name
−* System owner
−* Fields required
−* Data freshness
−* Completeness
−* Consistency
−* Reliability
−* Access requirements
−* Join keys
−* Known limitations
−* Whether it can support the required KPIs
+2. Review and prioritize KPI candidates.
+Classify each candidate as Core KPI, Supporting metric, Diagnostic metric, Vanity metric, Not recommended, or Pending definition. For each candidate, document:
+- stakeholder and decision served;
+- management action it could trigger;
+- rationale for the classification;
+- placement on the main view, drill-down, supporting report, or exclusion list;
+- risk of misinterpretation or gaming;
+- definition status and approval owner.
 
−6. Identify data quality checks.
−   Recommend checks for:
+Reject or defer a KPI when it lacks a decision link, stable definition, feasible source, appropriate grain, or responsible owner. Do not prefer visual appeal over decision utility.
 
−* Missing values
−* Duplicate records
−* Incorrect formats
−* Outliers
−* Broken joins
−* Inconsistent definitions
−* Delayed updates
−* Time-zone issues
−* Currency or unit mismatch
−* Manual entry errors
−* Historical data gaps
−* Source-system changes
+3. Build the metric dictionary.
+For every recommended KPI, specify:
+- canonical metric name and aliases;
+- business definition;
+- formula or calculation steps;
+- numerator and denominator, including zero-denominator behavior;
+- unit, currency, sign convention, and rounding;
+- event date or accounting date used;
+- reporting grain and aggregation behavior, including whether the metric is additive, semi-additive, or non-additive;
+- source system, tables or entities, required fields, and system of record status;
+- join keys, expected join cardinality, deduplication rule, and late-arriving data treatment;
+- filters, exclusions, cohort rules, status rules, and cancellation or refund treatment;
+- dimensions and permitted segments;
+- comparison period, baseline, target, or benchmark only when supplied;
+- time zone, fiscal calendar, and period-closing rules;
+- refresh cadence, latency tolerance, and restatement policy;
+- metric owner, approver, and access restrictions;
+- known caveats, unresolved conflicts, and human review requirements.
 
−For each check, include:
+If calculation logic is missing, provide a definition template and list the exact decisions needed to complete it rather than fabricating a formula.
 
−* Check name
−* Why it matters
−* How to run the check
−* Warning threshold
−* Owner
−* Action if the check fails
+4. Audit source fitness.
+For each source, assess the supplied evidence for:
+- system and business owner;
+- entities, fields, grain, date coverage, and history retention;
+- extraction method and access requirements;
+- freshness and refresh behavior;
+- completeness, validity, uniqueness, consistency, and referential integrity;
+- join keys and cardinality risks such as many-to-many inflation;
+- slowly changing dimensions, mutable historical values, and snapshot availability;
+- time-zone, currency, tax, unit, and fiscal-calendar handling;
+- manual entry, backfill, deletion, schema-change, and source-system migration risks;
+- privacy classification and whether personal, confidential, regulated, or financial data is involved;
+- KPI coverage and fitness conclusion.
 
−7. Recommend dashboard structure.
−   Design a practical dashboard layout.
+Rate each source as Supported by evidence, Partially supported, Unsupported, or Unknown. Include the evidence reference and confidence rationale. Do not assign a favorable rating solely because a source exists.
 
−Include:
+5. Specify data quality and reconciliation controls.
+Design controls relevant to the proposed metrics, including missing required values, duplicates, invalid formats or domains, impossible values, outliers, broken joins, unexpected cardinality, inconsistent definitions, stale loads, time-zone shifts, currency or unit mismatches, manual-entry errors, historical gaps, schema drift, and source changes.
 
−* Executive summary section
−* Core KPI section
−* Trend section
−* Breakdown or segmentation section
−* Diagnostic section
−* Data quality or freshness section
−* Notes, assumptions, and caveats section
+For each control, provide:
+- control identifier and related KPI;
+- failure mode and business consequence;
+- fields, grain, scope, and comparison period;
+- proposed SQL, pseudocode, or reproducible test procedure when feasible;
+- threshold and its provenance; if not supplied, mark Threshold awaiting owner approval and optionally offer a clearly labeled candidate for discussion;
+- expected observation;
+- actual observation only when execution evidence is supplied;
+- evidence reference and run timestamp if supplied;
+- owner, severity, escalation route, and remediation action;
+- retest requirement and status: Proposed, Executed-pass, Executed-fail, Blocked, or Not run.
 
−8. Recommend visualizations.
−   For each dashboard section, recommend:
+Include reconciliation controls where applicable, such as dashboard totals versus ledger, billing platform, CRM, warehouse, or an approved existing report. Define acceptable variance only from supplied policy; otherwise leave it pending approval.
 
−* Chart or table type
−* Metric shown
−* Dimension or segment
−* Why the visualization is appropriate
−* Mistakes to avoid
−* Whether drill-down is needed
+6. Design the dashboard information architecture.
+Recommend a practical structure for the available BI tool and team capacity:
+- executive decision summary;
+- core KPI scorecards with period comparison and freshness status;
+- trend analysis;
+- approved segment breakdowns;
+- diagnostic drivers and drill paths;
+- data quality, reconciliation, and refresh indicators;
+- metric definitions, assumptions, caveats, and last-updated details.
 
−9. Create a dashboard requirements table.
−   Include:
+For each section, state the user question, metric, grain, default filters, visualization, interaction, drill-down, and reason for inclusion. Address misleading axes, truncated scales, dual-axis confusion, inappropriate aggregation, excessive precision, inaccessible color use, small-sample disclosure, and comparisons across incomplete periods.
 
−* Requirement
−* User need
−* Metric or data needed
−* Source system
−* Priority
−* Owner
−* Dependency
−* Acceptance criteria
+7. Create implementation requirements and traceability.
+Translate the design into requirements with:
+- requirement identifier;
+- stakeholder need and supported decision;
+- metric or control dependency;
+- source and required fields;
+- transformation or semantic-layer requirement;
+- visualization or interaction requirement;
+- priority and rationale;
+- accountable owner and approver;
+- dependency, privacy or access constraint, and failure impact;
+- acceptance criterion and required evidence;
+- status: Ready, Blocked, Pending clarification, or Pending approval.
 
−10. Create a dashboard readiness assessment.
−    Assess whether the dashboard is:
+Maintain traceability from stakeholder decision to KPI, metric definition, source, quality control, dashboard component, and acceptance criterion. Flag every broken link.
 
−* Ready to build
−* Ready after minor data fixes
−* Not ready until major data issues are resolved
+8. Determine build readiness.
+Choose exactly one status:
+- Ready to build: every core KPI has an approved calculation-ready definition, identified source and fields, acceptable source evidence, approved access, specified controls, resolved critical conflicts, and testable acceptance criteria.
+- Ready for prototype only: enough information exists for a non-production prototype, but definitions, evidence, access, controls, or approvals remain incomplete.
+- Ready after minor fixes: bounded issues have owners and do not threaten core metric validity once corrected and retested.
+- Not ready: unresolved issues could materially change KPI values, expose protected data, break reconciliation, or mislead decisions.
 
−Explain the reason clearly.
+Provide criterion-by-criterion evidence for the selected status. A proposed test is not proof of readiness. If no profiling or reconciliation results were supplied, explicitly state that data quality remains unverified and limit the readiness claim accordingly.
 
−11. Provide final recommendations.
−    Summarize:
+Safety and stop conditions
 
−* Best KPIs to include
−* Metrics to remove or de-prioritize
−* Data quality risks to fix first
−* Dashboard sections to build first
−* Stakeholders to confirm with
−* Next steps before dashboard development
+- Do not request or reproduce passwords, API keys, connection strings, or unnecessary personal data.
+- Prefer schemas, aggregated extracts, masked samples, and field-level profiling over row-level sensitive records.
+- Stop and request human review if the design may expose personal or regulated data, permit re-identification, conflict with access policy, or use sensitive attributes for segmentation without authorization.
+- Require finance or accounting owner approval for revenue, margin, cash, tax, or investor metrics and reconciliation.
+- Require legal, privacy, compliance, or regulatory review when applicable.
+- Do not recommend production release when a critical KPI definition, source lineage, reconciliation, access approval, or severe data quality issue is unresolved.
+- Preserve current approved reports and definitions until authorized replacements are validated; recommend versioning and rollback to the last approved dashboard or metric definition for implementation handoff.
 
−Output format:
+Required output
 
−## Dashboard Purpose
+## 1. Scope and Materials Inspected
+List supplied materials actually inspected, unavailable evidence, scope limitations, assumptions, unknowns, and conflicts.
 
−## Stakeholder Decisions and Questions
+## 2. Dashboard Decision Contract
+Summarize goal, audience, cadence, decisions, actions, exclusions, success criteria, and blocking questions.
 
−## KPI Review and Prioritization
+## 3. Stakeholder Decision Matrix
+Provide a table with Stakeholder, Decision, Question, Required evidence, Review cadence, Trigger condition, Likely action, and Confirmation status.
 
−## Metric Dictionary
+## 4. KPI Prioritization Register
+Provide a table with KPI, Classification, Decision link, Actionability, Main view or drill-down placement, Definition status, Misinterpretation risk, Owner, and Recommendation.
 
−## Data Source Audit
+## 5. Metric Dictionary
+Provide the complete calculation and governance fields defined in the workflow. Use TBD only with a named resolution question and owner.
 
−## Data Quality Checks
+## 6. Source Fitness and Lineage Matrix
+Provide source-level assessments, evidence references, KPI coverage, join and grain risks, privacy constraints, confidence, and fitness status.
 
−## Dashboard Structure
+## 7. Data Quality and Reconciliation Control Register
+Separate proposed controls from supplied execution results. Include expected versus actual observations, evidence, severity, owner, response, retest requirement, and status.
 
−## Visualization Recommendations
+## 8. Dashboard Information Architecture
+Describe sections, user questions, metrics, filters, visuals, interactions, drill paths, caveats, freshness indicators, and accessibility considerations.
 
−## Dashboard Requirements Table
+## 9. Requirements and Traceability Matrix
+Connect every requirement from stakeholder decision through KPI, source, control, dashboard component, acceptance criterion, evidence requirement, owner, and handoff status.
 
−## Dashboard Readiness Assessment
+## 10. Readiness Decision
+State one allowed readiness status, criterion-level evidence, blockers, approvals, residual risks, and the conditions required to advance.
 
−## Final Recommendations
+## 11. Verification and Acceptance Checklist
+For each acceptance check, include Check, Expected result, Actual result, Evidence, Owner, and State. Use Not run or Blocked when no execution evidence exists. At minimum verify:
+- every core KPI has a stakeholder decision and action;
+- definitions specify grain, formula, filters, time handling, and ownership;
+- source grain and joins cannot silently duplicate or omit values;
+- core metrics reconcile to an approved reference where required;
+- refresh timing meets the stated decision cadence;
+- visuals use valid aggregation and comparison periods;
+- privacy and access requirements are approved;
+- critical controls have executed evidence before production acceptance.
 
−Verification:
−Before finalizing, check that:
+## 12. Handoff Plan
+Prioritize clarification, definition approval, access work, remediation, test execution, prototype work, stakeholder review, and production approval. Name owners where supplied and preserve unknown owners as unassigned.
 
−* Every KPI supports a real stakeholder decision.
−* Metric definitions are clear and calculation-ready.
−* Data sources are assessed before dashboard recommendations are finalized.
−* Data quality checks are practical.
−* Vanity metrics are removed or clearly marked.
−* Visualization recommendations match the metric type.
−* Assumptions and missing information are clearly listed.
−* High-impact reporting includes human review.
−* The final recommendations are actionable for dashboard planning and development.
+Final integrity check
 
−Begin the KPI dashboard requirements and data quality audit now.
+Before returning the package:
+- ensure no unsupported benchmark, formula, threshold, owner, result, or approval is presented as fact;
+- ensure observations identify their supplied evidence and scope;
+- ensure proposed, executed, blocked, unverified, approved, and completed states remain distinct;
+- ensure dashboard recommendations do not outrun source fitness or data quality evidence;
+- ensure the readiness decision agrees with the unresolved blockers and acceptance checklist;
+- ensure consequential financial, privacy, compliance, executive, investor, or customer-facing reporting is assigned human review.