Customer Onboarding Phase Gates: Exit Criteria That Stop Projects Advancing Before They're Ready (Free Template)

Here’s how most implementations actually advance:

the calendar says it’s Tuesday, so we’re moving to the next stage.

The kickoff happened. Training was delivered. The configuration has a green checkmark next to it in the project tracker.

None of which proves the customer can do the thing they bought the product for.

The project advanced on activity – things that were done – rather than evidence: things that are demonstrably true.

Projects that advance on activity surface their problems at go-live, when fixing them is expensive. The integration that “looked fine” breaks under real data. The workflows the customer “approved” were never actually shown to the people who’ll use them. The training that was “delivered” turns out to mean one person watched the recording.

This is what phase gates fix. Not by adding more process. By replacing the calendar as the thing that decides whether a project moves forward.

What a phase gate is (and what it isn’t)

A phase gate is a short list of conditions that must be verifiably true before an implementation advances from one stage to the next.

And the word “verifiably” is doing most of the work.

A checklist lists work to do. A gate lists conditions that must be true, each with someone who confirms them. “Training delivered” is a checklist item – you tick it and move on. “Three users from the customer’s operations team completed the first workflow end to end, confirmed by the ops team lead” is a gate condition. One records activity. The other records evidence.

The distinction matters because activity is easy to fake. A customer says “looks good” on a configuration call and then, two weeks later, discovers it doesn’t match how their team actually works. A stakeholder nods through a training session and never logs in again. The checklist said everything was fine. The evidence said otherwise.

A gate catches this before it becomes a go-live emergency.

Three gates carry most B2B implementations. A fourth closes onboarding itself. Here is what each one needs.

Gate 1: The handoff gate (sales → onboarding)

This is the gate between “we sold something” and “we’re building it.” The person who receives the work – your onboarding or implementation lead – owns it. If the conditions aren’t met, onboarding doesn’t start.

The conditions are simple and specific:

• A documented business outcome. Not “they bought the enterprise plan.” What does the customer need to be true for the implementation to be worth the money they spent? If nobody can write that down in a sentence, nobody knows what they’re building toward – and that sentence needs to come from the customer, not from your CRM notes.
• Named customer-side stakeholders, with their roles and contact details. The champion – the person who drove the purchase – is the minimum. But a single-threaded implementation is a fragile one. The gate should also name the technical owner (the person who controls system access and integration decisions) and the economic buyer (the person whose budget it is). If the champion leaves in week three – and champions do leave – you need to know who else can keep the project alive.
• A written record of what sales promised. Integrations, timelines, specific features, custom work – captured while the deal is fresh, not reconstructed from Slack messages three weeks later. This isn’t a CRM field. It’s a short document the AE writes before they move on to the next deal, confirming what the customer was told and what commitments were made.

If any of these three is missing, the handoff hasn’t happened. The project stays in sales until they are.

This gate is the operational version of a clean sales-to-CS handoff. Most handoff advice focuses on meetings and templates. A gate goes further: it makes the handoff a hard barrier, not a handover that happens whenever the AE gets around to writing up their notes.

Gate 2: The configuration gate (setup → ready to go live)

The configuration is “complete.” The project plan has green checkmarks. Ready to go live?

Not yet. Configuration complete means your team did the work. It doesn’t mean the work was right.

The configuration gate is owned by the implementation lead, and it requires three things before the project can move to go-live:

• Customer-approved workflows. Not “we walked them through the configuration on a call and they nodded.” The customer’s actual end users – the people who will work in the tool every day – have seen the workflows, tested them against their real processes, and confirmed they work. One sign-off per workflow, from the person who owns that process on the customer’s side.
• Validated data. The migration ran, the import completed, the API is pulling – and someone on the customer’s side has checked that the data is correct, complete, and in the right place. “The import finished without errors” is not the same as “the data matches what we expected.” Only the customer can confirm the second one.
• A completed technical test. An end-to-end test run by your team, observed or signed off by the customer’s technical owner. The integration works. The authentication works. The permissions are correct. If it breaks under real conditions, it fails the gate.

Notice what’s not here: “all configuration tasks marked complete.” That’s the checklist. The gate asks whether the configuration actually works for this customer, in their environment, with their data and their people. Those are different questions.

Gate 3: The go-live gate (configured → live)

This is the gate most teams skip, and it’s the one that costs them.

Going live means the customer is using the product in production, with real work flowing through it. But “the switch is flipped” and “the customer is getting value” are not the same event. The go-live gate makes sure the second one actually follows the first.

Three conditions:

• Trained users who can demonstrate competence. Not “training was delivered.” Not “the recording was shared.” Actual users – the people whose daily work depends on the product – have completed the workflows they’ll use in production, without hand-holding, and their team lead confirms they’re ready. If the training happened but nobody can do the thing, the gate is not met.
• A working support path the customer knows how to use. When something breaks at 4pm on a Thursday – and something will break – does the customer know exactly where to go? Who to contact? What information to include? If they’d have to email their champion, who’d then email your CSM, who’d then file a ticket, you have a support path that works for your org chart and fails for the customer. The gate requires a single, known, tested route from problem to resolution.
• The first-value scenario can be completed end to end. Pick the one workflow that represents “the customer is getting what they paid for.” For a payroll product, it’s running the first live payroll. For an analytics tool, it’s the first dashboard going live to stakeholders. For a CRM, it’s the first deal moving through the pipeline. Whatever it is, the customer has completed it once – not in a test environment, in production – before you declare go-live done.

Go-live without these three conditions is a bet. Sometimes the bet pays off. When it doesn’t, you’re fixing things in production while the customer’s confidence erodes. That’s an expensive place to discover what should have been caught at a gate.

Gate 4: The value gate (close onboarding)

Onboarding doesn’t end at go-live. It ends when the customer has reached actual value and can sustain it without the implementation team.

This gate is owned by whoever receives the account – the ongoing CSM, the account manager, the support team – and it’s the final check before onboarding formally closes. Five conditions:

• The agreed first-value outcome actually happened. Go back to Gate 1. The business outcome you documented before onboarding started – the thing the customer bought the product to achieve. Has it happened? Not “are they configured,” not “are they trained.” Did the thing they paid for actually occur? If the answer is no, onboarding isn’t finished – it’s just quietly abandoned.
• The customer can repeat it without the implementation team. One successful run with your team in the room proves the product works. A second run, done independently, proves the customer can use it. If the customer still needs your implementation manager to complete a core workflow, you haven’t handed over – you’ve created a dependency.
• Any unresolved work is documented, owned, and explicitly separated from go-live. Every implementation leaves open items. A feature request, a workflow the customer wants to revisit, a department that wasn’t ready for training. The gate doesn’t require everything to be done. It requires everything that isn’t done to be written down, assigned to a named owner, given a date, and clearly marked as “not a go-live blocker.” Without this, open items quietly hold the project hostage – nobody wants to close onboarding with loose ends, so onboarding never closes.
• Users know where to get help and who owns the account now. Two questions every end user should be able to answer without thinking: “If something breaks, I go to...” and “The person on your side who owns our account is...” If the answer to either involves “I think my manager knows,” the handoff is incomplete.
• The next phase has a date. Onboarding ends, but the customer relationship doesn’t. What comes next – a QBR, a 90-day health check, an expansion conversation – has a date on the calendar before the implementation team walks away. Not “we’ll reach out.” A specific day, with a specific owner, in a specific person’s calendar.

Close these five and onboarding is genuinely finished. Skip any one and you’ve handed over an account that looks stable but isn’t.

Three rules that keep gates from becoming bureaucracy

Gates sound like process, and process sounds like paperwork. Done wrong, gates become the thing everyone routes around – a form to fill in, a meeting nobody prepares for, another 40-item checklist that slows the project without improving the decision.

Three rules prevent that.

Keep each gate to a handful of conditions

The handoff gate has three conditions. The configuration gate has three. The go-live gate has three. The value gate has five. This isn’t a coincidence – it’s a target.

A gate with twelve conditions is a checklist wearing a different name. Nobody can hold twelve conditions in their head, so they become a form-filling exercise. The point of a gate is focus: what are the few things that, if untrue, make advancing genuinely dangerous? Everything else is a task. Tasks belong in the onboarding plan. Gates belong at the boundaries.

Let the person receiving the work own the gate

The person finishing a phase is not the right person to confirm it’s finished. They’re invested in moving forward. Their manager is invested in velocity. The cleanest solution: the person who inherits the work owns the gate.

Onboarding accepts the sales handoff. The customer’s technical owner accepts the configuration. The account owner – CSM or account manager – accepts the finished implementation and the value confirmation.

This does two things. It makes the gate a real check rather than a rubber stamp, because the receiver has every incentive to catch problems before they become their problems. And it forces a conversation: “Here’s what I’m handing you. Is it ready?” That conversation, done well, surfaces more than any checklist.

Separate genuine blockers from the phase-two backlog

Enterprise customers always have one more request. The legal team wants a custom field. The marketing department heard about a feature on a competitor’s roadmap. The CEO’s nephew has opinions about the dashboard layout.

If the gate waits for every request to be resolved, onboarding never ends. The rule: a go-live blocker is something that prevents the customer from reaching first value. Everything else is a phase-two item – documented, owned, dated, and explicitly not blocking go-live.

