A client signed for three service lines in the same week last year: bookkeeping, paid acquisition, and a website rebuild. Their previous arrangement had been four separate vendors and a slack channel none of them read. By day fourteen of working with us they had one shared workspace, a named pod across all three lines, a baseline report on what they were spending, and a first sprint plan that everyone had signed off on. Day fifteen was the first regular weekly standup.
This is the playbook we used. We have run it eleven times since with minor variations and the cadence holds. Fourteen days is enough to do the work properly and short enough that the client does not lose momentum between contract signing and the first visible output.
The thesis is simple. A multi-line kickoff fails when the lines are treated as separate onboardings stacked on top of each other. It works when the first two weeks are run as one project with one project manager, one decision log, and one set of shared artifacts. The service lines diverge in week three.
Why fourteen days, not seven and not thirty
Seven days is the timeline most agencies promise and almost none deliver. It treats kickoff as administrative, gets the contract counter-signed, sends a welcome email with login credentials, and books a “strategy call” for week two. The client never sees a baseline and the first thirty days produce no defensible output.
Thirty days is the timeline used by large consultancies billing for discovery. It produces a deck. The deck is usually accurate and almost always too late, because the client signed expecting work to start, not a second sales cycle.
Fourteen days lets us do real discovery, build the pod, agree the first sprint, and ship the foundational artifacts: a RACI, a scope document, and a baseline report. The client walks out of day fourteen with decisions made, not options to consider.
The deliverable of a kickoff is not a deck. It is a set of decisions the client and the pod have made together, written down, and agreed.
The 14 days, mapped
Below is the schedule we run. Days are business days. The named owner is on our side unless marked otherwise.
DAY | PHASE | OWNER | ARTIFACT PRODUCED
-----|--------------------------------|----------------|----------------------------------
1 | Discovery call (90 min) | Engagement Lead| Discovery notes, open questions
2 | Access provisioning | Ops + Client | Access matrix, credentials vaulted
3 | Tooling audit | Pod Leads | Tooling inventory, gap list
4 | Baseline metrics pull | Analyst | Baseline report (last 90 days)
5 | Pod assembly | Engagement Lead| Pod roster, RACI v1
6 | Roles and ownership review | Pod Leads | RACI v2, escalation path
7 | Internal pod sync | Engagement Lead| Cross-line dependencies logged
8 | First sprint scoping | Pod Leads | Sprint backlog draft
9 | Brief review with client | Engagement Lead| Sprint backlog v2
10 | Brief sign-off | Client | Approved sprint plan
11 | Workspace provisioning | Ops | Notion/Linear set up, access granted
12 | Dashboards live | Analyst | Live KPI dashboard, baseline locked
13 | Kickoff working session (3 hr) | All | Decision log, action register
14 | Week 1 sprint kickoff | Pod Leads | Active sprint, standup cadence set
Days 1 to 2: Discovery and access
The discovery call is ninety minutes, no longer. We have a structured agenda: business model, the three things that are working, the three things that are not, the upcoming quarter’s commitments, and the constraints we should know about before we start spending anyone’s money. We send the agenda forty-eight hours in advance so the client’s leadership team comes prepared.
Day two is access. This sounds trivial and is the most common failure mode of a kickoff. We have a standard matrix of what we need across each service line: read-only at first wherever possible, full access only where the work requires it. Every credential goes into a shared vault, never into email. We have a named client-side owner for access requests so the engagement lead is not chasing IT.
Days 3 to 4: Baseline metrics and tooling audit
You cannot improve what you have not measured. Days three and four exist to capture what the business looked like the day before we started, in numbers and in tooling.
The tooling audit catalogues every system in scope for our work: the accounting stack, the marketing stack, the website stack, the CRM, the analytics layer, the data warehouse if one exists. We note the version, the seat count, the renewal date, and whether anyone on the client team actively uses it. Roughly thirty percent of the tools we inventory turn out to be unused. That fact alone usually pays for the kickoff.
The baseline report covers the last ninety days, sometimes the last twelve months for accounting. It is a single document the client can hand to a board member. It is also the number we measure ourselves against in month six. We do not skip this even when the data is messy. A messy baseline is still a baseline.
Days 5 to 7: Pod assembly and ownership
By day five we know enough to staff the engagement. The pod is named, the RACI is drafted, and every line item of work has a single accountable owner. We use the strict version of RACI: one A per task, no exceptions. If two people are accountable, no one is.
Day seven is an internal sync where the pod leads from each service line walk through dependencies. The marketing lead needs the website lead to expose conversion tracking. The bookkeeping lead needs the operations contact to clarify which entity owns which bank account. These dependencies surface on day seven, not on day forty when they have already caused a missed deliverable.
The artifact from this phase is a RACI the client can read in five minutes. We have seen RACIs that took three hours to interpret. Those are not RACIs. Those are organizational charts in disguise.
Days 8 to 10: First sprint scoping and sign-off
The first sprint is two weeks, starts on day fifteen, and contains work that produces something visible by the end. We avoid the temptation to load the first sprint with “foundational” work that produces nothing the client can show their board. The client signed up to see motion. The first sprint shows motion.
Day nine is the brief review. We walk the client through what is in the sprint and, more importantly, what is not. The “not” list is usually longer and more useful. It is the things the client mentioned in discovery that we have explicitly deferred to sprint two or three, with reasoning.
Day ten is sign-off. Written, in the shared workspace, time-stamped. If sign-off slips past day ten the kickoff is in trouble and we say so. We have learned not to let day-ten slippage compound. We escalate to the executive sponsor on the client side and reschedule before day eleven.
Days 11 to 12: Workspace and dashboards
The workspace gets built once and used for the life of the engagement. We default to Notion for documentation, Linear for sprint tracking, and Slack for daily communication. We will fit a client’s existing stack if they have one in place and it works.
The dashboard is the live view of the metrics we will report against. For a multi-line engagement that usually means three layers: business-level KPIs at the top, service-line metrics in the middle, sprint-level outputs at the bottom. The client should be able to open one URL and see all three. If they cannot, the dashboard is wrong.
Days 13 to 14: The kickoff working session
Day thirteen is a three-hour working session, in person if possible, video if not. The pod is in the room. The client’s executive sponsor and the line owners are in the room. We do not present. We work.
The agenda has three parts: walk the baseline report and agree what it says, walk the first sprint and agree what success looks like, and walk the decision log and confirm what has been decided. We close the session with an action register: every open item with a name and a date next to it.
Day fourteen is light by design. The pod leads run their first internal standup, the cadence is set, and the client receives a one-page summary of where we landed. That summary becomes the reference document the engagement is measured against.
What the client owns on day fifteen
By the morning of day fifteen the client has, in writing and in a workspace they own:
- A discovery summary and a list of decisions made during kickoff.
- An access matrix and a vaulted credential set.
- A tooling inventory and a gap list with recommendations.
- A 90-day baseline report.
- A named pod with a RACI and an escalation path.
- A signed-off first sprint plan.
- A live KPI dashboard.
- A weekly standup cadence on the calendar.
None of this is exotic. The discipline is in producing all of it inside two weeks without ever delaying the first sprint. We have not always hit fourteen days cleanly. The longest we have run is seventeen, the shortest twelve. The variance is almost always on access provisioning, which is why day two has its own named owner and a daily check.
When it has been worth it
The clearest case is a vendor consolidation engagement we ran for a midmarket client who replaced six vendors with us across three service lines. They had been in the seven-vendor arrangement for two years and could not produce a unified report on what they were spending. Day fourteen of the kickoff was the first time anyone in their finance team had seen the full picture in one document.
If you are evaluating a provider across more than one service line, ask them what their kickoff looks like by day. If the answer is vague, the first ninety days will be too.
Now what?
The playbook above is what you should expect from any partner running multi-line work. If you want to see how we apply it across our full service range or how a specific kickoff would look for your business, book a 30-minute scoping call and we will walk through your day one through fourteen on the call.