The Client Welcome Packet: 10 Sections, With the Actual Copy

Before writing this we fetched every page ranking on the first page for "client welcome packet" in July 2026 and read all of them end to end. Here is the finding that shaped this article:

Across the five ranking pages, we counted zero sentences of usable packet copy. Not one of them contains a single line you could paste into your own document. They describe sections. They name headings. Three of the five sell you a Canva template at the bottom, one sells a CRM subscription, and one sells an onboarding portal.

The entire first page of Google for this query is a list of things to write, written by people who will not write them for you.

So this article writes them. Every section below has the heading, the reason it exists, and the actual language, in a plain voice you can adapt in about ten minutes. It is ungated: no email capture, no download, no trial. The copy is in the page.

What a client welcome packet actually is (and what it is not)#

A client welcome packet is a short, client-facing document, usually two to four pages, that translates your signed contract into plain English and tells the client what to do next.

It is not the contract. It is not your onboarding process. Those get confused constantly, and the confusion is why so many packets are bloated and useless.

Your onboarding sequence is internal. It is the five documents and the order you send them in, which we cover in client onboarding for a team of one. The client never sees that machinery.

The welcome packet is the one artifact from that sequence that the client actually reads. Its whole job is to prevent the questions and the delays that will otherwise land in your inbox over the next six weeks.

Here is the distinction that most pages blur:

The packet sits between the contract and the work. It is the document the client opens on week three when they cannot remember how many revisions they get.

The evidence: why the packet pays for itself#

PMI's 2018 Pulse of the Profession found that [52% of projects experienced scope creep](https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf), up from 43% five years earlier, and those are projects run by professional project managers with a change control process.

You are a business of one negotiating alone, mid-project, with the person who pays you. Your odds are worse than theirs.

The same body of research puts a number on the communication half. PMI's 2013 study on the role of communications found that 56% of dollars spent on projects are at risk due to ineffective communications, and that highly effective communicators were more than five times as likely to be in high-performing organizations (38% versus 7%). That study is old, and we are flagging its age rather than dressing it up as current, but the finding has not been contradicted since.

On the payment side, a 2022 Freelancers Union and Authors Guild survey of New York freelancers found 91% had experienced late or overdue payment at least once, 54% had waited three months or longer, and 76% spent one to two hours a week chasing payment. That survey covers New York only and was fielded as advocacy for the Freelance Isn't Free Act, so treat it as directional rather than national.

One more thing worth saying out loud, because this niche is full of it.

Several pages in this space cite completion-rate figures for welcome packets ("PDFs are fully read about 15% of the time," "interactive portals get 75% completion in 48 hours") with no source attached. We tried to trace them and found nothing. There is no published study measuring client welcome packet completion rates by format. Anyone quoting one to you is quoting a number someone invented.

The 10 sections, with the copy#

Use square brackets for the parts you swap per client. Everything outside brackets can stay as written.

1. The welcome, and the reassurance#

The client just spent money. There is a well-documented moment right after a purchase where people look for evidence they chose correctly. Your first paragraph is that evidence.

Keep it to three sentences. Do not write a founder's story.

Welcome, [Client name].

Thanks for trusting me with [project]. Everything you need for the next [8 weeks] is in this guide: what happens when, what I need from you, and how to reach me. It should take about five minutes to read, and it is worth reading once now rather than three emails later.

2. What you are getting#

Restate the deliverables in the client's words, not your internal task names. If your scope of work says "IA audit and wireframe set," the packet says what that produces for them.

What I am delivering

- [A 14-page website design, desktop and mobile, delivered as Figma files plus a shared prototype link]

- [Up to 2 rounds of revisions on each page, as defined below]

- [A 30-minute handover call and a written handover doc]

What is not included in this project

- [Copywriting. I will design around placeholder text unless you supply final copy by week 3.]

- [Development and launch. Quoted separately if you want it.]

- [SEO, hosting, ongoing maintenance.]

That second list is the single highest-value block in the packet. Most disputes are not about what you promised. They are about what the client assumed came along with it.

3. The timeline, with their dates in it#

A timeline that only lists your delivery dates is a timeline the client cannot miss a deadline on, which means every slip becomes your fault.

Put their obligations in the same table as yours.

Schedule

| Week | I deliver | You do | By |

|---|---|---|---|

| 1 | Kickoff call, project brief | Send brand assets and logins | [Mar 6] |

| 2 | Wireframes | Consolidated feedback | [Mar 13] |

| 4 | First design concepts | Consolidated feedback | [Mar 27] |

| 6 | Revised designs | Written approval | [Apr 10] |

