Model job description

Model Job Description: Business Intelligence Analyst Using SQL

This model job description describes a Business Intelligence Analyst who turns approved questions and permitted data into checked SQL evidence, clear reports and decision handoffs. Hiring teams adapt scope, systems and authority locally; it is not a live vacancy.

Explore Professional Certificate in SQL for Business Analytics

Resource: Model job description
Evidence: United States
Reviewed: October 7, 2026
Format: Reusable professional guide

An evidence-derived Business Intelligence Analyst job-description model for SQL analysis, measures, validation, reporting, handoffs and local decision rights.

Evidence scope: Evidence-derived role resource from a purposive review of 100 selected current U.S. analyst-SQL vacancies checked on 6 October 2026, plus a separate dated review of SQL and analytics platform changes. The sample is descriptive, not a representative estimate of U.S. hiring or employer practice.

What this model describes

A Business Intelligence Analyst using SQL turns an approved business question into evidence that another person can inspect and use. The analyst clarifies the decision, defines the population and measure, queries permitted data, checks the result against source records or agreed controls, and explains what the evidence does and does not support. Depending on the employer, the work may end in a checked analysis table, recurring report, dashboard, or concise recommendation.

This is an evidence-derived job-description model for local adaptation. It is not a live vacancy or a universal employer policy, and it does not invite applications. A hiring team should confirm its own reporting line, data access, approved systems, seniority, work rhythm, decision rights, and domain-specific requirements before using any wording below.

The model draws principally on an MTF Institute study of 100 selected current U.S. analyst-SQL requisitions, checked on 6 October 2026. The sample was structured and purposive. In those selected postings, 93 listed SQL as an applicant requirement and seven described a specific SQL task without stating it as an applicant requirement. The study counted explicit dashboard or reporting duties in 52 postings, business query or analysis duties in 38, validation or reconciliation duties in 32, and metric-definition duties in 29. These are counts within the selected 100 postings, not estimates for all U.S. employers or BI jobs. Categories overlap, and an unstated duty is not an absent duty.

The O*NET Business Intelligence Analysts profile is separate occupational context: it describes querying repositories, producing reports, maintaining BI tools, and explaining information for users. Its population and method differ from the MTF vacancy sample, so its figures should not be combined with the study counts. The separate current-changes review concerns dated vendor capabilities, not hiring prevalence.

Role purpose and scope

Model purpose: Provide reliable, reproducible analysis of business performance and operations using SQL and related reporting methods. Convert a bounded request into agreed definitions, a traceable data selection, tested calculations, and a useful handoff to the person who owns the decision.

Typical scope: Internal BI, product, revenue, marketing, service, finance, or operations questions where relational data can help describe performance, compare groups, diagnose change, or monitor a defined measure. The local employer must specify which domains this position actually serves. The analyst works within approved access and does not gain authority over production systems, data permissions, budgets, customer treatment, or specialist decisions merely by producing an analysis.

Core responsibilities to adapt

Clarify the business question, intended decision, audience, comparison period, and success measure with the requester or metric owner before writing a query.
Identify authorized source tables and document row grain, keys, population, date boundaries, filters, exclusions, and known gaps.
Write readable SQL to extract, join, aggregate, and check data for the approved question. Use more advanced query structures when the data and task require them; do not imply that every role uses every SQL feature.
Test joins for duplicated or lost rows, inspect nulls and unusual values, and reconcile material totals to an agreed source or control.
Define or document metric logic with the accountable business owner where assigned, including numerator, denominator, time basis, and interpretation limits.
Produce and maintain reports, dashboards, scorecards, or decision tables when those outputs are part of the local role. State refresh timing and ownership rather than leaving a recurring output ownerless.
Explain findings in plain professional language, with the evidence, uncertainty, alternative explanations, and action or decision that the analysis can inform.
Preserve the query version, source identity, run date, checks, assumptions, and handoff notes so another authorized analyst can review or rerun the work.
Raise access, data-quality, metric-definition, privacy, or production-impact questions to the appropriate owner. Escalate a consequential anomaly before presenting an unchecked number as settled.

