The Client Onboarding Playbook for AI Automation Projects

I’ve seen AI projects fail at the starting line. Not because the technology doesn’t work, but because nobody got aligned on what the project is.

Client thinks it’s a 3-month, $20k automation. You think it’s a 6-month, $50k platform build. By month three, both sides are frustrated.

This is why I have an onboarding playbook — a structured process that moves from “let’s explore AI” to “we’re actually building this” with clear expectations at every step.

This playbook has prevented miscommunication disasters three times. It’s worth following.

Phase 1: Discovery Call (Week 1)

Time: 1 hour · Attendees: Client decision-maker, me (consultant) · Goal: Understand the problem, qualify the opportunity

What I’m trying to learn:

1. What problem are you solving? Don’t accept vague answers. “We want to automate our documents” is too broad. Dig: which documents, how many per month, who processes them today, how long does it take, what’s the error rate, what would success look like. You want a specific, quantifiable problem.
2. Who is the champion? Who on their team cares about solving this? Who will clear the budget? Who will be your point of contact? If you don’t know, the project will stall when decisions need to be made.
3. What’s the current process? Walk through it step-by-step. Understand where AI adds value and where it doesn’t. Ask: “If I gave you a perfect AI system today, what would you do with it?” If they don’t have a clear answer, the project isn’t ready.
4. What’s your timeline? When do they need it done? Is this “nice to have” or “blocking our growth”? Ask: “If this took 6 months instead of 3, would you still want to do it?” The answer tells you whether it’s urgent.
5. What’s your budget? Don’t be shy. Ask directly what the total budget is — consulting, infrastructure, and ongoing. If they won’t say, it’s a red flag. Projects without budget clarity always end badly.
6. What are the constraints? Data privacy, compliance, integration requirements, technical debt. These shape the architecture and timeline.

If the answer to all six questions is clear and credible, move to Phase 2. If you’re unsure about the problem, timeline, or budget, push for clarity before proceeding.

I’ve walked away from projects where the decision-maker couldn’t answer these questions. It’s better to bail now than work with a client who doesn’t know what they want.

Phase 2: Data Audit (Week 1-2)

Time: 4-8 hours across multiple visits · Attendees: Client technical lead, operations person, me · Goal: Understand data quality, format, volume, and sensitivity

What I’m auditing:

• Data sources. Where does the data live — PDF folder, email, database, web scraping? Look at 10 recent examples representative of the dataset, the best case (cleanest data), the worst case (messiest data), and edge cases (unusual formats, missing fields).
• Data quality. How consistent is the format? How many errors? Sample test: have Claude extract data from 5-10 samples. What’s the accuracy? What fails? If accuracy is under 80% on your sample, the project will struggle at scale.
• Data privacy and compliance. Does the data contain PII, PHI (medical), PCI (payment cards), or trade secrets? Each requires different handling, which affects architecture and cost. Ask: where can this data go, can it touch third-party APIs, does it need to stay in your VPC?
• Integration points. Where does the output go — Salesforce, NetSuite, a CSV on a shared drive, a custom system? Integration complexity often determines project timeline more than extraction does.
• Volume and frequency. How many items per month, per year, and what are the seasonal variations? This shapes infrastructure cost and scaling decisions.

Output from Phase 2: a one-page data audit report covering data source and format, sample accuracy (Claude test on 10 items), quality assessment, privacy and compliance considerations, integration requirements, and volume forecast.

Phase 3: Architecture Proposal (Week 2-3)

Time: 4-6 hours, mostly my work · Attendees: Me, technical lead if discussion is needed · Goal: Define the solution, timeline, and cost

What goes in the proposal:

• Problem statement. One paragraph recapping their problem in your words. Get buy-in that you understand it correctly.
• Proposed architecture. A diagram and description of how data flows — input, processing, output — and what AWS services and Claude are doing. Keep it simple. They don’t need every detail, but they should understand the flow.
• Success criteria. What does done look like? Examples: process 100 invoices per month with 95%+ accuracy, extract key terms from contracts in under 30 seconds per document, integrate results into Salesforce automatically. Be specific and measurable.
• What’s included. Discovery and planning (8 hours), architecture design (6 hours), initial MVP development (4-6 weeks), monitoring and alerting setup, documentation and training, and 30 days of support post-launch. Be equally clear about what’s not included — ongoing maintenance, additional features, scale-up to 10x volume, integrations you didn’t anticipate.
• Timeline. Week 1: finalize requirements and get environment access. Weeks 2-3: build MVP. Week 4: test with real data and iterate. Week 5: handle edge cases, add monitoring. Week 6: deploy to production, train the team, hand off.
• Cost. Break it down — consulting hours, infrastructure (AWS, Claude API) per month for the first 12 months, one-time setup, and a total first-year figure. Include cost scenarios if they scale beyond the initial estimate.
• Risks and mitigations. “Data quality is lower than expected” → build thorough error handling. “Integration with Salesforce takes longer” → scope that work separately. “Requirements change mid-project” → use an agile approach, but scope creep costs extra.
• Next steps. They review and approve the proposal, we draft a detailed SOW, they secure budget and environment access, we kick off Week 1.