| 7 | Final files and handover call | Final invoice payment | [Apr 17] |

Dates assume feedback arrives within the windows below. If it does not, the schedule moves, as described in section 5.

4. The four words that cause disputes, defined#

This is the section no page on the SERP has, and it is the one that does the most work: define "revision," "round," "approval," and "final" before the project starts.

Every argument you will have about scope is really an argument about one of these four words. Both parties are using them honestly and meaning different things.

What these words mean here

A round is one batch of feedback from you, sent in one message, after everyone on your side has weighed in. Feedback that arrives in five separate emails over four days is still one round, but I will start work when the last one lands, so it costs you time.

A revision is a change within the direction we already agreed. Changing the button colour, rewriting a headline, resizing a section: revisions. Asking for a different layout, a new visual direction, or a page we never scoped: that is new work, not a revision, and I will quote it as a change order before starting.

Approved means you have replied in writing with the word "approved" for a specific deliverable. Silence is not approval. Enthusiasm on a call is not approval. I will always ask for it explicitly.

Final means approved and paid. Final files are released after the closing invoice clears.

If you want the reasoning behind revision limits and how many to offer, we cover the numbers in how many revision rounds to put in your contract.

5. Communication, both directions, with consequences#

Every welcome packet on the internet tells the client your office hours. Almost none of them state what happens when the client misses a window.

That asymmetry is the reason your projects run long. You are on a clock. They are not.

How we work together

My response times. Email and [Slack] on weekdays, [9am to 5pm ET]. I reply within [one business day]. If something is urgent, put URGENT in the subject line and I will treat it that way.

Your response windows. Feedback and approvals within [5 business days] of delivery.

What happens if a window is missed. I am not going to charge you for being busy, but I do have to protect the schedule for my other clients, so:

| Feedback arrives | Effect on the schedule |

|---|---|

| Within 5 business days | No change, we stay on the dates above |

| 6 to 15 business days | Delivery date moves by the number of business days elapsed past day 5 |

| More than 15 business days | Project pauses, and restarting depends on my availability, with a [$250] reactivation fee if I have to reschedule other work |

| More than 60 days | Project closes, work delivered to date is invoiced in full, restarting is a new engagement |

Worked example: designs go out [Mar 27], feedback is due [Apr 3], and it arrives [Apr 10]. That is 5 business days past the window, so the [Apr 10] delivery becomes [Apr 17] and everything after it moves by 5 business days too.

Check that arithmetic against your own calendar before you send it. In the example above, Mar 27 plus 5 business days is Apr 3, Apr 10 is 5 business days after that, and the two subsequent milestones shift by the same 5 days.

The pause threshold matters more than the shift. A project that sits at 90% done for four months is worse for you than one that ends, because it occupies a slot in your head and blocks the calendar without producing revenue. If you want the language for restarting stalled work, see scope creep scripts.

6. Who decides#

Decision makers

Final sign-off on this project: [Name, title, email].

If other people need to see the work, that is fine, but please gather their comments and send them as one consolidated response. I will act on feedback from [Name] only.

If the approver changes during the project, tell me. A new decision maker who has not seen this guide usually means a new round of opinions, and I would rather send them the guide than rediscover it in week 6.

That last paragraph exists because the mid-project stakeholder swap is one of the most reliable ways a scoped project turns into an unscoped one, and no competing article mentions it.

7. Money, in numbers#

Vague payment language in a friendly document undermines specific payment language in a contract. Repeat the numbers exactly.

Payments

- Total: [$6,400]

- [$3,200] deposit, paid, which is what reserved your slot

- [$3,200] due on final delivery, [Net 14]

- Invoices arrive by email with a card and bank transfer link. No account or login required.

- Late payments accrue [1.5% per month] after the due date, per section [7] of our agreement.

- Additional work outside the scope above is quoted in writing and approved by you before it starts. Nothing gets added to your invoice as a surprise.

"Net 14" means the client owes you within 14 days of the invoice date, and a surprising number of clients do not know that. Spell it out if your client is not a company with an accounts payable department. Our guide to freelance payment terms covers which terms to pick, and late fees covers what you can actually enforce.

8. Tools and access#

Where things live

- Files and deliverables: [link]

- Feedback and comments: [link], not email, so nothing gets lost in a thread

- Invoices and contract: [link]

- Calls: [link], booked here

What I need from you in week 1

1. [Brand assets: logo files, fonts, colour codes]

2. [Admin access to your site, sent through this link, not by email]

3. [Any existing analytics or research you want me to read]

Send them one at a time as you find them. I would rather have the logo today than a complete folder in two weeks.

