What a Client Kickoff Call Is Actually For
A client kickoff call is the first meeting after the project is agreed, and its only job is to remove the ambiguity that would otherwise surface halfway through the build. You are locking four things: what finished looks like in terms a non-technical person can check, who has the authority to approve it, what access you need and when it arrives, and how often you will report. Everything else on the call is conversation.
This is a different meeting from the discovery call, and running them as one costs you both. Discovery happens before the money is agreed and exists to decide whether there is a problem worth paying to solve, which the post on [discovery calls for AI projects](/blog/discovery-call-for-ai-projects) covers. Kickoff assumes the sale is closed and the client's mood has changed from evaluating you to expecting results, which is exactly the moment they will answer the hard questions honestly.
The Four Locks Agenda
The Four Locks is the agenda I run every time, in this order, because each lock depends on the one before it. Forty-five minutes is enough. If you cannot close all four in that time, the thing blocking you is the finding, and it belongs in the recap as a risk rather than getting glossed over so the call can end on time.
- Lock the definition of done. Not a feature list, a sentence the client would use to tell a colleague it worked. Our team stops copying orders into the spreadsheet by hand is checkable. An automated order pipeline is not.
- Lock the decision-maker. One named person who can approve and reject. If there are two, you have two projects. If the person on the call has to check with someone who is not there, that someone is the decision-maker and the next call includes them.
- Lock access. Every system, credential, export, and sample file you need, with a named owner and a date. Access is the single most common reason a build stalls, and it is always somebody else's queue.
- Lock the rhythm. When you will report, in what format, and what the client does with it. A fixed weekly note beats an open promise to keep them posted, because the note is a commitment you can keep without being asked.
The order is deliberate. Done comes first because it changes what access you need. Access comes before rhythm because the first report is usually about whether access arrived. If you jump to the schedule before agreeing what finished means, you have scheduled a journey to an unspecified destination.
How to Lock Done So It Cannot Move
Done is locked when the client has described the outcome in their own words and you have written it down in those words. Not paraphrased into your language, and not translated into a feature list. The reason is that a feature list can be satisfied completely while the client remains unhappy, and when that happens you are technically right and unpaid.
The question I use is blunt: three months from now, what has changed in your week that tells you this was worth the money? It gets an answer about behaviour rather than software. Then I ask the counterpart: what would make you say this did not work? That second answer is more valuable, because it names the failure mode they are quietly worried about and have not mentioned.
- Write the client's exact sentence at the top of the recap, in quotes, as the acceptance test.
- List what is explicitly not in scope. Two or three lines is enough, and it prevents the most predictable requests later.
- Name the one thing that would count as failure, and say how you will avoid it.
- Agree who checks the acceptance test and on what date.
Access Is the Real Schedule Risk
On AI builds specifically, access is the risk that eats timelines, and it is almost never the client's fault in a way you can complain about. They need somebody in IT to create an account, somebody in operations to export a sample, somebody in legal to confirm the data can leave a system. Each of those is a queue you do not control, and each one looks trivial until it takes nine days.
So the access lock is a list with owners and dates, made on the call while the decision-maker is present and motivated. Read it back. Ask who chases it if a date slips. Then put the list in the recap, because the recap is what the decision-maker forwards internally, and a forwarded list with names on it moves faster than a request you made once in a meeting.
There is a second reason to be precise here, and it is about your own exposure. Being handed credentials and client data on day one is a responsibility, and the client is entitled to know how you will handle it. Saying so plainly at kickoff builds more confidence than any reassurance later, and the piece on whether [Claude Code is safe for client work](/blog/is-claude-code-safe-for-client-work) sets out the position worth taking.
The Recap Is the Deliverable
The call is not finished when the call ends. It is finished when the recap is sent and confirmed, the same day, while everyone still remembers what was said. The recap is short and it exists to be forwarded. Anything the client will not confirm in writing was not actually agreed, and finding that out on day one is a gift.
What goes in the kickoff recap
| Section | Content | Why it matters |
|---|---|---|
| Done, in their words | The client's own sentence, in quotes | Becomes the acceptance test nobody can reinterpret later. |
| Not in scope | Two or three explicit exclusions | Turns the most likely scope creep into a pre-agreed conversation. |
| Decision-maker | One name, with role | Prevents approval routing through a committee mid-build. |
| Access list | Item, owner, date needed | Gets forwarded internally and moves other people's queues. |
| Reporting rhythm | Day, format, and what it contains | Replaces anxious check-in emails with a predictable note. |
| Start condition | The timeline starts when access is complete | Stops other people's delays becoming your overrun. |
Ask for one word back: confirmed. Not a signature, not a countersigned document, just a reply that says yes this is right. That reply is what you point at, calmly and without drama, the first time someone remembers the project differently. And when a request does arrive that sits outside the exclusions, you are having a pricing conversation rather than an argument, which is the whole subject of [handling scope creep on client projects](/blog/how-to-handle-scope-creep-on-client-projects).
What to Do When a Lock Will Not Close
Sometimes a lock will not close on the call. The client genuinely does not know who signs off, or cannot say what done looks like, or has no idea whether the data can be exported. This is not a failed kickoff. It is a successful one, because you now know the actual risk on day one instead of week three.
The move is to name it, write it in the recap as an open item with an owner and a date, and decide honestly whether work can start without it. Some open items are harmless and some are structural. Not knowing the export format is harmless. Not knowing who approves is structural, and starting a build with an unnamed approver means building for a person whose opinion you have not heard.
- Harmless open item: log it, start work, resolve it in the first report.
- Structural open item: log it, delay the start, and say plainly why. Clients respect this far more than a quiet start followed by a surprise.
- Either way, it goes in the recap. An open item that only exists in your head is a risk you have accepted on the client's behalf.
The habit underneath all of this is treating the first week as the cheapest place to be uncomfortable. A kickoff that surfaces two problems has done its job. A kickoff where everyone was pleasant and nothing was written down has moved those same two problems to the point where they cost real money. If the scope itself still feels loose, fix that before kickoff using [how to scope a Claude Code client project](/blog/how-to-scope-a-claude-code-client-project).
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
How long should a client kickoff call be?
Forty-five minutes is the right target for a typical build, and an hour is the ceiling. The four locks fit comfortably in that time if you send the agenda in advance and do not use the call to re-explain the proposal. If you genuinely need longer, that is usually a sign the scope was not settled before the project was agreed, which is a scoping problem rather than a meeting-length problem.
Is the kickoff call the same as the discovery call?
No, and combining them costs you both. Discovery happens before the money is agreed and exists to decide whether the project is worth doing and what it should cost. Kickoff happens after and exists to remove delivery ambiguity. The client answers differently in each one, because in discovery they are selling you the opportunity and in kickoff they want the thing to work.
Who should be on the kickoff call from the client side?
The person who can approve and reject the work, plus anyone who controls access you need. If the approver cannot make it, reschedule rather than proceeding with a proxy, because a kickoff without the decision-maker locks nothing. Keep the list short otherwise, because a large kickoff turns into a status meeting where nobody commits to anything.
What if the client has never bought an AI build before?
Then part of your job on the call is calibrating expectations, and the most useful thing you can do is be specific about what will be manual, what will be reviewed by a person, and what could be wrong. A first-time buyer who has been told plainly that a human checks the output is a far easier client in week four than one who was allowed to assume it runs itself.
Should I charge for the kickoff call?
It belongs inside the project fee rather than being billed separately, because it happens after the agreement and its purpose is to protect the delivery you are already being paid for. What you should not do is run a full kickoff before anything is signed. That is a free scoping session in disguise, and it is where a lot of unpaid work quietly happens.
Last reviewed by Duncan Rogoff on August 17, 2026