The distinction is simple to state and hard to enforce, because customers don’t always agree with where you draw the line. Which brings us to the question every implementation lead eventually faces.

What to do when a customer wants to skip a gate

Someone senior on the customer’s side wants to go live faster. The configuration is “good enough.” The training can happen “as we go.” The champion insists their team is ready.

You have two choices, and the right one depends on which condition they want to skip.

Some conditions are worth holding the line on. Untrained users who will break something in production. Unvalidated data that will surface errors in front of the customer’s own customers. A missing support path that means problems land in your inbox with no routing and no owner. These aren’t process rigidity – they’re the difference between a controlled go-live and an uncontrolled one, and an uncontrolled go-live costs more trust than a delayed one.

Hold the line. Explain why. Frame it in the customer’s terms: “If we go live without your ops team having tested the workflow with real data, the first time something doesn’t match, it’ll be your ops team’s manager calling you – not us. Let’s make sure that doesn’t happen.”

Some conditions can move forward as an owned, dated open item. A department that wasn’t available for training but doesn’t touch the product in phase one. A nice-to-have configuration polish that can happen in week two of production. A stakeholder who wants to review the setup but has no bearing on whether first value is reached.

These aren’t blockers. Write them down, assign an owner, put a date on them, and move them past the gate. The gate stays intact. The project keeps moving. The open item is tracked – as a condition for the value gate, if appropriate – but it doesn’t hold go-live hostage.

The principle: gates exist to prevent expensive failures, not to prevent every possible imperfection. If skipping a condition creates a recoverable problem, it’s a judgement call. If it creates an unrecoverable one, it’s a hard stop.

Why gates matter (and what happens without them)

Without gates, your onboarding process is a template, not a standard.

“Done” means something different to every CSM. One person closes onboarding when go-live happens. Another waits until the customer has run two payroll cycles. A third hands over when the tasks are all ticked, regardless of whether the customer can actually use the product. Same process on paper. Radically different outcomes for customers.

The quality of a customer’s onboarding becomes a lottery based on who they happened to get assigned to.

That’s the real cost. Not the occasional go-live failure – those happen anyway. It’s the invisible inconsistency. Two customers with the same product, the same plan, and the same potential get two different onboardings because one CSM has high standards and the other is behind on their book and rushing accounts through. The customers don’t know they got different treatment. They only know whether the product worked for them or not – and the ones it didn’t work for churn at renewal, ten months later, for reasons nobody connects back to a gate that wasn’t there.

Gates fix this by making the standard explicit. Every implementation, every CSM, every customer hits the same conditions at the same transitions. The calendar doesn’t decide. Activity doesn’t decide. The CSM’s gut doesn’t decide. Evidence decides.

This is also where the five onboarding stages and phase gates intersect. Stages name the phases of the journey – kickoff, setup, configuration, go-live, adoption. Gates sit at the boundaries between them, making sure one stage is genuinely complete before the next one consumes resources. A stage tells you where you are. A gate tells you whether you’re allowed to leave.

Making gates visible to the customer

A gate only works if two things are true: the condition is verifiable, and someone owns the confirmation.

“Verifiable” means there’s a record. Not a verbal yes on a call. Not an email that says “looks good.” An actual confirmation – a form submission, a sign-off, a completed task with a named owner on the customer’s side – that says: this condition was checked, by this person, on this date.

General-purpose project management tools can model a gate internally. You can set up a Monday.com board with a “gate review” column, or an Asana task with a custom field. But here’s the problem: the gate stays invisible to the customer. It’s your process, running in your tool, and the customer only finds out they didn’t meet a condition when you tell them the project is delayed.

That turns the gate from a shared standard into an internal secret – and internal secrets look like arbitrary roadblocks from the customer’s side.

A gate works better when the customer can see it: the conditions, who owns each one, and what’s still open. In Valuecase, each customer gets their own branded Space – the single place that customer opens to get onboarded, holding their plan, tasks, forms, and resources behind one link. The gates live inside that Space as tasks with named owners on both sides, visible to everyone who needs to see them.

The handoff gate conditions become tasks assigned to the AE and the onboarding lead, with a form the onboarding lead fills in to confirm each condition is met. The configuration gate lives in the customer’s own Space, with tasks assigned to their technical owner – so the customer sees exactly what’s required and who needs to act. The go-live gate is a shared checklist the customer’s team lead and your implementation manager both confirm, creating a record that survives staff changes on either side.

Because Spaces are built from templates, you don’t rebuild the gates per customer. You set them up once as part of your standard onboarding template – the four gates, their conditions, their owners – and every new customer’s Space comes pre-loaded with them. The same automation that spins up the Space when a deal closes through Valuecase’s HubSpot and Salesforce integrations drops the gates in automatically. No per-account assembly. No “I’ll send you the gate criteria later.”