Ask for one item at a time with the format, the destination, and the reason. A single bullet reading "please send all brand assets and access" gets deferred; a specific request with a reason gets done.

9. The FAQs you actually get asked#

Write these from your inbox, not from a list on a blog. Go through the last five projects, find the questions clients asked twice, and answer those.

Typical set:

Can I call you? Yes, book a slot at [link]. For anything under five minutes, email is faster for both of us.

What if I want something we did not scope? Tell me. I will quote it and you can decide. It is never a problem, it is just not free.

What if I hate the first concepts? That is what round one is for, and it happens. Tell me specifically what is not working (this typeface feels corporate, this layout buries the pricing) rather than "I do not love it," and round two will land.

Who owns the work? You do, on final payment, as set out in section [9] of the agreement. I keep the right to show it in my portfolio unless we agreed otherwise.

What if I need to cancel? Tell me as early as you can. Work completed to date is invoiced, and the deposit is not refundable, per section [5].

10. The precedence line#

Here is the liability that every ranking page walks straight past: a plain-English summary that contradicts your signed contract can be read against you, so the packet needs one sentence saying the contract wins.

You have just spent four pages simplifying legal terms. Simplification loses detail. If your packet says "2 rounds of revisions" and your contract says "2 rounds per deliverable," a dispute now has two documents pointing different directions.

Put this at the end, in small text:

This guide summarises our agreement in plain language for convenience. It is not a contract and does not change one. Where this guide and the signed agreement dated [date] differ, the signed agreement governs.

Then do the thing nobody tells you to do: whenever you change your contract template, re-read the packet the same day. They drift apart quietly, one edit at a time. For what belongs in the contract itself, see what should be in a freelance contract.

What to cut if you are solo#

The consensus packet on the SERP is built for a small agency. Three of the five ranking pages tell you to introduce your team and include a mission statement.

You do not have a team. Cut these:

A solo packet lands at two to four pages. If yours is running to fifteen, you are writing a brochure.

PDF, doc, or portal#

There is no published data on which format clients actually read, despite what some pages in this niche claim, so choose on maintenance cost instead.

The PDF's real failure mode is not that nobody reads it. It is version drift: you change your revision policy in month four and three clients are still holding a PDF that says the old thing.

A page the client logs into cannot go stale. That is the argument for keeping the packet where the work lives, which is what a client portal is for.

That is also the part Raoura is built around: the welcome content, the milestones, the files, the contract, and the invoices sit on one branded page the client opens, so when you change your response-window policy it changes everywhere at once. Disclosure: Raoura is our product, it is $17 a month flat, and every section of copy in this article works perfectly well in a free Google Doc. The doc just will not stay in sync with your invoices.

!A Raoura client portal home page showing the project, files, contract, and invoice in one branded view for the client

The packet as a page rather than an attachment: the client opens one link and sees what they agreed to, what is due, and what you need from them.

!A Raoura project view inside the client portal showing milestones, deliverables, and the current status of each stage

The timeline table from section 3, kept live. When feedback slips and dates move, the client sees the new dates instead of arguing from a PDF you sent in week one.

When to send it, and what to do after#

Send the packet immediately after the contract is signed and the deposit is paid, in the same email as the receipt. Not before signature: a packet full of policies during the sales conversation reads as defensive.

Then:

1. Reference it, do not repeat it. When a client asks a question the packet answers, reply with the answer plus "this is in the guide under Communication" so they learn the guide is real.
2. Re-send it on scope change. Any change order that moves dates or deliverables means an updated packet, with a one-line note on what changed.
3. Re-send it when the approver changes. New decision maker, new copy of the guide, same day.
4. Measure four things across your next five projects: days from kickoff to receiving the last asset you asked for, revision rounds per deliverable, number of "just checking in" emails from the client, and days from delivery to written approval. If the packet is working, all four fall. Nobody in this niche measures anything, so your own numbers will be better than any statistic you can find.

Verified July 2026. Statistics were checked against primary sources this month: PMI Pulse of the Profession 2018 (n=5,402, 52% scope creep), PMI Essential Role of Communications 2013 (56% of project dollars at risk), and the Freelancers Union and Authors Guild New York freelancer survey, May 2022 (91% experienced late payment, 54% waited 3+ months, New York respondents only, sample size unpublished). The SERP finding that no ranking page contains usable packet copy is our own, from fetching all five first-page results in July 2026. Widely repeated welcome-packet completion figures, including "PDFs are read 15% of the time" and "portals reach 75% completion in 48 hours," could not be traced to any published study and are deliberately not used here.