A kickoff meeting template that stops the scope argument in month three

A kickoff is two documents in one

Most kickoff templates only do the agenda half. You get a neat list of topics, the meeting happens, everybody leaves feeling aligned, and the only thing written down is a slide deck nobody opens again. Three months later two people remember the scope differently, and there is no document to check.

The fix is small. Every heading in this template is a question with a blank under it. You fill the blanks live, on the screen, while people watch. If a blank is still empty when the meeting ends, that is not a failure, it is your first risk, and you write it down as one with a name and a date next to it.

One more rule that costs nothing. Whoever facilitates does not write. Facilitating a kickoff and taking a full record at the same time is how half the detail gets lost. Name a scribe, or record the meeting and write it up after.

The agenda side of this overlaps with a plain meeting agenda template, and the record side overlaps with meeting minutes. A kickoff is the one meeting where you genuinely need both in the same file.

The project kickoff meeting template

Copy this section as it is. Square brackets mark what you replace. Keep the field names unchanged, because using the same names on every project is what makes an old kickoff file readable a year later.

Header block. One field per line, at the top of the page.

1. 1Why this project exists (10 minutes). [Two to four sentences. The problem in the words of the people who have it, with a number attached if one exists. Not the solution. If you cannot write this without naming a tool, you are describing a plan, not a reason.]
2. 2What done looks like (10 minutes). [Two or three measures, each with a starting number and a target number. "Manager time spent on X falls from A to B by DATE." Vague success criteria are the single biggest cause of a project that will not end.]
3. 3Scope in (10 minutes). [A list of things this project will deliver. Each line short enough to fit on one line.]
4. 4Scope out (10 minutes). [A list of things this project will not deliver, and where each one goes instead. This is the most valuable section on the page. Details below.]
5. 5Roles and decision rights (10 minutes). [Who decides, who does the work, who only needs to be told. One name per row, never a team name.]
6. 6Milestones and dates (10 minutes). [Five to eight milestones. Each one has a sentence saying what is true when it is done, a date, and one owner.]
7. 7Risks and assumptions (10 minutes). [Each risk gets four parts: what could go wrong, what it costs if it does, what you will do about it, and who is watching it. Assumptions get the same treatment, because an assumption is just a risk you have decided to accept.]
8. 8Communication plan (5 minutes). [Which meeting recurs and how often, where written updates go, where files live, how urgent problems get raised outside the normal rhythm, and how long people have to review something before silence counts as approval.]
9. 9Decisions log opened (5 minutes). [Write down every decision made in this meeting, numbered, dated, with the name of who decided. The log starts today, not at the first problem.]
10. 10Open questions and first actions (10 minutes). [Everything nobody could answer today, each one with an owner and a date. Then the actions for the first two weeks, in the same format.]

• Project: [Short name people will actually say out loud]
• Project code: [Optional, if your finance or ticketing system needs one]
• Kickoff date and time: [Tuesday 17 March 2026, 10:00 to 11:20]
• Location: [Room, or the call link, or both if it is a mixed meeting]
• Facilitator: [Name, role]
• Scribe: [Name, role. Never the same person as the facilitator]
• Sponsor: [The one person who can approve money and settle a scope fight]
• Attendees: [Names and roles. Mark who joined remotely]
• Could not attend: [Names, plus who briefs each of them and by when]
• Document status: [Draft, circulated DATE] or [Agreed on DATE by SPONSOR]

Scope out is the section that saves you in month three

Almost every kickoff template has a scope section. Almost none of them force you to write the other half. That omission is where late projects come from.

Here is the pattern. In month three somebody asks for a thing they always assumed was included. Nobody wrote down that it was not. There is no document that says no, so the argument becomes about who is being unreasonable rather than about what was agreed. You lose two weeks and some goodwill, and the thing usually gets built anyway.

A written scope out list ends that in one minute. It is not a rejection list. Each line says where the item actually goes: a later phase, a different team, a separate budget, or a decision that has not been made yet. Write it in the meeting, out loud, so people can argue with it while it is still cheap to change.

The uncomfortable moment is the point. If someone objects when you read the scope out list, you have found a real disagreement on day one instead of in month three. That is the best thing a kickoff can do.

What people get wrong: they write scope out in vague language. "Advanced reporting is out of scope" invites a fight about what counts as advanced. Name the actual thing. "No custom report builder. Six fixed reports, listed in the requirements doc."

Roles: who decides, who does, who is informed

Three questions, and only three. Who can settle a disagreement. Who is doing the actual work. Who just needs to be told and has no vote.

What people get wrong: two names in the decision row. Two owners means no owner. When two people can both approve something, the project stalls the first time they disagree, and neither of them thinks it is their job to break the tie. Pick one name, write it down, and let the other person be consulted instead.

