The Day-One Client Onboarding Doc That Kills the 'Wait, You Didn't Tell Me' Calls

Tuesday morning. The kickoff was Friday. You're three days in and your phone buzzes — Slack ping from the client: "Hey, quick one — where do I send the invoice? Also, who's reviewing the first round? And what's the timeline again?"

You stop what you were doing. You type out three answers. You feel a small annoyed knot in your chest because all of that was in the proposal. Then on Wednesday the same client asks one of the questions again, in a different channel, with a different phrasing.

This keeps happening because the proposal isn't where clients look once the project starts. The proposal is sales material. The minute the deposit lands, they archive the PDF and never open it again.

Quick honest note before we start. I'm not a project manager and I'm not a customer success coach. I'm a dev — I build DocsAura, a tool freelancers use to ship client docs fast. I just keep watching this exact pattern in user data, and I asked a few people who run client work for a living what they do about it.

What they do is send one document on day one — same shape, every project — and most of the week-one chaos goes away.

What follows is the seven-section layout they use. Each section has a one-line reason it's there, a verbatim sample you can copy, and a quick scenario showing what it prevents. Total time to fill in: about 15 minutes per project. Use it as a checklist or paste it into a single page and send it the same hour the deposit clears.

Step 1 — Name the humans, with response windows

Most week-one confusion is not about the work. It's about who answers what. List every person on the project, what they do, how to reach them, and how fast they typically reply. Including yourself.

People on this project

• You (Anna, Head of Marketing) — final approver on copy and design. Email: [email protected]. Reply window: same day on weekdays.
• Me (Dominik, designer) — I do the work and send updates. Email: [email protected]. Reply window: within 4 hours on weekdays, next morning on weekends.
• Tom (your developer) — implements the design after approval. Loops in from week 3. Email: [email protected].

Let's say Anna goes on vacation in week two and her designer (you) needs an answer on copy. Without this list, you ping Anna, wait two days, miss your own deadline, and then explain to Anna why things are late. With this list, Anna already wrote "Tom can sign off on copy if I'm out" in week one — you ping Tom on Tuesday, the answer comes Wednesday, the project moves.

Step 2 — Pick one place to talk

The single biggest cause of "wait, you didn't tell me" calls is the work being split across email, Slack, WhatsApp, and a phone call. The client tells you something in WhatsApp Wednesday night. You don't see it. They assume you did. By Friday it's a mess.

Pick one tool. Write it down. Tell them what gets used where.

How we talk

