The kickoff email is the document everyone returns to three months later when two people remember the scope differently. It is written at the point of maximum goodwill and minimum information, which is exactly why it tends to be vague. Most kickoff emails introduce the team, express enthusiasm and attach a timeline, then leave unanswered the questions that later cause the trouble: who decides, what counts as finished, and what happens when something changes. This guide covers what belongs in the message and why each part earns its place.
Decide Who Is Actually on the Email
The recipient list is a design decision, not an administrative one. Everyone on it will assume they have standing to comment, and everyone left off will hear about the project secondhand.
Include the people who do the work, the person who signs off, and the person who holds the budget if that is someone different. Include the client-side contact who will answer day-to-day questions. Where a stakeholder needs visibility but not involvement, say so in the email itself rather than relying on the cc field to communicate it: “Copying Helen for visibility; Ravi is our day-to-day contact for approvals.”
Be cautious about large distribution lists at kickoff. A message to fourteen people generates either fourteen opinions on the scope or, more commonly, none at all, because each reader assumes someone else is responding.
State the Scope in Terms of Deliverables
Scope written as activity is unenforceable. “We will support your content strategy” cannot be finished, disputed or invoiced against. Scope written as deliverables can be.
List what will exist at the end: a document, a working feature, a set of designs, a migrated database, a trained team. Give each one a rough date. Then, and this matters more than the list itself, state what is not included. Exclusions feel awkward to write at kickoff and save weeks of argument later.
A usable formulation: “In scope: the new booking flow, the confirmation emails, and the admin view for cancellations. Not in scope for this phase: the loyalty points system and the mobile app, which we have agreed to look at separately.”
Define What Success Looks Like Before Work Starts
Deliverables tell you when the work stops. Success criteria tell you whether it was worth doing, and they are the part most often skipped because they are harder to write.
Ask what has to be true at the end for the client to consider the project a success, and record the answer in their words. It may be a measurable outcome, but it is just as often a qualitative condition: that the finance team can produce the monthly report without engineering help, that the site can be updated by a non-technical editor, that a process currently taking three people takes one.
Writing this down at kickoff protects both sides. It prevents scope creep dressed as clarification, and it prevents a technically complete delivery that nobody is happy with.
Name the Decision Maker Explicitly
The most expensive ambiguity in any project is who gets to say yes. Where approval is diffuse, work stalls in review or, worse, proceeds on the strength of an opinion from someone who turns out not to have had the authority to give it.
Put the name in the email: “Ravi has final approval on design and copy. For anything that changes the budget or the delivery date, we will need Helen’s sign-off as well.”
If the client cannot tell you who decides, that is itself a significant finding and worth surfacing immediately rather than discovering at the first review.
Set the Communication Cadence
Cadence prevents both silence and constant interruption. Agree it in writing at the start, and specify the channel for each type of message rather than leaving it to habit.
| Communication type | Channel | Frequency | Expected response |
|---|---|---|---|
| Status update | Email, from us | Weekly, fixed day | None required |
| Working questions | Shared chat channel | As needed | Same working day |
| Decisions and approvals | Email, written record | As needed | Two working days |
| Review meeting | Video call | At each milestone | Attendance by decision maker |
| Urgent blockers | Phone, then email summary | Rare | Immediate |
| Scope or budget change | Email to budget holder | Rare | Written agreement |
The distinction between the chat channel and email is the useful part. Quick questions in chat keep momentum, but anything that changes scope, cost or date belongs in email, where it can be found later. Say this explicitly, because otherwise a significant approval will end up buried in a chat thread nobody can search.
Say Where Files Live and Who Can Reach Them
A surprising amount of project friction is simply people not being able to find things. Name one location for each category of material and state it plainly: where drafts live, where approved final versions live, where credentials are shared, and where the project plan sits.
Two practical points are worth including. First, confirm that everyone on the project has access before work starts, rather than discovering on review day that the approver cannot open the folder. Second, say how versions are named. Even a crude convention beats a folder containing three files called final.
Explain What Happens When Something Changes
Every project changes. The kickoff email should say how a change will be handled, in one short paragraph, while nobody is under pressure and the conversation is still theoretical.
A serviceable version: “If a request falls outside the scope above, we will send a short note setting out the impact on cost and timeline before we start work on it. Nothing outside scope proceeds without written agreement from Helen.”
This single paragraph does more to prevent difficult conversations than any other part of the message. It converts an argument about whether something was in scope into a routine process that both sides agreed to in advance.
Close With Actions and Owners
End with a short list of what happens next, each item with a name and a date. Not “we will schedule a workshop” but “Priya to send three dates for the discovery workshop by Thursday.”
Keep it to three or four items. A kickoff email that ends with eleven actions has moved from setting direction to managing tasks, and the actions will be lost in the prose.
One Practical Takeaway
Write the kickoff email as though you will be reading it back in a disagreement six months from now, because you probably will. If it names the decision maker, states what is out of scope, and describes how changes are handled, it will do its job long after the enthusiasm of the first week has worn off.
Frequently Asked Questions
Who should be on a project kickoff email?
The people doing the work, the person who signs off, the budget holder if that is someone else, and the day-to-day contact who answers questions. Where someone needs visibility without involvement, say so in the body rather than expecting the cc field to convey it. Keep the list tight: a kickoff sent to a dozen people tends to produce either a dozen competing opinions on scope or complete silence, because every reader assumes another one is responding.
How do I write project scope so it prevents disputes later?
Write it as deliverables rather than activity. A promise to support, advise or improve something cannot be finished or disputed, whereas a document, a working feature or a migrated database can. Give each deliverable a rough date. Then list what is deliberately excluded from this phase, which is the part people skip because it feels awkward at kickoff. Those exclusions are what you refer back to when a reasonable-sounding request arrives three months in.
Why does the kickoff email need to name a decision maker?
Because ambiguous authority is the most expensive problem a project can have. Without a named approver, work either stalls in review while everyone waits for someone else, or proceeds on an opinion from a person who turns out not to have had the authority to give it. State who approves what, and note separately who must agree to anything affecting budget or timeline. If the client cannot name the decision maker, that is worth raising straight away rather than at the first review.
How should the kickoff email handle changes to the project?
Describe the process in one short paragraph while the discussion is still theoretical and nobody is under pressure. Say that any request falling outside the agreed scope will be answered with a brief note setting out the effect on cost and timeline, and that nothing outside scope starts without written agreement from the budget holder. Agreeing this at the start converts a later argument about whether something was in scope into a routine step both sides already accepted.