These responsibilities are a configurable model. A specific posting should retain only duties the employer will actually assign and support with access, supervision, and review.

Expected work products

Question and metric brief: A concise record of the decision, population, grain, measure, comparison, requester, and approving metric owner.
Reproducible SQL analysis: A versioned query or query set with source tables, filters, joins, calculation logic, and run context.
Checked result: A table or analysis-ready extract with row-count, key, null, duplication, range, and material-total checks appropriate to the question.
Reader-facing output: A report, readout, dashboard, or scorecard that defines its measures, period, limitations, and refresh status. Choose the smallest output that supports the actual decision.
Handoff record: A plain-language interpretation, outstanding questions, source and query references, and named next owner.

The selected-posting study recorded 47 explicit dashboard or scorecard outputs and 34 report or readout outputs. Those counts describe this sample only. A local position may require one, both, or neither; an accurate checked table can be the right deliverable for a bounded request.

Capabilities and observable behaviours

Core analytical capabilities

Practical SQL querying against relational data, including filtering, joining, grouping, calculating, and checking results.
Careful interpretation of table grain, relationships, data types, missing values, and measure definitions.
Validation that connects a query result to source records, expected controls, and the business question.
Clear documentation of assumptions, query changes, unresolved discrepancies, and limitations.
Ability to select a suitable reporting form and explain why a number changed without presenting correlation as a proven cause.

Observable working behaviours

Asks a requester what decision the analysis will inform and repeats back the agreed measure and population.
Checks whether two tables can be joined at the intended grain before trusting a combined result.
Shows the requester a definition or control-total mismatch rather than silently choosing the convenient number.
Explains what is known, what is uncertain, and what should be checked next in language the audience can use.
Coordinates with data, product, engineering, finance, marketing, or operations colleagues when the task crosses their ownership boundaries.
Prioritizes a bounded, verifiable answer over a broad dashboard that has no agreed decision use.

The study found explicit stakeholder-communication wording in 41 selected postings and cross-functional collaboration in 28. These observations support including visible behaviours in a job description; they do not make every interface mandatory for every employer.

Tools and systems

Specify the actual environment locally. The model may involve a relational database or cloud query service, a SQL editor, a BI or visualization tool, a spreadsheet, a shared metric catalogue, and approved documentation or version-control systems. Some roles also use Python or R. Name a product only when the employer uses it and will provide access or a clear onboarding path.

Current vendor releases increasingly expose semantic definitions, query diagnostics, AI assistance, access controls, and lineage within analytical tools. They can help an analyst inspect or document work, but a generated query or successful execution still needs human checks of grain, joins, permissions, metric meaning, and business interpretation. The separate platform-changes review describes these capabilities with dates and limits; it does not establish that U.S. employers have adopted them.

Experience and level

Choose one level and match duties, support, and hiring criteria to it:

Entry or associate: Can explain basic relational data, write and check bounded queries with review, document definitions, and escalate unclear access or metric questions. Provide a named reviewer and suitable practice data.
Independent analyst: Can scope a request, build and validate a reproducible analysis, maintain agreed reports, work with stakeholders, and hand off limitations without routine step-by-step direction.
Senior or lead analyst: Can guide metric and quality reviews, challenge ambiguous requests, improve reusable analytical methods, mentor peers, and coordinate complex cross-team decisions while respecting the local approval chain.

The 100 selected postings span several levels, but the study did not treat level labels as a nationally comparable count. Set minimum experience, education, and tool exposure from the real task and the employer’s own criteria. Distinguish a required capability from a preferred one; do not turn exposure to a current tool stack into a blanket requirement.

Working relationships and decision boundaries

The analyst's most important interface is the person who owns the business question or metric. Depending on the assignment, other contacts may include data engineering for source or pipeline issues, product teams for event definitions, operations or finance for controls, and reporting users or external clients for interpretation. Name only the counterparts this position will actually work with.