A gate the customer can’t see is a rule. A gate the customer can see is a shared commitment. Shared commitments get met. Rules get argued with.

Free template: the four phase gates

Copy this structure. The blank lines are yours to fill with the conditions that matter for your product and your customers. One owner per gate – the person who confirms it and says “yes, we can move forward.”

Gate 1 – Handoff (sales → onboarding)

Owner: Onboarding / implementation lead

• Business outcome documented – what does success look like, in the customer’s words. Confirmed by: ______ | Date: ______
• Customer-side stakeholders named – champion, technical owner, economic buyer, with roles and contact details. Confirmed by: ______ | Date: ______
• Written record of what sales promised – integrations, timelines, commitments, captured while the deal is fresh. Confirmed by: ______ | Date: ______

Gate 2 – Configuration (setup → ready for go-live)

Owner: Implementation lead + customer technical owner

• Workflows tested and approved by customer’s end users – not just the champion. One sign-off per workflow, from the person who owns that process. Confirmed by: ______ | Date: ______
• Data validated – imported, checked for accuracy by the customer, confirmed complete. Confirmed by: ______ | Date: ______
• End-to-end technical test completed and signed off – by the customer’s technical owner. Confirmed by: ______ | Date: ______

Gate 3 – Go-live (configured → live in production)

Owner: Implementation lead + customer team lead

• End users trained and can demonstrate the core workflows – without hand-holding, confirmed by their team lead. Confirmed by: ______ | Date: ______
• Support path documented, tested, and known to the customer’s team – a single, tested route from problem to resolution. Confirmed by: ______ | Date: ______
• First-value scenario completed end to end in production – real data, real work, not a test. Confirmed by: ______ | Date: ______

Gate 4 – Value confirmation (close onboarding)

Owner: Ongoing CSM / account owner

• First-value outcome (from Gate 1) actually achieved – the thing the customer bought the product for has happened. Confirmed by: ______ | Date: ______
• Customer completed the core workflow independently – no implementation team involvement. Confirmed by: ______ | Date: ______
• All unresolved work documented, owned, dated, and marked “not a go-live blocker” – nothing holding the project hostage. Confirmed by: ______ | Date: ______
• End users know where to get help and who owns the account – two questions any user can answer without thinking. Confirmed by: ______ | Date: ______
• Next phase has a date on the calendar – QBR, health check, expansion conversation. Confirmed by: ______ | Date: ______

A note on using this template: start with the gates as they are. Run them across your next three implementations. You will discover conditions that are missing for your product and conditions that don’t apply. Edit accordingly. But resist the urge to add more than five or six conditions per gate. Remember the rule: a gate with twelve conditions is a checklist wearing a different name, and checklists don’t make decisions – they just record activity.

FAQ

What’s the difference between an onboarding stage and a phase gate?

Stages describe where you are in the implementation journey – kickoff, configuration, go-live. Gates sit at the boundaries between stages and ask: “Are we actually ready to leave this stage?” A stage tells you where you are. A gate decides whether you’re allowed to move. For the five-stage framework these gates map onto, see the stages of customer onboarding.

How is a phase gate different from a checklist?

A checklist lists work to do. A gate lists conditions that must be verifiably true, with someone who confirms each one. “Training delivered” is a checklist item. “Three users completed the core workflow independently, confirmed by their team lead” is a gate condition. Checklists record activity. Gates require evidence.

Who should own each gate?

The person receiving the work, not the person finishing it. Onboarding accepts the sales handoff. The customer’s technical owner accepts the configuration. The ongoing CSM accepts the finished implementation. This gives the receiver every incentive to catch problems before they become their problems.

What if a customer wants to skip a gate?

Distinguish between conditions that prevent an unrecoverable failure and conditions that create a recoverable one. Untrained users, unvalidated data, and missing support paths are worth holding the line on. A department that wasn’t available for training but doesn’t touch the product in phase one can move forward as an owned, dated open item – tracked, but not blocking go-live.

How many conditions should a gate have?

Three to five. Fewer than three and the gate isn’t checking enough. More than five and it becomes a checklist that nobody can hold in their head. If you have more than five, some of those conditions are tasks – move them into the onboarding plan where they belong.

Can I run phase gates in a spreadsheet?

You can, but the gate stays invisible to the customer – and a gate the customer can’t see looks like an arbitrary roadblock. The conditions, owners, and confirmations need to be visible to both sides, with tasks assigned to named people and confirmations captured as a record rather than a verbal yes. General-purpose tools like spreadsheets, Monday, or Asana can model a gate internally but weren’t built to get the customer through it.

Build gates your customers can actually see. Start a free trial of Valuecase or book a demo – your gates, your template, every customer’s Space.