# How to Run a Shopify Project Kickoff Meeting (With Agenda)

> A project kickoff meeting agenda for Shopify agencies: what must exist before the meeting, who attends, what to cover, and what to send after.

_Published: 2026-10-23 · CommerceCopilot_

## What a kickoff meeting is for, and what it is not

A Shopify project kickoff meeting has one job: get everyone who will touch the project, on both sides, working from the same picture of what is being built, how decisions get made, and what happens next. It is not the place to gather requirements or renegotiate the quote. By the time the kickoff happens, discovery has produced the requirements and scoping has produced the price. A good project kickoff meeting agenda transmits that context to the people who were not in the room when it was created, and sets the working rules for the weeks where the actual money gets made or lost.

Most agencies treat the kickoff as a ceremony: a deck, introductions, a restatement of the proposal, and a warm goodbye. Three weeks later the client is surprised that the subscription widget is phase two, the developer is building against an assumption the client never confirmed, and change requests arrive through four different channels. That is not a kickoff failure exactly. It is a failure to use the kickoff for the things only a kickoff can do.

## What has to exist before the kickoff

A kickoff cannot create context. It can only transmit context that already exists, which means the inputs matter more than the slides.

Before you put the meeting on anyone's calendar, three things should be true. First, the internal handoff from sales to delivery has already happened: the delivery team has read the scope, the decision log, and the assumptions, and had the chance to interrogate the person who scoped the project. If that has not happened, run the [handoff process](/blog/shopify-agency-handoff-process) first: a kickoff where the delivery team hears the project for the first time in front of the client is an improv exercise, not a meeting.

Second, discovery produced a record, not just a quote. The outcome the client wants, the constraints, and the open questions should exist in writing, with each item marked as confirmed by the client or assumed by your team. If your [discovery process](/blog/shopify-agency-client-discovery-process) produced a living brief, assembling the kickoff material takes an hour. If it produced a folder of call notes, the kickoff preparation is where you pay that debt.

Third, the first stretch of work exists as sequenced tickets, or is close to it. You do not need the full backlog groomed, but "what happens in week one" should be specific enough that the kickoff can end with real next actions instead of "we'll get started."

## A project kickoff meeting agenda that sets up delivery

This agenda fits in 60 minutes for a typical scoped Shopify build. The time boxes are the point: every item here has a failure mode where it quietly eats the meeting.

### 1. Roles and decision rights (5 minutes)

Introductions, but with a sharper question than "what do you do." For each person on the client side: can they approve designs, can they approve spend, and whose opinion do they defer to? Name the single decision-maker out loud and get a nod. Projects rarely stall because nobody has opinions. They stall because three people have opinions and nobody established whose counts.

### 2. The outcome, in the client's words (10 minutes)

Ask the client to state what success looks like, even though you already know, especially if the people in the kickoff were not in discovery. You are listening for drift: if the sponsor who signed the proposal describes a different outcome than the marketing lead who will review every deliverable, that gap is cheapest to surface now. Write the stated outcome down verbatim. It becomes the tiebreaker for every scope argument later.

### 3. Scope walk: in, out, and assumed (15 minutes)

Walk the scope at the level of deliverables, and spend most of the time on the edges: what is explicitly out, what is deferred to a later phase, and which line items rest on assumptions. "The build assumes your existing theme is salvageable" is the kind of sentence that must be said to the client's face, because an assumption acknowledged at kickoff is a shared risk, while the same assumption discovered in week four is your mistake. Do not re-sell the project here. The deal is closed; the goal is shared memory.

### 4. Ways of working (10 minutes)

This is the item most agendas skip and the one that prevents the most mid-project pain. Agree, specifically: which channel is for what (Slack for quick questions, email for approvals, calls for decisions), expected response times on both sides, the cadence of status updates, and, above all, where new requests go. Clients will keep having ideas after kickoff. If you do not give those ideas a single named destination, they will arrive as Slack asides and reply-alls, and each one becomes unpriced scope or a dropped expectation.

### 5. Milestones and what done means (10 minutes)

Walk the timeline at milestone level, with dates, and state what each milestone depends on from the client: content delivered by a date, staging access, app credentials, review turnarounds. Then define acceptance: who reviews deliverables, within how many days, and against what standard. If your team runs a [definition of done](/blog/definition-of-done-shopify-projects), summarize it here so "finished" means the same thing on both sides of the table.

### 6. Risks and open questions (5 minutes)

