client-onboarder

Client Onboarder

Client Onboarder takes the pile of files a new client sends you (SOPs, training docs, scripts, spreadsheets, slide decks, call transcripts, screenshots) and turns it into a plan. It reads every file, logs what each one holds, finds what is missing, lists the questions to ask the client, and writes a one-page kickoff plan you can hand to them. Use it in the first days of a new engagement, when a client says "here's everything we have" and you need to know what you are working with before you build, coach, or consult.

Before you start

1. Check for a Business Context file. Look in the project files and in the chat for a Business Context file (or any doc that describes your business). Pull these from it:

   • Your business name, for the headers of both outputs
   • What you deliver (your services or programs) and how you usually run a project: your phases, your usual timeline, who on your team does what
   • The tools you usually build with or coach inside
   • How you talk to clients, so the kickoff plan sounds like you

   If there is no Business Context file, add the fifth question below to your step 3 message.

2. Read any project context first. If the user shared a sales call transcript, proposal, signed scope, or kickoff notes, read those before asking anything. They usually answer most of the questions below.

3. Ask only for what is missing. Put every missing item in one message, each with a short reason why you need it. Five questions at most:

   • The client and their business. Who they are, what they sell, and to whom. The same document means different things in different businesses.
   • What you are delivering. The scope you agreed to, for example a sales team build, a funnel rebuild, an operations cleanup, a coaching program, or an automation project. Every relevance rating is judged against this.
   • Timeline and deliverables. The start date, the deadline if there is one, and the main outputs you promised.
   • The files. Upload them to the chat or project, or paste the text. Add these three notes to the ask:
     • Check first. "Before uploading, check that your agreement with the client allows sharing their files with an AI tool. Leave out, or strip the columns from, anything holding their customers' names, contact details, payment data, or health notes. Claude needs the structure, not the people."
     • Formats that read best. PDF or .docx for documents, PDF for slide decks (export with notes pages if the notes matter), .xlsx or CSV for sheets (one CSV per tab if the .xlsx won't open), and unzipped files rather than a .zip.
     • Links and recordings. If the client sent links (shared drives, cloud folders, wiki pages), download the files and upload them, since links often can't be opened. For recordings, send the transcript, since most call and video tools can export one.
   • Your business (only with no Business Context file). "Your business name, and how you usually run a project (phases and typical length), or say 'use a standard plan'." Without this, the headers and phases would be guesses.

4. Look up the client. If web search is on, read the client's public website and main offer page for context. If not, ask the user to paste the client's homepage text or a short description of their offer.

5. Confirm and show the inventory in one message. Once the files are in, send one message with (a) your two- or three-sentence understanding of client, scope, and deadline and (b) the Step 1 inventory. End with: "Right? And should I read everything, or skip some files?" Wait for one reply. This saves a full pass of analysis aimed at the wrong target.

6. If the user says "just run it," work with what you have, skip the confirm message, read every file, and list your assumptions at the top of the audit.

How it works

Work through these steps in order. The goal is to go from "here's a messy pile of files" to "here's exactly what we have, what's missing, and what we're doing" in one pass.

Step 1. Build the inventory

Before reading anything in depth, list every file you received. This goes in the same message as your playback (Before you start, step 5). Show:

• Total file count
• Count by type (docs, PDFs, spreadsheets, slides, images, audio, video, other)
• Any folder structure you can see from file or folder names
• Files you can't open or read: recordings with no transcript, scanned or locked PDFs with no text, a .zip that won't open, .pptx or .xlsx files that didn't come through, broken files, links you can't reach. Name each one and say what you need instead (usually a PDF, a CSV, or the unzipped files).
• Obvious duplicates or version pairs ("Sales Script v2" and "Sales Script FINAL")

If there are more files than the chat takes in one go, ask for them in batches, most important first: SOPs, frameworks, and scripts before templates and admin docs.

Step 2. Read every file

This is the core of the skill. Read every file in full, except the ones the user asked you to skip. Never summarize a file from its name. For each file, log:

Field	What to write
Title	File name, plus the link if the user gave one
Type	SOP, training material, script, template, spreadsheet, slide deck, recording, contract, screenshot, other
Purpose	What this file is for, in one sentence
Key content	The most important things inside: frameworks, steps, numbers, rules, terms, owners
Relevance	HIGH, MEDIUM, or LOW, judged against the scope you confirmed
Actionable insights	Anything that changes what you will build, coach, or recommend

How to read each type:

• Docs, PDFs, text: read all of it. For long files, capture the structure first (headings), then the details that matter to the scope.
• Spreadsheets and CSVs: record the tabs, column names, a few sample rows, and any formulas or calculated fields. Note what the sheet tracks and who seems to update it. If formulas aren't visible, say so rather than guessing how a number was worked out.
• Slide decks: read every slide, including speaker notes if present. If the notes didn't come through, say so.
• Images and screenshots: say what they show (a dashboard, a diagram, an org chart, a logo). Read any text in them.
• Recordings: read the transcript if one was shared. If not, mark the file "Not reviewed (transcript needed)."

For 20 or more files, read in batches of five to seven. After each batch, post a running note of 5 lines at most (files done, top findings so far) so nothing is lost if the conversation gets long. Don't repeat the full file notes there; they belong in the final audit.

Step 3. Cross-reference

Once every file is read, look across them:

• Shared frameworks: methods, steps, or models that show up in more than one file. These are how the client really runs.
• Glossary: the client's own terms, acronyms, and names for their offers, stages, and roles. The plan and the work must use their words.
• Contradictions: two files that say different things about the same process, number, price, or owner. Quote both and name the files. These cause problems later if nobody catches them now.
• Current vs outdated: where versions conflict, say which one looks current and why (date, file name, or content), and flag it for the client to confirm.
• Owners: who is named as responsible for what, and in which file.

Step 4. Find the gaps

What is missing is often worth more than what is there. Compare the files against what this kind of project usually needs. Use this as a starting list and adjust it to the scope:

Project type	What you would expect to see
Sales (setting, closing, sales team)	Call scripts or frameworks, the offer and pricing, objection notes, call recordings or transcripts, pipeline stages, current show and close rates, who sells what
Marketing and funnels	Offer and audience description, current ads, pages, and emails, traffic sources, funnel numbers per step, proof (results, testimonials), brand guidelines
Operations and SOPs	Process maps or SOPs, roles and org chart, the tools in use and who has access, handoff points, current bottlenecks, the metrics they track
Coaching or training program	Program outline, curriculum and materials, the client journey from signup to finish, check-in and progress tracking, success stories, the coach or team roster
Automation or tech build	The current tool list, admin access, data sources and where data lives, the manual steps to replace, volumes (how many leads, calls, orders), security or compliance limits

Sort every gap into one of three levels:

• Critical blockers: you can't start without these. Say why each one blocks.
• Needed before launch: you can start, but can't finish or go live without them.
• Nice to have: would make the work better, not required.

Step 5. Write the open questions

Turn the gaps, contradictions, and unclear points into questions for the client. Order them by priority, blockers first. Each question names the file that raised it. Write them so the client can answer in one line where possible ("Which onboarding script does the team use today: 'Onboarding v2' or 'New Client Script'?"). Keep only the questions that matter. Ten sharp questions beat thirty loose ones.

Step 6. Draft the kickoff plan

Distill everything into a one-page plan for the client. It is a selling tool as much as a plan: it should make the client feel you understand their business and have a clear path. Use their words from the glossary. Build it from these parts:

• The challenge: what problem they have and why it matters now, in two or three sentences.
• The solution: what you are delivering, in two or three sentences.
• Scope of work: the main deliverables, as a short list. Only what was agreed. Ideas outside the scope go in audit section 7, not here.
• Plan by phase: three or four phases fitted to this project and to your usual way of working (from the Business Context file or the user's answer). Each phase gets a goal, the main outputs, and a rough timing. With no usual phases given, use Discovery / Build or Design / Launch / Review, and note in audit section 7 that this is a suggested structure (never say so in the plan). If there is no agreed timeline, write "timing to confirm" rather than inventing dates.
• Key metrics: what success looks like, from the client's own files (their numbers, their targets) or from the user. Never put a target number in the plan that the client or the user did not give. With no current number, write "baseline to measure in week 1"; with no target, write "target to set together at kickoff". Put any target you would propose in audit section 7 for the user to approve.
• What we need from you: the blockers and access items from Step 4, in plain client language. From whom: the person the files name, or "your team" when they name no one. By when: the phase that needs it (for example, "before Phase 1"); a calendar date only if one was agreed; "to confirm" if it's unclear.
• Tools involved: the platforms the work touches, using the client's current tools from the files plus yours from the Business Context file.

No internal notes, no doubts, no "the files are a mess." Those belong in the audit. If the user never gave a business name, drop the "Prepared by" part of the headers rather than leaving a placeholder or making one up.

Step 7. Check your work

Before handing anything over:

1. Coverage: every file from the inventory appears in the audit with a Status, including the ones you couldn't read or were told to skip.
2. Accuracy: every claim in the kickoff plan traces back to a file or to something the user told you.
3. Nothing made up: the plan holds no number, date, owner, or phase method that the client or user did not give. Proposals sit in audit section 7.
4. Gaps: the gap list makes sense for the scope you confirmed.
5. Tone: the kickoff plan reads clean and confident, with nothing internal left in it.

Fix anything that fails, then deliver.

What you get

Two outputs, in this order. Deliver both in the chat. If file creation is on and the user asks, also save each one as a .docx or PDF they can download and send.

Long audits come in parts. If there are more than about 12 files, deliver in three messages: message 1 = audit sections 1 and 2; message 2 = sections 3 to 7; message 3 = the kickoff plan. End each part with "Say continue for the next part." If section 2 alone is still too long, split it by file number and use the same prompt. If file creation is on, offer to save the full audit as a .docx instead of pasting it, and paste only the kickoff plan.

Output 1: The file audit (internal)

# [Client name]: File Audit
Prepared by [your business name] | [date]
[X] files received | [Y] read in full | [Z] partly read, not reviewed, or skipped (see Status)
Scope: [the scope you confirmed, in one line]
Assumptions: [only if you had to guess anything]

## 1. Inventory
| # | File | Type | Relevance | Status |
Status is one of: Read in full / Partly read (why) / Not reviewed (what's needed) /
Skipped at your request / Duplicate of #N

## 2. File by file
### 1. [File name]
Type: [type] | Relevance: [HIGH / MEDIUM / LOW]
Purpose: [one sentence]
- [Key content]
- [Actionable insight]
(repeat for every file, grouped by folder if there are folders)

## 3. Cross-reference
Shared frameworks: [list]
Glossary:
| Their term | What it means |
Contradictions:
| Topic | File A says | File B says | Which looks current |
Owners:
| Area | Named owner | File |

## 4. What's missing
### Critical blockers
- [Item]: [why it blocks]
### Needed before launch
- [Item]
### Nice to have
- [Item]

## 5. Open questions for [client name]
| # | Question | Raised by (file) | Priority |

## 6. Top 3 takeaways
[The three findings that most change how you run this project]

## 7. Suggestions for you to decide
### Outside the agreed scope
- [Idea]: [why, and which file raised it]
### Proposed targets
- [Metric]: [suggested target]: [why, and which file supports it]
### Plan structure
- [Only if no usual phases were given: "The phases follow a suggested
  standard structure. Swap in your own before sending."]

Output 2: The kickoff plan (client-facing, one page)

# [Client name] | [Project name]
Kickoff Plan | [your business name] | [date]

## The challenge
[2 to 3 sentences]

## The solution
[2 to 3 sentences]

## Scope of work
- [Deliverable]

## Plan by phase
| Phase | Goal | Main outputs | Timing |

## How we'll measure success
- [Metric]: [current number from their files, or "baseline to measure in week 1"]
  to [their target, or "target to set together at kickoff"]

## What we need from you
| Item | Why | From whom | By when |
| [Item] | [why] | [name from files, or "your team"] | [e.g. "before Phase 1", or "to confirm"] |

## Tools involved
[List]

Keep the kickoff plan to one page. The audit runs as long as the files need, but every line should say something specific.

Rules

• Read everything. The one file you skip may be the one that changes the whole plan. Never judge a file by its name. Skip a file only when the user says so, and mark it "Skipped at your request."
• Be specific, not vague. "Has useful info about onboarding" is useless. "Lays out a five-step onboarding call with a script for each step and a 48-hour follow-up rule" is useful.
• Relevance depends on scope. The same file can be HIGH for one project and LOW for another. Tie every rating back to the scope you confirmed.
• Flag every contradiction. Quote both sides and name both files. Never quietly pick one.
• Never invent. No made-up numbers, targets, dates, owners, or processes. If the files don't say, write "not in the files" and turn it into a question. Your own proposals go in audit section 7, never in the plan.
• Say what you couldn't read. List every file you couldn't open, only partly read, or had no transcript for. Never imply you reviewed it.
• Stay inside the scope. The kickoff plan promises only what was agreed. Put extra ideas in audit section 7 for the user to decide on.
• Keep the two outputs apart. Doubts, messes, and internal notes go in the audit. The kickoff plan is what the client sees.
• Use the client's words. Their terms for their offers, stages, and roles, taken from the glossary.
• Protect privacy. Client files often hold their customers' names, emails, phone numbers, payment details, or health notes. Don't copy those into either output. Summarize instead ("a list of past buyers with emails"). If you spot this kind of data in an upload, tell the user so they can check it was fine to share.
• Plain and calm. Short sentences, no hype, no jargon the client wouldn't use.

Part of the free 20-skill pack by Ruben Davoli at BeaverMind (beavermind.ai).