The second common mistake is a team name where a person should be. "Marketing will review the copy" is not a role, it is a hope. "Nadia reviews the copy within three working days" is a role.

Milestones: dates with a definition of done attached

A milestone with only a date is a wish. A milestone with a sentence saying what is true when it is finished is a checkpoint you can actually pass or fail.

Five to eight is the right number for most projects. Fewer and you find out too late. More and the list becomes a task tracker, which is a different document.

What people get wrong: milestones that describe activity instead of a result. "Testing" is activity. "All 22 branches loaded and two managers have built a rota without help" is a result. Only the second one can be checked by somebody who was not there.

Put a real date on every row, even a bad one. A date you are unsure about is a risk you can write down. A blank date is a problem you will not see coming.

Risks, assumptions and the communication plan

An assumption is a risk you have decided to accept without saying so. Writing them in the same list is honest and takes no extra time.

Give every entry four parts. Skip any part and the entry becomes decoration.

• What could go wrong: [One sentence, specific. Not "resourcing". "[Name] is committed to another project until [date], so we have [number] fewer engineering weeks than the plan assumes."]
• What it costs: [The consequence in time, money or scope. "Pilot slips two weeks" beats "delay to the project".]
• What we will do about it: [Either a mitigation you start now, or an explicit decision to accept it. Both are fine. Silence is not.]
• Who is watching it: [One name, and when they next report on it.]
• Assumptions, same four parts: ["We assume HR provides the staff list by DATE." What happens if they do not, what we will do, who checks.]
• Communication plan: [Recurring meeting and how often. Where the written update goes and on which day. Where files live. How someone raises an urgent problem between updates. How many working days a review takes before silence counts as approval.]

The decisions log, opened on day one

Most teams start a decisions log in month four, when they realise nobody can remember why the database was chosen. By then the reasoning is gone and only the outcome is left, so the decision gets reopened and argued again from scratch.

Start it at the kickoff. You will make four or five real decisions in that meeting, and they are the ones people will question later. Number them, date them, and always record the reason. The reason is worth more than the decision, because it is what tells you whether the decision still holds when the situation changes.

Keep the log in the same file as the kickoff notes, or in one shared document that never moves. A decisions log split across three tools is a decisions log nobody reads.

A worked example: a real kickoff, written up

A made-up but realistic project, so you can see how much detail is enough. Brightside Bakery runs 22 branches and builds every staff rota in a spreadsheet. The project moves them onto a scheduling tool.

Project: Rota replacement, phase one. Kickoff: Tuesday 17 March 2026, 10:00 to 11:20, Meeting Room 2 and Google Meet. Facilitator: Marco Silva, project lead. Scribe: recorded, written up by Marco the same afternoon. Sponsor: Dana Whitfield, Operations Director. Attendees: Dana Whitfield, Marco Silva, Priya Raman (lead engineer), Tomas Berg (payroll), Aisha Noor (store manager, Camden). Could not attend: Lena Fischer, finance. Marco to brief her by 19 March. Budget: $46,000, approved.

Why this project exists. Branch managers spend around six hours a week building and fixing rotas in a spreadsheet. Payroll gets roughly 30 corrections a month because the spreadsheet and the timesheets disagree. Two managers left last year and both mentioned rota admin in their exit conversation.

What done looks like. Manager time on rota building drops from about six hours a week to under two, measured by a survey of all 22 managers in July. Payroll corrections drop from around 30 a month to fewer than five, measured by Tomas from the August payroll run. Every branch is on the new tool with the spreadsheet retired by 26 June 2026.

Scope in. Rota building for all 22 branches. Shift swaps between staff at the same branch, with manager approval. Weekly CSV export for payroll. Manager training, one session per region. Twelve months of historical rota data loaded.

Scope out, and this is the list Marco read out loud. No staff mobile app in phase one, staff see rotas by email and on the branch noticeboard, provisional phase two in Q4. No direct payroll system integration, CSV export only, because the payroll vendor contract ends in November and anything built now gets thrown away. No rota data older than twelve months, the older files stay in the shared drive. No cross-branch shift swaps, that needs a policy decision from Dana that has not been made, decision due 15 May. No Arabic interface for the two franchise branches until phase two, Aisha to tell those managers before 24 March.

Roles. Dana decides, including any date slipping. Marco runs it day to day and keeps the decisions log. Priya does the configuration and the data load, four days a week from 3 April. Tomas answers payroll questions and signs off the CSV format, two hours a week. Aisha signs off anything that changes the shift swap rules and runs the pilot training. Lena gets the weekly update and has no approval role.

Milestones. Requirements signed off by Dana, one page per branch type, 27 March. Sandbox configured with two branches loaded, 17 April. Pilot live at Camden and Leeds Central with the spreadsheet retired at both, 12 May. Pilot review and go / no-go by Dana, 5 June. All 22 branches live, 26 June. Handover to operations and project closed, 10 July.

