Data analyst proposals: questions, data access, and deliverable tables

Data analyst job posts range from “build a dashboard by Friday” to “help us understand why revenue dropped.” Clients often do not know what data they have, how clean it is, or what decision the analysis should support. Your proposal should not sound like a statistics lecture. It should sound like someone who will get access safely, deliver defined artifacts, and stop scope from becoming a endless SQL ticket queue.

The winning pattern has three parts:

1. Questions that expose data reality (sources, grain, freshness, PII)
2. Data access plan (tools, permissions, security, who provisions)
3. Deliverable table (what file or dashboard they receive, in what format, by when)

Use this on Upwork, consultancy-style RFPs, and founder hires. For giant requirement lists, add structure from proposal for a long RFP. For thin posts, start with short job post proposals and embed the deliverable table once they answer two questions.

What hiring managers skim

They look for:

• Tools that match their stack (SQL, dbt, Looker, Power BI, Python, Excel)
• Whether you have worked with similar data (e-commerce, SaaS, ads, ops)
• Clarity on outputs (dashboard, slide deck, memo, recurring report)
• Awareness of data quality and privacy (not blind optimism)
• A sane first step (discovery vs “I will analyze everything”)

If you open with “I love data storytelling,” you lose to the analyst who wrote a deliverable table with dates.

Questions to ask in the proposal (not after you are hired)

Pick 5-8. Tailor to their post.

Business and decision

• What decision should this analysis support in the next 30 days?
• Who is the audience (exec, marketing, ops) and what format do they consume?
• What metric definition do you use today for [KPI they named]?

Data sources and access

• Where does data live (warehouse, spreadsheets, GA4, Shopify, Salesforce)?
• Do you have a single source of truth or multiple exports?
• Who can grant read access and how long does IT take?
• Is PII involved and do you need anonymized views?

Quality and grain

• Known issues (missing dates, duplicate orders, test accounts)?
• Grain of truth: user, order, session, line item?
• Historical depth needed (90 days vs 3 years)?

Delivery and maintenance

• One-time project or recurring reporting?
• Self-serve dashboard vs static weekly PDF?
• Who maintains the dashboard after handoff?

Strong questions prove you have been burned by dirty exports before. That builds trust.

Data access block (put this in every proposal)

Clients blame analysts when IT takes three weeks. Name the access path:

Access needed: read-only to [tables/schemas] or exports [CSV/API]. Provisioned by: your IT / me with your approval. Start of work: analysis clock begins when I can run queries on a sample or production mirror. Security: VPN / SSO / no local PII on personal laptop policy [state yours].

If they cannot grant access yet, price Phase 0: access and profiling as a paid milestone. Do not start “analysis” on imaginary data.

Mention NDAs if the post touches finance or health. Do not download production to personal Gmail drives. One sentence on security separates pros from cowboys.

Deliverable table (the center of the proposal)

Replace vague “insights” with rows. Example structure:

Deliverable	Format	Includes	Due (example)
Data profile memo	Google Doc or Notion	row counts, nulls, key joins	Week 1
KPI dashboard v1	Looker / Power BI / Sheets	6 metrics they listed	Week 2
Recommendation summary	2-page memo	3 actions, caveats	Week 3
Handoff call	30 min	walkthrough + doc	Week 3

Adjust to project type:

• Ad-hoc investigation: memo + slide with charts, not necessarily a live dashboard
• Dashboard build: wireframe screenshot in proposal, revision rounds on layout
• Recurring reporting: weekly refresh SLA, definition of “data ready” each Monday

Each row should say what is not included: predictive ML, data engineering pipeline rebuild, 24/7 on-call.

Cross-link how many revision rounds to promise for dashboard layout changes vs logic bugs (define both).

Proposal structure for analyst jobs

1. One-sentence understanding of the business question
2. Approach: explore, model, visualize (3-5 bullets, no jargon pile)
3. Questions (numbered)
4. Access paragraph
5. Deliverable table
6. Pricing: fixed per table row, day rate, or hourly with cap
7. Assumptions: data ready by [date], one stakeholder for feedback

