Jump to section
Your customer said yes. The demo went well, the champion is excited, the budget is approved. Then legal review begins. And procurement. And the security questionnaire. Three, four, sometimes six weeks pass before a signed contract lands in your inbox.
What happens on the customer's side during those weeks?
Nothing. The internal momentum they built to get the purchase approved – the case they made to their boss, the enthusiasm they sold to their team – slowly drains away. By the time your onboarding manager sends the first "let's get started" email, the energy that closed the deal is gone. Kickoff becomes a restart, not a start.
This is the pattern in most B2B implementations, and it's so common that most teams accept it as inevitable. It isn't.
The gap between "yes" and "signed"
In B2B software and services, the decision to buy and the signed contract are rarely the same moment. Legal needs two weeks to review terms. Procurement has a vendor registration process. The security team wants a SOC 2 report and a filled questionnaire. The person who signs – the economic buyer – was in two of the sales calls and needs a summary from their team before they'll put pen to paper.
None of this is negotiable, and none of it is new. Yet in most companies, the implementation team waits. They wait for the signed contract, then the internal handoff, then the kickoff meeting – and only then does anyone start moving the project forward.
What if those waiting weeks carried real forward motion?
What if the implementation plan was already agreed, the owners already named, and the customer-side dependencies already in motion – before the contract came back?
That's not a hypothetical. It's a tactical choice, and the teams that make it cut weeks from their time to value without changing anything about how they implement.
What "start before signature" actually means
Let's address the objection you're already forming, because it's the right one: you can't give away implementation work without a signed contract. Configuring a production environment, assigning engineers, running a data migration – that's paid delivery, and it needs a commercial commitment first.
Fair. That's not what this is.
Starting onboarding before signature means doing the planning work, not the delivery work. Specifically, four things that cost almost nothing, commit nobody to free consulting, and change the shape of the project once it goes live:
- Agree the implementation plan. Not draft it in isolation – co-create it with the customer while they're still engaged from the buying process.
- Introduce the implementation owner. Put a face to the name before the project starts, so the customer meets the person they'll actually work with.
- Put dates on the first steps. Lock the kickoff, the first milestone, and the target go-live before procurement has a chance to let the timeline drift.
- Launch the customer-side queues. IT tickets, data exports, security reviews – the things that cost an hour of their time but three weeks of waiting.
None of this delivers the product. All of it delivers momentum. And momentum is what determines whether the first month of onboarding feels like a running start or a cold open.
The four things to do before the contract is signed
Put the implementation plan into the final sales conversation
The sales process has a natural final stage: the moment the champion says "we're going with you" and the commercial details are locked. In most deals, that's where the AE disengages and hands over to legal.
Here's the shift: instead of ending that conversation with "we'll send the contract," end it with "let's sketch the plan."
Open a draft onboarding plan – not a blank page, not a locked deck, but a working structure you can edit live – and walk it with the customer. Ask, don't tell: "What does a successful go-live look like to your team?" "Who needs to be in the room for the data setup?" "Is there an internal approval step we should know about?"
This does three things at once. It switches the register from "we're selling to you" to "we're planning a project together," which is the relationship onboarding needs. It surfaces blockers while there's still calendar to solve them – the procurement step that adds two weeks, the integration their IT team has opinions about, the stakeholder who wasn't on any of the sales calls but owns the decision. And it gives the kickoff call something to open with: a plan that's already 80% agreed, instead of a blank slate and an hour of introductions.
The plan doesn't need to be perfect. It needs fingerprints from both sides. A customer who helped set a date defends that date. One who was handed a date treats it as your problem.
Bring the implementation owner onto the last sales call
This one makes sales teams nervous, and the nervousness is fair. A new face late in a deal can introduce variables nobody asked for. The honest answer: the AE keeps control of the call, the CSM or implementation lead is briefed beforehand on what was promised and what's still open, and their role is to listen and be introduced – not to run the meeting.
Why it matters: the customer has spent weeks or months building trust with the AE. When that person disappears the moment the contract is signed and a stranger sends the kickoff invite, the customer feels a drop. They might not say so, but they feel it – and they're about to invest months of their team's time into a relationship with someone they just met and didn't choose.
Bringing the implementation lead into the last sales conversation changes that. The customer meets the person they'll work with. They hear the promises the AE made in the room, firsthand, so nothing gets lost in translation. And the handoff – the moment that usually creates a gap – disappears, because the next person was already in the room.
This is how to handle the sales-to-CS handoff done proactively. Most handoff advice focuses on what information to transfer. The stronger move is to remove the transfer entirely by overlapping the people before the transition happens.
Put dates on the first implementation steps
Here's a commercial side effect worth understanding, because it's the argument that makes sales want this change rather than tolerate it.
When legal and procurement receive a contract, they have no deadline except their own process. There's nothing pushing them to prioritise your deal over the other twelve in their queue. The contract sits for a week, then another, and nobody on your side has leverage because "we'd love to get started" isn't a deadline anyone in procurement cares about.
Now imagine this instead: before the contract goes out, the customer's implementation owner has agreed to a kickoff date two weeks from now. The data export from the incumbent vendor has been requested. The IT ticket for system access is in the queue. The customer's team is waiting on those things, and the dates are real.
Suddenly procurement has a reason to move. The contract isn't the only thing gating forward motion – there's a working project with dates attached, and the customer's own team has a stake in those dates holding. That tends to pull the close forward, sometimes by weeks, because the customer's internal pressure now works in your favour.
This isn't manipulation. It's making the project real while the paperwork catches up, and letting the project's momentum do what a follow-up email never could.
There's an instructive parallel from the sales side. Clay – the data enrichment platform now valued at $1.25B – famously rebuilt its entire sales motion around a single insight: traditional demos didn't work. Prospects watched, nodded, and then couldn't use the product on their own. So Clay flipped the format. Instead of presenting, they asked the prospect to share their screen, sign up live, and solve a real problem with Clay during the call – with the rep guiding, not lecturing. Varun Anand, Clay's co-founder, describes going from "seven demos to get someone to pay two, three hundred a month to … one call or even none," compressing the sales cycle to a single session by making the prospect an active participant rather than a passive observer.
The principle transfers directly to onboarding. When the customer is a participant in building the plan before signature – rather than a recipient of a plan after it – the timeline compresses for the same reason. Active participants move. Passive recipients wait.
Start the customer-side dependencies that sit in queues
Every implementation has steps that depend entirely on the customer and take far longer to wait for than to do. An IT ticket for system access: one hour of work, three weeks in the queue. A data export from the incumbent vendor: an afternoon of effort, two weeks of waiting for the vendor to respond. A security review: the questionnaire takes a morning, but it sits in the infosec team's backlog for a month.
These are the hidden time bombs in every onboarding timeline. They're not hard – they're just slow, and they sit in queues you can't see and can't control. If you wait until after signature to even request them, you've built weeks of predictable delay into your go-live date before the project has started.
The fix is embarrassingly simple: ask for them now. The moment the customer decides, give them the list: "While legal works through the contract, here are the three things that typically take the longest on your side. If you can start these this week, we'll be ready to move the moment the ink is dry."
Most customers will do it. They just bought your product – their enthusiasm is at its peak. The IT ticket feels like progress. The data export feels like momentum. And while your competitors are waiting for a signed contract to even send the first email, your customer's dependencies are already clearing.
One note: this requires knowing what those dependencies are per customer type. If every implementation starts by discovering that an API key needs IT approval, you're doing discovery during delivery – and that's what creates the delay. Template the dependency list. Make it part of the plan you walk through in the sales conversation. Customers don't mind being asked to do work. They mind being asked to do work they should have been told about three weeks ago.
Why sales gets on board with this
So far this sounds like an operational win for the implementation team – which it is. But if sales doesn't see the upside, it won't happen. The AE owns the relationship until signature, and asking them to change how they close deals needs a commercial reason, not a process argument.
Here's what makes sales want this:
Faster closes. Dated implementation steps create a procurement deadline, as covered above. Deals that would have drifted through legal for weeks gain an internal advocate – the customer's own implementation owner, who now has a project to run and dates to hit.
A stronger close narrative. "We don't just hand you off to a stranger – here's the person who'll run your implementation, joining us today" is a powerful thing to say in a final sales call. It answers the unspoken question every buyer has: "What happens after I sign?" Most vendors answer with "you'll be in good hands." Showing the hands is better.
Cleaner handoffs. When the AE knows the implementation plan is already in the customer's hands and the CSM has already been introduced, the post-close period loses its anxiety. There's no gap to manage, no context to reconstruct, no risk that the customer goes quiet because nobody's talking to them.
Faster time to value – which means faster expansion. A customer who goes live in four weeks instead of eight is a customer who renews and expands sooner. That shows up in the AE's commission in the following year, and smart reps understand that.
What the payoff looks like
Picture two kickoff calls.
In the first, the onboarding manager opens with introductions. Who's who, what does everyone do, here's a slide about our methodology. The customer hasn't seen a plan yet. The goals the AE captured are in a CRM note the CSM skimmed ten minutes before the call. The first real work item – "let's build the plan" – gets scheduled for next week. The kickoff was an introduction. The project starts later.
In the second, the onboarding manager opens with: "We've already sketched the plan with your team, so let's pick up where we left off. The first milestone is locked for the 18th, Sarah owns the data export and she's already requested it, and IT confirmed they'll have system access by Friday. The one thing we still need to pin down is the training schedule – let's do that now."
The difference isn't talent or effort. It's that the second team started onboarding before the contract was signed. The plan exists. The owners are named. The queues are clearing. The kickoff isn't the start of the project – it's the first working session of a project that's already moving.
Weeks that used to be dead now carry the project. And those weeks are the cheapest ones you'll ever reclaim, because they cost nothing except the decision to use them.
How a platform that spans both sides of the signature helps
Most of the friction in starting early is logistical. Sales works in one set of tools – CRM, email, a deck. Onboarding works in another – a project tracker, a spreadsheet, a shared drive. Bridging the two means copying context from one system to another, which is where context gets dropped and where the "handoff gap" comes from.
Purpose-built onboarding tools don't solve this either. They're designed for what happens after close. General-purpose project tools – Monday, Asana, ClickUp, spreadsheets – were never customer-facing to begin with. Your team can use them internally before signature, but the customer can't see the plan you're co-creating without a login, an account, and an invitation.
A platform that runs continuously from sales through onboarding removes the logistics entirely. In Valuecase, the customer works inside a Space – one branded link they open (no login required) that holds the plan, tasks, forms, and key people together. The same Space that served as a digital sales room during the deal becomes the onboarding hub after the close. The draft plan the AE and the customer sketched together in the final sales call? It's already there, in the same link the customer already has, with the same owners and dates they agreed to – and then the onboarding manager opens the same Space and continues from where sales left off.
No new link. No re-introduction. No handoff meeting that could have been an email. The onboarding plan the customer helped shape before the contract was signed is the same plan that runs the implementation after it.
This is the practical difference between a platform built for one half of the journey and one built for the whole thing. When the customer's workspace doesn't reset at signature, the dead weeks between decision and kickoff don't exist – because the project was already running.
FAQ
Is it safe to start onboarding before the contract is signed?
Yes – when you limit it to planning, not delivery. Agreeing the plan, naming owners, setting dates, and launching customer-side dependencies (IT tickets, data exports, security reviews) costs nothing and commits no paid implementation resources. What you don't do is configure environments, assign engineers, or run migrations before there's a signed commercial agreement. The line is straightforward: planning is free; delivery waits for ink.
How do I convince sales to bring the CSM into the final call?
Lead with the commercial argument: dated implementation steps create a deadline for procurement, which tends to pull the close forward. Then address the objection directly – the AE keeps control of the call, the CSM is briefed beforehand, and their role is to listen and be introduced, not to run the meeting or introduce complexity. Sales teams adopt this when they see it as a closing lever, not a handoff chore. For the full handoff picture, start with how to run a clean sales-to-CS handoff.
What if the deal falls through after we've started planning?
You've spent an hour on a planning conversation. That's the investment. Compare it to the weeks of delay you'd absorb by waiting for the contract, plus the energy you'd lose with a cold restart, and the trade-off is heavily in your favour. If the deal does fall through – which is rare once the customer has verbally committed and co-created a plan – the template and the process are reusable for the next one.
What are the customer-side dependencies that usually take the longest?
IT tickets for system access or API keys, data exports from an incumbent vendor, security reviews and infosec questionnaires, and internal stakeholder approvals (especially when the signatory isn't the implementation owner). Each of these costs an hour or two of actual work but sits in a queue for two to four weeks. That's why they belong in the pre-signature window.
When does the kickoff call actually happen?
Ideally within a day or two of the signed contract landing – not a week or two later. The pre-signature work makes that possible, because the plan is already agreed and the dependencies are already moving. When the contract comes in, you're not starting; you're continuing. If you want a step-by-step for that call itself, here's how to run a customer onboarding kickoff.
What's the connection between starting early and time to value?
Starting early attacks the biggest source of wasted time in onboarding: the gap between decision and first action. When you close that gap, you shorten the total window from signature to first value – which is exactly what time to value measures. Teams that overlap sales and onboarding planning typically cut weeks from their implementation timelines without changing anything about the delivery work itself. For the full playbook, see how to reduce time to value in SaaS onboarding.
See how the sales plan becomes the onboarding plan – in one continuous customer Space. Start a free trial of Valuecase or book a demo.