Risks and assumptions. Priya is committed to another project until 3 April, so the plan has four fewer engineering weeks than it looks like, and the mitigation is that discovery and requirements move first. Marco reports on this on 3 April. We assume HR provides current staff lists for all 22 branches by 24 March, and if they do not the pilot slips a week, Marco checking weekly. The real risk is managers quietly keeping the spreadsheet, so the spreadsheet is deleted at both pilot branches on 12 May and Aisha runs the training herself rather than sending a document. Aisha reports at the 5 June review.

Communication plan. Thirty minute check-in every Tuesday at 09:30. Written update from Marco every Friday to Dana, Tomas, Aisha and Lena. Files in the shared drive under Rota Replacement. Anything that puts a milestone at risk goes to Dana the same day, by phone, not by email. Reviews get three working days, after which silence counts as approval.

Three variants: internal, client, and agency onboarding

The skeleton stays the same. What changes is which sections get more weight and which extra fields you add.

Variant 1: internal project. The people doing the work report to someone else, so the section that matters most is availability. Add a line per person that says how many hours a week their manager has actually agreed to, and put that manager's name next to it. "Priya, four days a week from 3 April, agreed with Sam Okafor on 12 March" is a commitment. "Priya is on the project" is not. Also add a what this project displaces line, because borrowed people are always already busy, and naming what slips is more honest than pretending nothing does. Keep the commercial fields out. Nobody is invoicing anyone.

Variant 2: client project. Add a commercial block under the header: contract or statement of work reference, the agreed fee and payment schedule, and the change request process in one sentence with a price attached. The scope out list stops being helpful and becomes contractual, so write it in the same words as the statement of work, and read it out loud in the meeting. Add a named client-side approver with a turnaround time, because client review time is the most common cause of slippage and the only fix is to agree in the kickoff how many working days a review takes and what happens when it takes longer. Add an assumptions block that is really a list of client dependencies: content, access, data, sign-off. Each one gets a date and a consequence.

Variant 3: agency onboarding. This is a kickoff plus an access checklist plus a first read on how the client works. Add a section for accounts and assets: logins, analytics access, brand files, ad account permissions, who grants each one and by when, because a project that waits three weeks for an analytics invite has already lost three weeks. Add a who approves what list for creative work, and ask directly who else looks at it before it goes out, since the person nobody mentioned in the kickoff is usually the person who rejects the first draft. Ask which language the deliverables and the record should be in. If the client's own team works in one language and talks to you in another, agree in the first meeting which one the written record uses, and get both if you need them. That is a real problem for bilingual teams, and it is worth reading how transcription handles a meeting held in two languages before you promise anything.

Getting the kickoff written up without a scribe

Kickoffs are long and dense. Ninety minutes, eight people, and roughly forty things worth writing down. If you are facilitating, you cannot capture that and still run the room. If you hand the job to the newest person, you get a record that misses the reasons behind the decisions, which is the part that mattered.

The practical alternative is to record the meeting and write it up from the recording. Noter AI records an in-person kickoff from a phone on the table, one tap, screen locked, and sends a bot into Zoom, Google Meet, Microsoft Teams or Webex for the remote version. Its Formal report output style turns the recording into a structured document with headings, and Minutes of meeting gives you the shorter agenda-item-by-agenda-item shape if that fits your organisation better. Action items come out as their own list with owners attached, which is most of your first-two-weeks plan already written.

Two things make it useful specifically for a kickoff. Speaker labels and timestamps mean the decisions log entry can name who decided, and you can tap a line to hear that exact moment again when someone questions it in June. And the transcript is editable, so you fix the product names and people's names the model got wrong, then re-run the summary so the corrected spelling flows into the document you circulate.

Months later, when someone asks why payroll integration was left out, AI chat searches across every note at once, not just the one you remember. That is the question a decisions log is supposed to answer, and the recording is the backstop when the log is thin.

For a bilingual kickoff, and agency onboarding calls often are, transcription covers 60+ languages with automatic detection and tags language word by word, so a scope point made in Arabic with the deliverable named in English is captured accurately on both counts. Tools that make you pick one language before recording will transliterate the second one phonetically, which turns your record into guesswork. The finished notes can then be translated into 18 languages, so the client reads the record in theirs and your team reads it in yours.

On price it is $9.99 a month or $49.99 a year, flat, not per seat. Project work is the case where seat licences age badly, because a project team is not a fixed list. You kick off with five, a contractor joins for the build phase, an agency lead sits in for three sessions, and someone rolls off at the end of the quarter. Every one of those movements is a seat change on a per-user tool and no change at all here. If the kickoff is the only meeting you ever record, the annual plan is $49.99 against the cost of getting the scope wrong once. Test it on one real kickoff. For the mechanics of capture, how to record an in-person meeting covers the setup, and getting action items out automatically covers the follow-through.