The Data Contractor's Guide to Onboarding a New Client

The first two weeks on a new data engagement are the most important two weeks of the whole project. Not because you’ll solve anything in that window — you won’t. But because everything you do in those two weeks shapes how the rest of the engagement goes.

Get it right and you build trust, surface the real problems, and set yourself up to do good work. Get it wrong and you spend six months fighting uphill.

I’ve done this enough times to have a process. Here’s how I run a new client onboarding.

Week One: Listen More Than You Talk

The hardest thing about starting a new engagement is resisting the urge to immediately show how much you know. You’ve seen this pattern before. You have opinions. You want to be useful.

Slow down.

The first week is intelligence gathering. Your goal is to understand the landscape, not to fix it.

The stakeholder tour

Schedule 30-minute conversations with everyone who touches the data — not just the person who hired you. The analyst who builds the reports. The ops person who does the imports. The sales rep who complains that the CRM is wrong. The exec who makes decisions based on dashboards.

Each person has a different relationship with the data and a different theory of what’s broken. You need all of those theories before you can figure out which one is right.

Ask each person two questions:

1. What’s the biggest data problem you deal with?
2. If this engagement goes perfectly, what does that look like for you?

Write down the answers verbatim. Don’t editorialize yet.

The systems inventory

Where does data come from? Where does it go? What lives in between?

I build a simple map: sources on the left (CRM, website, ad platforms, spreadsheets), destinations on the right (dashboards, reports, downstream systems), and whatever pipelines or manual processes connect them in the middle.

This doesn’t need to be fancy. A whiteboard sketch or a quick text list is fine. The point is to see the whole flow, including the parts that are “I email Karen a CSV every Monday and she pastes it into Salesforce.”

That last part is always somewhere.

The access checklist

Before you can do anything, you need access. Start the access request process on day one — not because you’ll use it immediately, but because access provisioning is slow and you don’t want to be blocked in week three waiting for someone to add you to a database.

My standard access list for a new engagement:

• Read access to production databases (or a read replica — never write to prod)
• The BI tool / reporting platform
• The CRM
• Any data warehouse or staging environment
• Relevant Slack channels or communication threads
• Documentation (Notion, Confluence, Google Drive folder — wherever it lives)

Ask for read-only first. Ask for write access when you have a specific reason.

The First Data Audit

Somewhere in week one, pull a sample of the core dataset and run a quick quality audit. Not comprehensive — just a first look. You’re trying to form a hypothesis about where the real problems are before you commit to a project scope.

I run the same queries every time:

-- Row counts and null rates for key fields
SELECT
    COUNT(*) AS total_rows,
    ROUND(100.0 * COUNT(email) / COUNT(*), 1)   AS email_fill_pct,
    ROUND(100.0 * COUNT(phone) / COUNT(*), 1)   AS phone_fill_pct,
    ROUND(100.0 * COUNT(company) / COUNT(*), 1) AS company_fill_pct,
    MIN(created_at) AS earliest_record,
    MAX(created_at) AS latest_record
FROM contacts;

-- Top values in key categorical fields (spot-check for garbage)
SELECT status, COUNT(*) AS cnt
FROM leads
GROUP BY status
ORDER BY cnt DESC
LIMIT 20;

What I’m looking for: obvious data quality issues, how complete the key fields are, and whether the date ranges make sense. This takes an hour and gives me enough to have an informed conversation about scope.

Week Two: Align Before You Build

By the end of week one, you have:

• A systems map
• A stack of stakeholder opinions about what’s broken
• A first-pass data quality assessment
• Access (hopefully)

Now you synthesize. What are the real problems? What’s actually causing them? What can you fix, what’s out of scope, and what’s someone else’s job?

The kickoff memo

I write a one-to-two page kickoff memo and send it before any formal kickoff meeting. It covers:

1. What I heard — my summary of the stakeholder conversations, reflecting back what each person said
2. What I found — the data quality issues I spotted in the first audit
3. My hypothesis — what I think the root cause is (this is often different from what people said in the interviews)
4. Proposed scope — what I’m planning to tackle and in what order
5. What I need — any blockers, access gaps, or decisions that need to be made

The memo does several things. It demonstrates that you listened. It surfaces misalignments before they become mid-project surprises. And it creates a written record of scope before work begins — which protects both you and the client.

The one thing rule

Every engagement needs a primary deliverable — one thing that, if you accomplish nothing else, means the project was worth doing. Not a list of five things. One thing.

This is harder than it sounds. Clients often want everything. Your job is to help them prioritize by asking: “If we could only do one thing in the next 90 days, what would have the most impact?”

The answer shapes everything else. Once you know the one thing, you can build backwards to a work plan.

The Ongoing Habits

Two things I do throughout every engagement that consistently pay off:

Weekly written updates. Not a long report — four or five bullets covering what I did, what I found, what I’m doing next, and any blockers. Sent every Friday. Clients who don’t hear from contractors assume nothing is happening. This simple habit keeps everyone aligned and demonstrates progress even in weeks where the work is exploratory.

A running issue log. Anytime I find a data quality problem I’m not fixing right now, I log it: table name, column, description of the issue, approximate impact. By the end of the engagement, this becomes a punch list of known issues the client can address after you’re gone. It’s also valuable proof of work — concrete evidence of what you found and flagged.

The Mistake I Used to Make

Early in my career, I would dive straight into fixing things. Skip the interviews, skip the systems map, skip the memo. I thought showing up and immediately producing work demonstrated value.

What it actually did was build the wrong thing, faster.

The problems clients describe are often symptoms. The actual problems — the root causes — are usually somewhere upstream. You can’t find the root cause without the stakeholder tour, the systems map, and the data audit. And if you start building without finding the root cause, you’ll spend a lot of time doing technically good work that doesn’t actually solve anything.

The two-week onboarding isn’t overhead. It’s the most leveraged thing you do on the whole engagement.

— Matthew