• Slack (#acme-redesign channel) — day-to-day questions, async updates, link sharing.
• Email — anything contractual: scope changes, invoices, approvals. If it's in email, it counts. If it's in Slack only, it doesn't count for scope changes.
• Call — Tuesdays 14:00–14:30 CET, weekly check-in. Anything else by request.

Let's say in week three the client messages you on WhatsApp asking for a fourth landing page (the contract was three). You missed it because WhatsApp wasn't the channel. Two weeks later they ask where the fourth page is. You point at this line. The conversation is awkward for ninety seconds and then it's fine — instead of a forty-minute argument about whether the request was real.

Step 3 — Restate the deliverable in one sentence

Open the doc and write what you are building, in one sentence, in the client's words. Not the proposal's marketing language. The actual thing.

What you're getting: a redesigned homepage, pricing page, and case study template for acme.com, delivered in Figma + final HTML/CSS files, ready to hand to your developer by July 12.

That's it. One sentence.

Let's say someone new at the client's company gets added to the project in week two. Their first question is "so what exactly are you doing for us?" You point them at this line. They get it in five seconds. You don't end up on a thirty-minute re-introduction call.

Step 4 — Put the dates that matter in one list

Not a Gantt chart. Not a project plan. A short list of dates a non-project-manager can read on a phone.

Key dates

• May 22 (Thu) — first round of homepage designs sent to you.
• May 27 (Tue) — your feedback due back to me.
• June 5 (Thu) — second round, final design direction.
• June 19 (Thu) — all three pages, ready for developer handoff.
• July 12 (Sat) — final files delivered. Project closes.

If a date matters to the bill, mark it. Use real calendar dates, not "week 3, day 2".

Let's say feedback doesn't come back by May 27. You can send a one-line nudge — "Quick reminder, feedback was due yesterday. Anything you need from me to unblock it?" — without it feeling pushy, because the date is something you both agreed on in writing.

Step 5 — Spell out how approval works

This is the line that prevents the "oh, my boss needs to see it first" phone call at the end of week three.

How approval works: I send each round as a Figma link in our Slack channel. You reply in Slack with one of:

• Approved. (we move on)
• Approved with notes. (notes inline in Figma — I do them, no second round needed)
• Needs another round. (counts as one of your two included revision rounds)

A third round triggers an extra-revisions invoice at €450/round. I'll always check before that happens.

Who can approve: Anna. If Anna is out, Tom can approve copy only. Design approvals always wait for Anna.

Let's say in week three you send round one. Anna sends back fifteen tracked-change comments. Without this section, you do all fifteen for free and then she asks for "just a few more tweaks" the following week. With this section, you reply "Hey — round 1 had 15 changes which is normal, included in your two rounds. I'll send round 2 Thursday. After that, additional rounds are €450 each per the onboarding doc." And she says fine, because she already saw that line on day one.

Step 6 — Money in one place

Every project has the same five money questions. Answer them all in one short block, once.

Money

• Total: €14,000 (signed in proposal).
• Schedule: 50% deposit now (€7,000), 50% on final delivery (€7,000).
• Send invoices to: [email protected] (Anna's CC: [email protected]).
• Payment terms: Net 14 from invoice date. Late fee 2% per started week after 30 days.
• What changes the bill: extra revision rounds (€450 each), new pages or sections not in the original scope (priced before work starts), urgent work outside business hours (1.5× rate, with your written approval first).

Let's say in week four the client says "could you also do an FAQ page?" — a clean, friendly scope-creep request. You reply "happy to. Per the onboarding doc, that's a new page — I'll send a quick mini-quote, takes 5 minutes." You're not making the rule up under pressure. The rule was there on day one.

Step 7 — What happens if something breaks

This is the one most freelancers skip. It's also the one that matters most when something goes wrong. Write the three or four "what if" cases that could realistically happen, and the answer to each.

If something goes sideways

• You get sick or busy for more than a week: tell me as soon as you know. The timeline shifts by the lost time. No penalty.
• I get sick: I'll tell you within a day. I'll either push the timeline by the lost days or, for anything over a week, refund the unworked portion. Your call.
• You want to pause: the project pauses, the work to date is invoiced, and we restart with a new timeline (subject to my availability).
• You want to stop entirely: the kill fee is 30% of the remaining balance, billed within 7 days. You keep all work delivered to that point.

Let's say in week five the client's funding round gets pushed and they ask to pause for two months. Without this line, you have an awkward call where neither of you knows what's fair. With this line, you pause the project, send an invoice for work to date, and book the time for someone else. No drama.

A worked example — what a real day-one doc looks like in one sitting

Here's how Anna's project looks once all seven sections are pasted into one document, sent through DocsAura, and shared as a single link the same hour the deposit clears.

Project: Acme.com redesign — homepage, pricing, case study template.

1. People: Anna (approver), Dominik (you, designer), Tom (their dev). 2. Channel: Slack #acme-redesign for day-to-day, email for scope/invoices, Tuesday 14:00 call. 3. Deliverable: three pages in Figma + final HTML/CSS, ready by July 12. 4. Dates: May 22, May 27, June 5, June 19, July 12. 5. Approval: two revision rounds included, €450 each after that, Anna approves. 6. Money: €14k total, 50/50 split, [email protected], Net 14, late fee 2%/week after 30 days. 7. If broken: standard pause/kill clauses, mutual sick-leave rules.

Anna opens the link on her phone Friday afternoon. She reads it in three minutes. She replies "this is great, makes everything clear." Week one goes by with zero "where do I…" pings. Week two she has one question; she finds the answer in the doc before sending. By week four, she's referenced the doc twice when her own teammates ask her things.

That's the whole game. One link, sent once, that holds.

What to avoid

A few easy ways to undercut your own onboarding doc.

Burying it in a Notion workspace with eleven sub-pages. If they can't find the answer in 30 seconds, the doc may as well not exist. One page. One link. Scannable on a phone.

Writing it in lawyer-speak. This is not the contract. The contract is the contract. This is a short, friendly map of how the project actually runs. "Send invoices to [email protected]" beats "Invoicing shall be directed to the accounts payable address as designated" every time.

Forgetting to update it mid-project. If the timeline shifts in week three, update the doc the same day and send a one-line note: "Updated the onboarding doc — new delivery date is July 19, everything else the same." A stale doc is worse than no doc.

Not sending it on day one. Sending it in week two is half as useful. Sending it in week four is just documentation. The whole point is that it lands before the first question gets asked.

This works because most week-one chaos is the same five or six questions, asked in different order, by clients who are not deliberately being difficult — they just don't remember what was in a 12-page proposal they read three weeks ago. Answer the questions once, in one place, on day one.