Keep the opening short. Busy operators want the table.

Copy-ready opening (dashboard / analysis)

Hi [Name], you want to [decision/outcome] using [sources mentioned]. My first step is a data profile (quality, grain, joins) once I have read access to [system]. Deliverables I propose: [row 1], [row 2], [row 3] by [dates]. I work in [SQL/Python/BI tool] and have done similar work for [niche] (e.g. cohort retention for SaaS, SKU mix for retail). Access: read-only via [your VPN/warehouse]; work starts when sample queries run. Questions: How do you define [KPI] today, and is there a documented schema or only exports?

Variations by job type

”Build us a dashboard”

Ask who maintains it. Include wireframe approval milestone. Separate data modeling from viz if their warehouse is messy.

”Why did revenue drop?”

Deliverable is a memo with hypotheses tested, not only charts. State you may need interviews with ops, not only SQL.

Marketing analytics (GA4, ads)

Call out attribution limits honestly. Deliverable might be weekly channel report with definitions footnoted.

Finance / ops reporting

Precision and definitions matter. Ask about fiscal calendar, refunds, currency. Extra revision round on metric definitions, not colors.

Ongoing analyst retainer

Weekly hours, priority queue, SLA for ad-hoc asks. Use retainer proposal patterns if you price monthly blocks.

Pricing and milestones

Data work without milestones becomes unpaid exploration.

• M1: Access + profile memo (paid even if project stops)
• M2: Core analysis or dashboard v1
• M3: Revisions and handoff

Fixed price works when deliverable table is tight. Hourly works for exploratory “we do not know yet” posts, with a weekly cap and written priorities.

If they want guaranteed lift (“increase ROAS 20%”), decline or reframe to diagnostic deliverables. See why clients ignore proposals for hype that backfires.

Mistakes in data analyst proposals

• Promising insights before seeing data
• No deliverable table (only “I will analyze”)
• Ignoring PII/GDPR
• Conflating analyst with data engineer (pipelines, Airflow) without pricing engineering time
• Unlimited “small questions” after project
• Tool name dropping without linking to their question

Tools: mention them tied to outcomes

Write “Looker dashboard for funnel conversion” not “expert in Looker, Tableau, Power BI, Python, R, Excel.” Match their post. If they use Sheets only, do not pitch a warehouse migration in the proposal unless they asked.

Before and after

Before

“I am a data analyst with strong SQL and visualization skills. I can help you get actionable insights from your data. I am detail-oriented and communicate well. Available immediately.”

After

“You want to know which cohorts retained after the pricing change. I need read-only BigQuery access to events and subscriptions tables (IT ticket ~3 days). Deliverables: (1) data profile memo week 1, (2) cohort dashboard v1 week 2 with definitions doc, (3) 2-page recommendation memo week 3. Two dashboard revision rounds included; pipeline rebuild out of scope. Fixed $X or $Y/day capped at 10 days. Questions: How is ‘active user’ defined internally, and do test accounts exist in prod data?”

Working with messy stakeholders

If multiple people assign tasks, propose a single intake owner and weekly priority list. Otherwise you become Slack-driven helpdesk.

For first reply after they message you, keep the deliverable table stable and answer new asks with “happy to add as change request” per first reply templates.

FAQ

Should I do a free sample analysis?

A public dataset demo is fine. Their production data before contract is a paid Phase 0 or small pilot. See unpaid test tasks.

They want AI/ML prediction.

Say if it is out of scope for v1 or needs a separate estimate. Do not imply ChatGPT replaces metric definitions.

Non-native English?

Clear tables and short sentences beat flashy adjectives. Non-native English proposal mistakes still apply.

Final pass

Questions listed, access and security stated, deliverable table with dates, revisions bounded, price tied to rows. Data clients hire for judgment about messy reality. Proposals that show you expect messy data sound like someone who will actually finish.