Key takeaways
- Reconcile the signed contract, order form, statement of work, proposal, RFP answers, security commitments, and approved call notes.
- Convert each operative promise into an owner, condition, due date, acceptance method, and source reference.
- Resolve conflicts and missing dependencies before kickoff; do not ask the customer to adjudicate internal document history.
- Keep internal selling notes private while making the delivery-relevant understanding visible to the customer.
01
The kickoff should not be the first contract review
The customer expects a connector in week one because it appeared in the proposal. The statement of work calls it customer-built. A security response promised a log-export format the implementation lead has never seen. Everyone arrives at kickoff prepared, just not for the same engagement.
Before scheduling kickoff, collect the executed agreement, order form, statement of work, final proposal, RFP and security responses, approved exceptions, and relevant customer-approved notes. Identify the precedence rules in the agreement, then reconcile the practical meaning rather than assuming one document contains the whole deal.
Swipe to compare every column
| Commitment field | Question it answers | Failure if absent |
|---|---|---|
| Source and clause | Where was this accepted? | The promise cannot be verified |
| Owner | Who must make it true? | Everyone assumes another team |
| Condition or dependency | What must happen first? | Dates are treated as unconditional |
| Acceptance evidence | How will both sides know it is done? | Completion becomes an argument |
| Change route | How can the understanding be revised? | Scope drifts through conversation |
02
Build a commitment ledger, not a longer summary
For each deliverable, capability, service level, integration, data obligation, security action, training item, migration task, dependency, exclusion, milestone, and acceptance condition, record the source, exact scope, owner on each side, date or range, evidence, risk, and status. Link back to the authoritative artifact.
Mark ambiguity rather than cleaning it up in prose. “Standard integration” and “launch support” can hold several incompatible meanings. Resolve them with the commercial and delivery owners while the context is still available.
03
Run a readiness review before asking the customer to attend
Confirm commercial approval, delivery capacity, environment access, data route, security prerequisites, integration ownership, customer team, decision rights, milestone realism, and the first useful outcome. Escalate missing scope or unapproved commitments before the kickoff deck is built.
Give the customer a concise shared brief with outcomes, scope, roles, dependencies, milestones, risks, communication, and change control. Keep internal forecast history, competitive notes, private sentiment, and compensation out of it. Transparency does not require exposing every internal record.
04
Close the learning loop back to sales and product
Record handoff defects by source: outdated proposal language, unsupported claim, unclear contract term, missed dependency, unavailable capacity, or hidden customization. Correct the template, library, approval rule, or qualification step that created the defect. Do not merely coach the implementation lead to catch it sooner next time.
Measure time from signature to readiness, unresolved commitments at kickoff, scope changes in the first month, customer repetitions, delayed dependencies, and disputes traced to pre-sale material. A clean handoff is not a meeting. It is a verified transfer of the understanding that persuaded the customer to buy.
Primary sources and further reading
Use the source material to validate details against your own context and current platform configuration.
This field note follows the XenGrowth editorial policy: primary sources where available, visible limitations, material review dates, and no invented first-hand experience.
Stay with the problem
