You've spent years learning SQL, building pipelines, wrangling messy datasets, and answering questions that nobody else in the room could answer. You know how to find the broken foreign key that's inflating revenue numbers by 40%. You know how to spot a Looker dashboard that's been silently lying to the marketing team for six months. You know how to walk into a company's data infrastructure and, within hours, identify the three things that are costing them the most money and the two things that will bite them in six months.
The problem is that you've been giving this knowledge away for free — in job interviews, in consulting conversations, in "quick calls" that turn into two-hour strategy sessions. Or worse, you've been packaging it as a 90-day engagement when the client doesn't have the budget or trust for that yet. The Data Audit Service solves both of these problems at once. It's a scoped, time-boxed, high-value deliverable that you can sell quickly, complete in a day, and use as the front door to a much larger client relationship.
By the end of this lesson, you will know exactly how to package, price, sell, deliver, and follow up on a professional Data Audit Service. Not in theory — in practice, with the actual frameworks, templates, and decision logic you need to execute on this immediately.
What you'll learn:
This lesson assumes you have:
You do not need prior experience selling or packaging services. That's what this lesson is for.
Before we talk about how to build and sell a Data Audit, we need to talk about why this product works when other approaches fail. Understanding the structure helps you defend it in sales conversations and adapt it intelligently when you hit edge cases.
Most freelancers approach new clients in one of two ways: they pitch a large project ("I'll redesign your entire data pipeline for $30,000") or they offer hourly consulting ("I'm $200/hour, let me know what you need"). Both of these create friction.
The large project pitch fails because the client doesn't trust you yet. They don't know if you understand their business. They don't know if your diagnosis is correct. Asking someone to commit $30,000 to a diagnosis they can't yet verify is asking them to take an enormous leap of faith. Most sophisticated buyers won't do it, and the ones who will are often difficult clients precisely because they're not exercising proper judgment.
The hourly consulting model fails for a different reason: it puts the client in charge of scoping. They'll call you for small, urgent problems and never give you the access or context to understand the big picture. You become an expensive ticket-resolver instead of a strategic advisor. Your billing is unpredictable. Your leverage is low.
The Data Audit sits in a different position entirely. It's:
Time-boxed and concrete. The client knows exactly what they're buying: one day of your focused attention plus a written deliverable. There's no ambiguity about when it ends or what they receive.
Low enough in price to bypass committee approval. In most companies, purchases under $5,000 to $10,000 can be approved by a single manager or director without a procurement process. This dramatically accelerates your sales cycle.
High enough in value to establish premium positioning. If you're charging $2,500–$5,000 for one day of work, you're signaling that your time is worth $300–$600 per hour. This shapes how the client thinks about your implementation work later.
Structured to surface your expertise. A good audit requires you to ask questions nobody else in the building has asked, find problems nobody else has found, and explain them in terms the client actually cares about. This is a live demonstration of your value, not a pitch for it.
A natural gateway to implementation. Every good audit ends with a prioritized list of recommendations. Those recommendations are a project backlog. You're not pitching follow-on work in the abstract — you're walking them through work they now know they need, with an expert they've already hired and trusted.
The most common mistake in productizing a service is either scoping it too narrowly (so the client doesn't perceive enough value) or too broadly (so you can't finish it in a day and you start dreading every booking). Getting scope right is a craft problem, not just a business problem.
A well-scoped Data Audit covers four domains:
This is the foundation layer. You're asking: does the data actually get from source systems to the place where people use it, reliably and completely?
Specific checks include:
You're not going to rebuild the infrastructure in a day. You're cataloging its current state and identifying the highest-priority gaps.
This is usually where the most emotionally resonant findings live. Data quality problems are the ones that make the VP of Sales say "I don't trust these numbers" and the ones that made the CEO make a decision last quarter that turned out to be based on bad data.
Specific checks include:
product_category field that has "Software", "software", "SW", and "SaaS" all meaning the same thing)These checks can be done with SQL. We'll look at specific queries in the technical section below.
This domain is about whether the business actually agrees on what its numbers mean. Surprisingly often, they don't.
Specific checks include:
You're looking for what's called the "multiple versions of truth" problem. Most companies above 20 people have it. Naming it, quantifying its cost, and proposing a path to resolving it is extremely high-value work.
This is the domain most auditors skip, which is a mistake because it's the one that most directly speaks to executive-level concerns.
Specific checks include:
When you can say "your team is spending 60% of their time answering repetitive ad-hoc questions that could be eliminated with three well-designed dashboards," that's a finding that resonates with every level of the organization.
Let's talk about numbers. The typical range for a professional Data Audit is $2,500 to $7,500, depending on company size, complexity, and your positioning. Here's how to think about where in that range to position yourself.
At $2,500: This is appropriate for small companies (under 50 employees, under $5M revenue) where the data stack is relatively simple and the engagement is genuinely simpler. Be careful here — it's easy to underestimate scope with early-stage companies because their data is often messier, not simpler.
At $3,500–$5,000: This is the sweet spot for mid-market companies (50–500 employees) and the price point where you can do this without it feeling like commodity work. Most managers can approve this without escalation.
At $5,000–$7,500: This is appropriate for larger or more complex organizations, where the data environment spans multiple business units, multiple tools, or where the stakes of data quality issues are particularly high (fintech, healthcare, regulated industries).
Critical pricing principle: Do not price based on the time it takes you to do the work. Price based on the value of the finding. If your audit reveals a data quality issue that's been inflating churn calculations by 15% — costing the company $500,000 in misallocated retention spend — the value of that finding is enormous. Your fee is a rounding error in comparison.
The framing you use matters. You're not selling "a day of your time." You're selling a Risk Assessment and Opportunity Report for their data environment. The deliverable has a name. It has a format. It produces an artifact that the client can share, act on, and refer back to. This is worth more than time.
Structuring the offer:
Present the audit as a fixed-fee engagement with a clear deliverable. Never present it as a day rate. Here's an example:
"The Data Readiness Assessment is $4,500 and includes: a half-day access session where I review your data stack and speak with your team, a 48-hour turnaround on a written report covering infrastructure health, data quality findings, metric governance gaps, and prioritized recommendations, and a 60-minute readout call where we walk through findings together."
Notice the deliverable is named ("Data Readiness Assessment"), the components are specific, and there's a 48-hour turnaround mentioned — which creates urgency and signals that you're efficient and decisive.
Selling a data audit is fundamentally different from selling hourly consulting or a large project, and most technical people get it wrong because they lead with solution instead of problem.
Here's the structure of a sales conversation that consistently converts.
You are not pitching yet. You are asking questions that help you understand whether this company is a good fit for an audit and what the most likely pain points are.
Effective discovery questions:
These questions do two things simultaneously. They surface the actual pain points (which you will reference when you present the audit), and they demonstrate that you think about data problems in business terms, not just technical terms.
Warning: Do not use this time to show off your technical knowledge. Resist the urge to say "oh, you're using Fivetran? We could probably optimize that significantly." You haven't been hired yet. Listen.
After discovery, summarize what you heard before you make any offer. This is the most underused technique in consulting sales, and it's extraordinarily effective.
"Let me make sure I understand what you've told me. It sounds like the core challenges are: one, you have multiple definitions of 'active subscriber' floating around that create confusion in leadership meetings; two, your data team spends a lot of time on ad-hoc requests and can't get to the roadmap work; and three, you had an incident six months ago where a pipeline broke and nobody noticed for three days. Is that a fair summary?"
When you can reflect their problems back to them more clearly than they articulated them, you demonstrate diagnostic expertise before you've done any work. This is worth more than any credential.
Now you present the audit. Connect it explicitly to what you heard.
"Based on what you've described, a Data Audit would be the right starting point. What I'd do is come in and systematically assess all four of those areas — your pipeline reliability, your data quality, how your metrics are defined and governed, and how your team's time is being used. You'd get a written report with specific findings and a prioritized list of recommendations, and we'd walk through it together. The fee for this is $4,500 and I can typically fit you in within two weeks."
Note that you're not asking "would this be helpful?" You're presenting it as the appropriate solution to the problems they just told you about. This is an important distinction in how buyers perceive your confidence and expertise.
The three most common objections you'll hear:
"We already know what our problems are." This is the most common and most easily handled. Your response: "That's actually a good sign — it means your team is paying attention. What a formal audit adds is a prioritized, documented view that you can bring to leadership, and often we find issues that weren't on the radar that turn out to be significant. The fact that you know some of the problems doesn't mean you've found all of them."
"Can you just quote us for the full project instead?" This sounds like a win but is actually a trap. You don't have enough information to scope a full project accurately, and neither do they. Your response: "I'd love to do that, and I want to make sure any proposal I give you is accurate. The audit is how I get the information I need to scope a full engagement properly. Without it, I'd either underquote and create problems for both of us, or overquote to protect myself, and you'd be paying for buffer you don't need."
"We don't have budget right now." This is sometimes true and sometimes a proxy for "I'm not convinced this is worth it." Probe it: "What does your budget cycle look like? Is this a question of timing, or is there a threshold where it becomes a harder decision internally?" If it's genuine budget constraints, you can discuss timing. If it's hesitation, you need to go back to value.
You've been hired. The audit day is scheduled. Here's how to execute it.
Send this to your client one week before:
Tip: The state of the documentation you receive tells you a lot before you've done any work. If they send you nothing, that's a finding. If they send you a Google Doc that hasn't been updated since 2021, that's a finding. If they send you a well-maintained dbt schema.yml with test coverage, that's a very different kind of company.
Spend the first 90 minutes understanding the landscape, not diving into queries. Walk through:
This is also where you build rapport with the data team. They may be nervous that you're here to evaluate them or criticize their work. Be explicit that your job is to help them make the case for what they need — more resources, better tooling, cleaner data — not to audit their performance as individuals.
Pull up the orchestration tool and start with a simple question: what failed in the last 30 days?
In Airflow, this looks like browsing DAG run history and filtering for failures. In dbt Cloud, it's the run history tab. In Prefect, it's the flow run view. You want to understand:
Then look at the warehouse:
-- In BigQuery: check table freshness by looking at metadata
SELECT
table_name,
last_modified_time,
row_count,
size_bytes / (1024*1024*1024) AS size_gb
FROM `your_project.your_dataset.INFORMATION_SCHEMA.TABLE_STORAGE`
ORDER BY last_modified_time DESC;
For Snowflake, the equivalent is:
SELECT
table_name,
last_altered,
row_count,
bytes / (1024*1024*1024) AS size_gb
FROM information_schema.tables
WHERE table_schema = 'YOUR_SCHEMA'
ORDER BY last_altered DESC;
You're looking for tables that are supposed to be updated daily but haven't been touched in a week, tables that are growing uncontrollably without obvious purpose, and tables with zero rows that are downstream dependencies of things that matter.
This is the core technical work. Run a systematic battery of quality checks on the most critical tables — the ones that feed the reports the business uses to make decisions.
Completeness checks:
-- Check null rates across key fields in a critical table
SELECT
COUNT(*) AS total_rows,
COUNTIF(customer_id IS NULL) AS null_customer_id,
COUNTIF(transaction_date IS NULL) AS null_transaction_date,
COUNTIF(revenue_usd IS NULL) AS null_revenue,
COUNTIF(product_id IS NULL) AS null_product_id,
ROUND(COUNTIF(customer_id IS NULL) / COUNT(*) * 100, 2) AS pct_null_customer_id,
ROUND(COUNTIF(revenue_usd IS NULL) / COUNT(*) * 100, 2) AS pct_null_revenue
FROM `analytics.fact_transactions`
WHERE transaction_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY);
Uniqueness checks:
-- Find duplicate records where you expect uniqueness
SELECT
order_id,
COUNT(*) AS occurrences
FROM `analytics.fact_orders`
GROUP BY order_id
HAVING COUNT(*) > 1
ORDER BY occurrences DESC
LIMIT 20;
Referential integrity checks:
-- Find transactions that reference customers who don't exist
SELECT
t.transaction_id,
t.customer_id,
t.transaction_date,
t.revenue_usd
FROM `analytics.fact_transactions` t
LEFT JOIN `analytics.dim_customers` c
ON t.customer_id = c.customer_id
WHERE c.customer_id IS NULL
AND t.transaction_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)
ORDER BY t.transaction_date DESC;
Distribution and outlier checks:
-- Look for revenue outliers that might be data entry errors
SELECT
transaction_id,
transaction_date,
customer_id,
revenue_usd,
AVG(revenue_usd) OVER () AS overall_avg,
STDDEV(revenue_usd) OVER () AS overall_stddev,
(revenue_usd - AVG(revenue_usd) OVER ()) / NULLIF(STDDEV(revenue_usd) OVER (), 0) AS z_score
FROM `analytics.fact_transactions`
WHERE transaction_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)
QUALIFY ABS(z_score) > 3
ORDER BY z_score DESC;
Consistency checks for categorization fields:
-- Find value inconsistencies in categorical columns
SELECT
product_category,
COUNT(*) AS row_count,
COUNT(DISTINCT customer_id) AS unique_customers
FROM `analytics.fact_transactions`
GROUP BY product_category
ORDER BY row_count DESC;
That last query will often surface things like: "Enterprise", "enterprise", "ENT", "Enterprise Sales" — four values that mean the same thing and will wreck any segmentation analysis.
Document every finding with the query, the result, and the business impact. Don't just write "found nulls in customer_id" — write "found 847 transactions in the last 90 days (4.2% of total) with no customer_id, representing $127,000 in revenue that cannot be attributed to any customer segment."
The afternoon session with a business stakeholder (not from the data team) is often the most revealing part of the entire audit. You're asking questions like:
You will almost always discover that the business stakeholder has a slightly (or dramatically) different understanding of key metrics than the data team does. This is not a failure of either side — it's an organizational problem that your audit is about to name and give them a path to solve.
Also review the BI tool usage logs. In Looker, you can query this from the system activity explore:
-- Looker system activity: find dashboards by view count (last 90 days)
SELECT
dashboard.title,
COUNT(DISTINCT history.id) AS view_count,
COUNT(DISTINCT history.user_id) AS unique_users,
MAX(history.created_date) AS last_viewed
FROM history
LEFT JOIN look ON history.dashboard_id = look.dashboard_id
LEFT JOIN dashboard ON history.dashboard_id = dashboard.id
WHERE history.created_date >= DATE_ADD(now(), INTERVAL -90 DAY)
AND history.dashboard_id IS NOT NULL
GROUP BY 1
ORDER BY view_count DESC;
You'll typically find that 20% of dashboards account for 80% of views, and there are dashboards that haven't been opened in six months. That's maintenance overhead with zero return.
The written report is the artifact that justifies your fee, establishes your expertise permanently in that client's mind, and becomes the proposal for follow-on work. Do not treat it as a formality.
The report should be 10–20 pages (in a well-formatted PDF or Notion document) and follow this structure:
This is the only section some stakeholders will read, so it has to stand alone. It should contain:
Tip: The dollar-impact framing is the single most important thing you can do in the executive summary. "You have data quality issues" is boring. "$340,000 in annual marketing spend is being allocated based on a conversion metric that we found to be overcounted by 23%" is a finding that gets the CFO's attention.
Walk through what you found in the pipeline and warehouse review. For each finding, use a consistent three-part structure:
Finding: What you observed Impact: What it means for the business Recommendation: What should be done about it, at what level of priority
Keep the technical detail moderate here — enough to be credible, not so much that a non-technical reader checks out. If you need to include complex technical details, put them in an appendix.
This is the most emotionally impactful section. Lead with the most significant finding. If you found that 4.2% of revenue transactions can't be attributed to any customer segment, that goes first. Include the actual query output (sanitized if needed) and a clear explanation of how this finding affects any downstream analysis.
Use a risk categorization for each finding: High, Medium, or Low. High means it's actively affecting decisions being made right now. Medium means it's creating future risk. Low means it's a best practice gap that should be addressed eventually.
Document the specific metric definitions you reviewed, whether they're formally documented anywhere, where you found inconsistencies between teams, and what a minimum viable governance process would look like for this company at their stage.
Present the dashboard usage data. List the top 10 most-used dashboards and reports. List any dashboards that haven't been used in 60+ days. Quantify the estimated time the data team spends on ad-hoc requests and what it would take to reduce that.
This is the section that becomes your project backlog. List every recommendation from the previous sections, assigned to one of three tiers:
Strategic note: The recommendations section is where your follow-on work lives. Do not undersell it. Be specific about what each project entails. "Implement a metrics layer using dbt metrics or a tool like Cube.js to create a single source of truth for all core business metrics" is better than "fix the metric definition problem." Specific recommendations are easier to buy.
The readout call is a 60-minute session where you walk through the report with the client. It's not a presentation — it's a conversation. Your job is to make sure they understand the findings, feel the urgency of the high-priority items, and see you as the person who can fix them.
Structure the readout:
That last question is not a sales question. It's a diagnostic question. But it naturally transitions to a scoping conversation. When they say "the metric governance issue is the one keeping our VP of Sales up at night," you say "that's actually one of the projects I outlined in the near-term tier — let me tell you how I'd approach that."
Within 48 hours of the readout call, send a proposal for the first follow-on project. Don't wait for them to ask. The proposal should:
This is how the audit pays for itself many times over. You're not just delivering value in the audit — you're financing the entire relationship through a low-risk entry point.
This exercise is designed to help you build your audit capability before you have a paying client.
Exercise: Conduct a Mock Audit on a Public Dataset
Use the NYC Taxi and Limousine Commission trip data, which is publicly available in BigQuery (the bigquery-public-data.new_york_taxi_trips dataset). Imagine you've been hired by a fictional analytics team at a transportation company that acquired this data.
Step 1: Run the completeness battery. Write queries to check null rates across all columns in tlc_yellow_trips_2022. What percentage of trips have null pickup_location_id? What about passenger_count?
Step 2: Run distribution analysis. Write a query to find trips with fare amounts greater than 3 standard deviations from the mean. What do you find? How would you communicate this as a data quality finding to a non-technical stakeholder?
Step 3: Check for consistency. Write a query to identify all distinct values of payment_type and rate_code_id. Are there values that seem anomalous or undefined?
Step 4: Write a mock finding. Take the most interesting quality issue you found and write it up in the three-part format (Finding / Impact / Recommendation) as it would appear in a real audit report. Make up a plausible business context for why this finding matters.
Step 5: Write a mock executive summary. Based on what you found, write a 150-word executive summary for a fictional client. Include a dollar-impact estimate (you can extrapolate or invent a plausible one).
This exercise will surface common data quality patterns you'll see in nearly every real audit, and it will force you to practice the translation from technical finding to business impact — which is the hardest skill to develop.
You arrive and discover the data environment is a disaster — four disconnected warehouses, five different BI tools, a decade of accumulated cruft. You could spend three days just cataloging the mess. Don't. Your scope is a systematic sample of the highest-stakes areas, not an exhaustive census. If the environment is genuinely more complex than you expected, note it in the report and scope the comprehensive assessment as a separate (paid) project.
A common failure mode is writing the report for the data team instead of for the buyer. If the person who signed the check can't understand Section 2, you've lost the plot. Use plain language in the main sections. Put SQL and technical detail in appendices. Always ask: "If I sent this to someone who doesn't write code, would they understand what the problem is and why they should care?"
Many data freelancers are more comfortable with technical people and skip the business stakeholder interview or treat it as a formality. This is a major mistake. The business stakeholder interview is where you discover the discrepancy between what the data team thinks the business cares about and what the business actually cares about. That gap is almost always an audit finding, and it's almost always one of the most valuable ones.
If you price the audit at $1,500 because you're nervous about the number, you will do resentful work and deliver a mediocre report. The client will sense the lack of confidence and enthusiasm. Price appropriately for the value you're delivering. If a client pushes back hard on $4,500, the right question is whether this is actually the right client, not whether you should lower your price.
Some auditors deliver a beautiful report and then... wait. They assume the client will reach out when they're ready to implement. They don't. Implement the 48-hour follow-on proposal discipline. Send a specific, scoped proposal for the first project while the findings are fresh and the urgency is high. If you wait two weeks, you're competing with their internal priorities and budget cycles.
It seems obvious, but access issues are one of the most common ways an audit day gets derailed. Send the access checklist two weeks out. Follow up one week out. Have a contingency plan for what you'll do if access isn't ready on the day (spoiler: you can still do stakeholder interviews and documentation review, and you charge the same fee regardless).
This is rarer than you'd think, but it happens. If the data environment is so immature that you can't run meaningful quality checks because there's no real warehouse yet, reframe the deliverable. An audit of a very early-stage environment becomes an Architecture Assessment — documenting what exists, what's missing, and what the roadmap should be to build a real data foundation. The format is the same. The findings are just different in nature.
Also rarer than you'd think, but a real scenario. If a company has good infrastructure, low null rates, versioned metric definitions, and healthy BI adoption, your job isn't to manufacture problems. Note the maturity honestly in the executive summary, then focus the recommendations on the next level of value: predictive capabilities, advanced segmentation, cost optimization, or more sophisticated governance. Sophisticated clients appreciate honest assessments — they've usually hired auditors before who inflated findings to justify implementation work, and your candor is itself a differentiator.
Let's bring this together. What you've learned in this lesson:
A Data Audit is a scoped, time-boxed, fixed-fee service that covers four domains: infrastructure health, data quality, metric governance, and usage/ROI. It's priced at $2,500–$7,500 depending on company size and complexity, and it's sold as a value-based engagement, not a time-based one.
The sales conversation leads with discovery, follows with reflection, and presents the audit as the appropriate diagnostic tool for problems the client has articulated — not as a generic offering. The audit day is structured: morning for orientation and infrastructure review, late morning for data quality queries, afternoon for stakeholder interviews and BI usage analysis.
The deliverable is a 10–20 page report with an executive summary, domain-by-domain findings in a Finding/Impact/Recommendation format, and a tiered recommendation list that becomes the project backlog. The readout call transitions naturally to a follow-on proposal, which is sent within 48 hours and priced at 5–15x the audit fee.
Your next steps:
Run the hands-on exercise using the BigQuery public dataset. Write at least one full Finding/Impact/Recommendation entry and one executive summary paragraph. This will feel awkward the first time. Do it anyway.
Write your service description. In 200 words or less, describe your Data Audit offer, including what it covers, what the client receives, and the price. Use the language from this lesson as a model, but make it your own.
Identify three target clients. Think about companies you have existing relationships with — former employers, vendors, companies you've spoken with. Which of them would benefit from a data audit? Draft one paragraph explaining what you'd expect to find and why it matters for each.
Set your price and commit to it. Decide on your starting price and practice saying it out loud without hedging. "The audit is $4,500" is different from "I typically charge around maybe $3,500 to $5,000 or so depending on what we need." Confidence in pricing is a skill that develops with practice.
Read the follow-on lesson on scoping and pricing implementation projects. The audit is the entry point. The real leverage in your freelance practice comes from what happens next.
The practitioners who build sustainable, high-margin consulting practices aren't the ones who know the most SQL or can architect the most sophisticated data stack. They're the ones who know how to frame their expertise as a product, demonstrate that expertise quickly and credibly, and create a natural path from that demonstration to a long-term engagement. The Data Audit is that path. Go build it.
Learning Path: Freelancing with Data Skills