Read out the open questions discovery deliberately left unresolved, each with an owner and a date. Five minutes here shows the client you know where the uncertainty lives, and converts silent risks into assigned work.

### 7. Next actions (5 minutes)

End with the specific list: what your team does this week, what the client owes and by when, and the date of the first status update. A kickoff that ends with mutual enthusiasm but no dated actions was a pleasant call, not a kickoff.

## How to run the meeting

The delivery lead facilitates, not the salesperson. The person who sold the project should attend and handle the "why is it shaped this way" questions, but the client needs to learn that the people answering their emails for the next two months own this project now.

Record the call, with everyone's knowledge, and send a written summary within 24 hours: decisions made, the confirmed outcome statement, the working agreements, and the action list with owners and dates. Ask the client to confirm or correct it. [PMI's Pulse of the Profession research on communications](https://www.businesswire.com/news/home/20130522006700/en/PMI-Project-Budget-Risk-Due-Ineffective-Communications) found that ineffective communication is the primary contributor to project failure one third of the time, and hurts project success more than half the time. The kickoff is the single most concentrated communication event between signing and launch; running it without a written, confirmed record wastes most of its value.

One hour is the right default. If the agenda will not fit, that is a signal, not a scheduling problem: either discovery left too much unresolved, or the project is large enough to justify separate internal and client sessions.

## Common failure modes

- **The kickoff becomes a second sales pitch.** The deck restates the proposal's benefits instead of walking scope edges and working agreements. Everyone leaves aligned on enthusiasm and nothing else.
- **The kickoff becomes a discovery session.** A stakeholder who skipped discovery shows up with new requirements, and the meeting absorbs them into the plan in real time, unpriced. New requirements at kickoff go to the open-questions list and the change process from item four, not into the scope.
- **The decision-maker sends a delegate.** If the person who can approve things is not in the room, every approval for the rest of the project routes through someone who was not there when the rules were set. Reschedule before running it without them.
- **Nothing is written down.** The meeting happened, the recording exists, and nobody can say three weeks later what was agreed about review turnarounds. A recording is storage, not memory.
- **Assumptions stay indoors.** The team walks scope but skips the assumptions underneath it, usually out of politeness. Every assumption you do not say out loud at kickoff becomes your sole property the moment it breaks.

## Where the kickoff gets easier to run

Everything above is a documentation and consistency problem: the kickoff is only as good as the discovery record behind it, and its output only survives if someone writes the summary, tracks the open questions, and catches the requirements that trickle in afterward. At most agencies that someone is a senior person doing it between billable work.

This is the part CommerceCopilot covers. Its Business Analyst agent maintains the project's context as a living model from the first discovery call onward: what is confirmed, what is assumed, and what is still open, built from meeting transcripts, connected Slack channels, notes, and email. The [meeting notetaker](/docs/meeting-notetaker) can join the kickoff call itself, with the host's permission, and fold the discussion into that model while the meeting is still running, so decisions and newly surfaced questions land in the project record instead of in one attendee's notes. After kickoff, the client's new ideas arriving in Slack threads land in the same model, which is what keeps item four of the agenda honest. The [discovery walkthrough](/docs/your-first-discovery-project) shows the loop from first call to accepted, sprint-ready tickets.

## FAQ

### Should the internal kickoff and the client kickoff be separate meetings?

Yes, whenever the people who scoped the project and the people delivering it are not identical. The internal session is where the delivery team asks the blunt questions ("is this estimate real," "what is the client actually worried about") that should never be asked in front of the client. Run it before the client kickoff so the client-facing meeting presents one aligned team.

### How long should a project kickoff meeting be?

Sixty minutes for a typical scoped build, ninety for projects with multiple client stakeholders or integrations that need their own walk-through. A 30-minute kickoff on a well-documented project beats a two-hour one reconstructing discovery live.

### What is the difference between a kickoff meeting and a discovery call?

Sequence and purpose. Discovery happens before the quote and exists to find out what should be built. The kickoff happens after signing and exists to align everyone on what was decided and how delivery will run. When a kickoff starts doing discovery's job, the project is absorbing unpriced scope in its first hour.

### What if the client tries to change scope during the kickoff?

Acknowledge the request, put it on the open-questions list with an owner, and keep the meeting moving. The change process from the ways-of-working item exists for this. Relitigating scope live, in a meeting framed as a celebration of the signed deal, is how phase-two items migrate into phase one for free.

---
Canonical page: https://www.commercecopilot.ai/fr/blog/shopify-project-kickoff-meeting