The analyst may propose a query method, document a definition issue, recommend further analysis, and explain options supported by evidence. The employer should identify who approves the metric definition, authorizes data access, changes a production data product, accepts a public or client-facing number, and makes the business decision. Escalate when data permissions are unclear, a source conflicts with an agreed measure, a material reconciliation fails, or a requested change could affect production reporting or another person's outcome.

Decision or escalation authority was unstated in 89 of the 100 selected postings. This model therefore leaves final authority to named local owners and does not infer approval rights from an analyst title.

Work rhythm to set locally

Vacancy text often did not specify work frequency: cadence was unstated in 88 of the selected 100 postings. Use the following as adaptable examples, not a universal BI schedule:

Daily or request-driven: Triage a new question, check data freshness and access, investigate material exceptions, and record the next owner.
Weekly or other agreed reporting cycle: Refresh assigned reports, reconcile key measures, review anomalies with metric owners, and update assumptions or issue logs.
Monthly or planning cycle: Reconfirm definitions and comparisons, review recurring-output use, retire unused views, and document changes that affect trend interpretation.
Event-driven: Recheck a result after a source, schema, permission, product event, or business definition changes; escalate a material conflict before reuse.

The hiring manager should replace these examples with the actual cadence, service expectations, and review points for the position.

Reusable job-description model

Use the text below as a starting structure. Complete the local choices before posting it or using it for role evaluation.

Position identity

Employer-approved title: Select the title used in the hiring system.
Team and reporting line: Name the actual team, manager, and decision partners.
Location and working arrangement: State the real workplace and eligibility rules.
Level and employment terms: Set these through the employer's normal hiring process.

Model role summary

The Business Intelligence Analyst will turn approved business questions into checked, reproducible evidence using SQL and the organization's authorized analytical tools. The role will work with named metric and source owners to define measures and permitted data, build and validate analyses, and communicate results in a form that supports accountable decisions.

Model responsibilities

Clarify assigned questions and document agreed metric, population, grain, time period, and intended reader.
Query permitted relational sources and validate material results before sharing them.
Maintain the specific reports, dashboards, or analysis tables assigned to this role.
Record query logic, checks, limitations, and handoff information for review and reuse.
Communicate findings and escalate data, definition, access, or production-impact issues to the named owner.

Model capability criteria

Demonstrated ability to use SQL to answer a bounded analytical question and check the result.
Ability to explain relational data, joins, aggregation, and metric definitions at the level required by this position.
Clear written and spoken communication of methods, findings, limitations, and next steps.
Experience with the employer's actual BI, spreadsheet, scripting, or warehouse environment only where the role needs it; mark each item required or preferred.

Local decisions to complete

The hiring manager should specify the assigned business domain, source systems, named metric and access owners, deliverables, review standard, recurring cadence, approval chain, escalation route, and level-specific expectations. Remove any model statement that does not fit the real position.

Local adaptation checklist

Confirm the role has substantive business-facing SQL analysis rather than mainly pipeline engineering or system administration.
Check that each listed duty has an actual owner, source, system access path, and review route.
Set the required SQL proficiency through a practical work sample aligned with the level; separate required from preferred tools.
Replace generic counterpart names with the teams and decision owners the analyst will actually contact.
Decide which outputs are required, who reads them, how frequently they refresh, and how a failed check is handled.
State local rules for sensitive data, permitted AI tools, production changes, and external sharing where the role encounters them.
Remove any unverified salary, employment outcome, credential, or universal-authority claim before publication.

Evidence and use boundary: The MTF vacancy study supports the selected-posting observations above. O*NET supplies broader occupational context through a different source population. The hiring employer must validate every operational and authority detail for its own job.

Quick reference

Use the resource in five moves

Read the role purpose and expected outputs.
Compare the model with the local role and authority boundaries.
Select only statements supported by real evidence.
Adapt the reusable fields without inventing experience or approvals.
Review the result with the accountable person before operational use.