Proposal format: a well-designed PDF or Google Doc, 3-5 pages max, with one architecture diagram and one timeline diagram. Make it easy to read.

Phase 4: Statement of Work (Week 3)

Time: 1-2 hours · Attendees: Me and their decision-maker, maybe legal or finance · Goal: Formalize the agreement

SOW should include:

• Scope of work. A clear list of what you’ll build and what you won’t. In scope: extract data from PDFs using Claude, store results in DynamoDB, email notifications to the ops team, a monitoring dashboard. Out of scope: integration with their ERP system, a mobile app for reviewing results, training for more than 5 people.
• Deliverables. Terraform code in their GitHub repo, Lambda functions with documentation, monitoring dashboards, a runbook for operations, and a training session.
• Timeline. Specific weeks and milestones, plus a launch date. Week 1: setup and requirements finalization. Weeks 2-3: core development. Week 4: testing, documentation. Week 5: deployment, training.
• Cost and payment. Total cost and payment schedule — for example, 50% upon signing and 50% upon completion, or 25% per sprint across four payments.
• Support. 30 days of post-launch support included; beyond that, a support retainer at a set monthly rate.
• Assumptions. The client provides AWS and API access by Week 1, has a technical person available a few hours per week for sync and decisions, tests with real data during Week 4, and requirements won’t change significantly mid-project without a scope adjustment.
• Terms. A cancellation fee if the project is cancelled after kickoff, net-30 payment, and clear IP ownership — you own the code, they license it.

Keep the SOW clear and professional. Ambiguity creates disputes.

Phase 5: Kickoff (Week 1)

Time: 2-3 hours across the week · Attendees: Me, client decision-maker, tech lead, operations person · Goal: Align everyone on requirements and start building

Kickoff week activities:

1. Environment setup (Day 1). Confirm AWS account access, API keys (Claude, MLS, integrations), data access, and communication channels.
2. Detailed requirements (Day 2). Walk through the problem again with the full team. Make sure the tech lead understands the requirements.
3. First milestone (end of Week 1). A proof of concept: process one document, extract data, validate the output. Share the code and results with the client and get feedback — are we on the right track?
4. Weekly sync schedule. A fixed slot — say, Tuesdays 10am for 30 minutes — to review progress, blockers, and decisions needed. This consistency prevents miscommunication.

Common Misalignments (and How to Prevent Them)

“We thought it would take 4 weeks, not 12 weeks.”

Prevented by a detailed timeline in the proposal and SOW. Be realistic. If it looks like 3 months, say 4 to account for unknowns.

“The accuracy is 80%, we need 95%.”

Prevented by the data audit in Phase 2. Test Claude on real data upfront and set realistic accuracy expectations based on data quality.

“We need to integrate with Salesforce. That wasn’t in the original plan.”

Prevented by the integration-points question in the Phase 2 audit. If Salesforce integration is needed, it belongs in the original architecture. If it’s “nice to have,” it’s out of scope and costs extra.

“We want to customize the UI, add this new feature, change the data model.”

Prevented by a clear scope and an explicit “out of scope” section in the SOW. When they ask for new features, you can say: “That’s a great idea. It’s outside the current scope. We can add it as a Phase 2 project for $X.”

The One-Pager: Keeping Everyone Aligned

At the end of each week, send a one-page status update:

Simple. Clear. Prevents surprises.

Exit Criteria: When the Project Is “Done”

Define this upfront:

• MVP deployed to AWS
• Monitoring and alerting configured
• Documentation complete — runbook, architecture, code comments
• 30 days of production data processed successfully
• Team trained (1-hour session plus a written guide)
• Handoff complete — they can operate it without me

Once these are done, you’re done. Anything beyond that is a separate project.

After Launch: The Relationship

If you did this right, the client now has a working system, code they own, documentation they can understand, and confidence that you delivered.

Some will want ongoing support. Offer a retainer — a flat monthly fee for monitoring and a few hours of support, with ad-hoc help beyond that billed hourly.

Most will just keep it running. Some will call in a year and ask for Phase 2: new features, scale to 10x, new integrations.

Good onboarding creates clients who want to work with you again.

The Checklist

Use this for every project.

Phase 1: Discovery

• Understood the problem (specific, quantifiable)
• Identified the champion
• Know the timeline and budget
• Know the constraints

Phase 2: Data Audit

• Reviewed 10+ data samples
• Tested accuracy with Claude
• Understand privacy and compliance
• Know the integration points
• Forecasted volume

Phase 3: Proposal

• Architecture diagram drawn
• Timeline specific, week by week
• Cost broken down
• Success criteria defined
• Client approved

Phase 4: SOW

• Scope of work clear (in and out)
• Deliverables listed
• Timeline confirmed
• Cost and payment terms defined
• Assumptions documented

Phase 5: Kickoff

• Environment access confirmed
• Requirements review done with the full team
• Weekly sync scheduled
• First milestone targeted

Follow this, and you’ll avoid the miscommunication disasters that kill projects.