Domino-proof your onboarding: Lunch & learn playbook

Introduction & purpose

This is not just a team meeting. It's an onboarding audit with teeth.

You'll walk through your current onboarding journey using the DIVE Method and the Risk Webframework to identify where small issues spiral, where assumptions live, and where you can build instrategic "stopper blocks" to prevent downstream chaos.

‍What you'll need

1. 60–90 minutes
2. A virtual or in-person room with your onboarding, CS, implementation, and support teams
3. Post-its, whiteboard or Miro board, or a shared doc
4. Copies of your current onboarding workflow/process (if available)
5. This guide and the downloadable resources included
   

Pre-work: Come prepared to go deep

To get the most value from this Lunch & Learn, each participant should arrive with one recent onboarding experience in mind—preferably one that had bumps, delays, or lessons learned.

Bring the following:

• A quick summary of the onboarding project (no need to over-prepare—just know the basics: who,what, when, and where things got messy).
• 5–10 things that either
  1. Caused friction or delays
  2. Created confusion, misalignment, or tension
  3. Were assumed to be fine, but later turned out to be problematic
  4. Or simply made you say, "That shouldn't have happened."

Not sure what counts? Look for:

1. A stakeholder who disappeared after kickoff
2. A miscommunication between teams
3. A scope or data surprise mid-onboarding
4. A missed milestone that caught everyone off guard
5. A process step that always feels rushed, skipped, or unclear
   

Pro Tip: The more honest you are about what didn't work, the more valuable this session will be.

Agenda overview

0:00–0:10 - Set the Stage – Why We're Here

0:10–0:25 - DIVE Deep: Walkthrough of the Framework

0:25–0:45 - Group Activity: Map the Risk Web

0:45–1:00 - Identify the Assumptions

1:00–1:15 - Design Your Stopper Blocks

1:15–1:30 - Debrief, Commit, and Document

Facilitation script + Step-by-Step

‍1. Set the stage (10 min)

"Our goal today is to take a real, honest look at our onboarding process. Not just what's documented,but how it actually plays out. We're not here to point fingers—we're here to stop the dominos."

Facilitator Notes

1. Begin by sharing a brief personal story of when an onboarding went sideways
2. Set psychological safety - emphasize that this is about improvement, not blame
3. Explain that we're looking for patterns, not isolated incidents

‍Prompts for Discussion

1. Where have you seen onboarding go sideways recently?
2. What's a moment where you knew, "We're in trouble"—but it started small?
3. If you could wave a magic wand and fix one part of our onboarding process, what would it be?
   

Activity: Ask each participant to write down their "first domino" moment from their pre-work example on asticky note and place it on a shared board.

2. Walk through the DIVE method (15 min)

Quick recap

D = Discover assumptions and hidden risks

I = Investigate how those risks compound

V = Validate with real data or conversations

E = Engineer resilience through small, repeatable system changes
‍

Facilitator notes

1. For each step of DIVE, provide a real example from your organization
2. Connect each step to practical actions the team can take
3. Show sample outcomes (e.g., "This is what a validated assumption looks like")
   

Prompts for discussion

1. What's something we've assumed to be true in our onboarding process that we haven't confirmedlately?
2. Where in our journey are we operating on "I think" instead of "I know"?
3. Which part of our process has the most "it depends" answers?

Activity
‍Have the group brainstorm one example for each DIVE component based on their collectiveexperience:

1. One assumption they need to discover
2. One risk connection they need to investigate
3. One belief they need to validate
4. One process they need to engineer for resilience

3. Risk web activity (20 min)

Instructions

1. Choose one recent onboarding project from the pre-work examples
2. Draw one issue in the center (e.g., "Late kickoff")
3. Then draw out all the ways that impacted other parts of the onboarding
4. Look for loops: Where did one issue feed another?
   

Facilitator notes

1. Use a whiteboard or digital collaboration tool
2. Draw lines between connected issues
3. Circle areas where multiple issues connect (these are high-impact intervention points)
4. Look for places where small issues created disproportionate impacts
   

Prompts for discussion

1. What was the first domino in this project?
2. What consequences snuck up on us later?
3. Which dependencies caused the most downstream issues?
4. Where did we lack visibility into brewing problems?
   

Activity

Split into smaller groups if you have more than 8 participants. Each group maps one risk web, thenpresents their top 3 insights to the larger group.

4. Identify assumptions (15 min)

"Listen for phrases like: 'We usually…' 'They should…' 'I assume…' 'That's always…' Those are flags."

Facilitator notes

1. Distinguish between facts, expectations, and assumptions
2. Highlight how assumptions become "invisible" over time
3. Focus on high-impact assumptions (those that affect multiple steps)
   

Group reflection

1. Where do we have too much confidence and not enough confirmation?
2. What risks have we normalized as "just part of onboarding"?
3. What do we believe about our customers that might not be universally true?
4. Where are we assuming alignment that hasn't been explicitly confirmed?
   

Activity
‍Create an "Assumption Inventory" from the Risk Web:

1. List all assumptions identified in the activity
2. Rate each on a scale of 1-5 for:
   1. Confidence (how sure are we?)
   2. Impact (how much does it matter?)
   3. Validation ease (how easily can we confirm it?)
3. Circle the high-impact, low-confidence assumptions for immediate follow-up
   

5. Design stopper blocks (15 min)

Instructions

1. Now that we've spotted the dominos, how do we stop them?
2. What checkpoints, alignment calls, questions, or playbook updates could prevent this risk fromhappening again?
   

Facilitator notes

1. Focus on practical, realistic interventions
2. Distinguish between one-time fixes and systemic improvements
3. Consider both process changes and communication strategies
4. Remember: good stopper blocks are specific, measurable, and scalable
   

Prompts for discussion

1. Where could we validate earlier?
   
2. What moments could become standard checkpoints?
3. What's one stopper block we'll commit to adding this quarter?
4. How might we make validation a habit rather than an exception?
   

Activity
‍For each high-priority risk identified, design one concrete stopper block using this format:

1. Risk: [Describe the domino]
2. Current process: [What happens now]
3. Proposed stopper block: [New checkpoint or process]
4. Owner: [Who will implement]
5. Success measure: [How we'll know it worked]‍

6. Debrief and document (15 min)

Facilitator notes

1. Summarize key insights from each section
2. Focus on actionable takeaways
3. Assign clear ownership for follow-up items
4. Set expectations for how these insights will be integrated into existing processes
   

Group close-out prompts

1. What's one risk we'll never overlook again?
2. What's one process improvement we can make scalable today?
3. How do we make sure we never say "it depends" again without documenting the conditions?
4. What surprised you most about today's discussion?
   

Activity
‍Each participant commits to one concrete action they'll take in the next week to implement a stopperblock or validate an assumption.

Jasmine's rule: "If your process depends on the customer being easy, it's not a process—it's agamble."

What to do after the lunch & learn

1. Assign owners to finalize new stopper blocks or process changes
   
2. Add new insights to onboarding documentation or playbooks
3. Plan to revisit your risk web quarterly or after every major post-mortem
4. BONUS: Turn this into part of onboarding for new CSMs—teach risk from day one

30-day follow-up plan:

1. Week 1: Document all stopper blocks and distribute to the team
2. Week 2: Implement top 3 priority stopper blocks
3. Week 3: Validate top 5 assumptions identified
4. Week 4: Review early results and adjust as needed

‍Success metrics:

1. Reduction in "surprise" issues during onboarding
2. Decreased time spent on firefighting
3. Improved time-to-value for customers
4. More predictable onboarding timelines
5. Clearer handoffs between teams‍

Add-on resources

Domino risk mapping template

Instructions: Use this template to visually map how risks cascade through your onboarding process.Start with one trigger event and trace all possible impacts.
‍

How to use this template:

• Identify the trigger (First domino)
  1. Write a specific onboarding issue in the center circle
  2. Example: "Technical contact changed mid-implementation"
• Map first-order effects
  1. What immediately happens as a result?
  2. Draw these in the inner ring
  3. Example: "Knowledge transfer interrupted" or "Project timeline delayed"
• Map second-order effects
  1. What happens because of those first-order effects?
  2. Draw these in the middle ring
  3. Example: "Configuration decisions made without proper context"‍
• Map third-order effects
  1. What are the long-term or final impacts?
  2. Draw these in the outer ring
  3. Example: "User adoption issues after launch"
     

• Identify connection points
  1. Draw lines between related effects
  2. Highlight loops where effects feed back into each other
  3. Circle points where multiple effects converge (high-leverage intervention points)
• ‍Prioritize intervention points
  1. Mark places where a simple check or process could break the chain
     
  2. Focus on early-stage interventions that prevent multiple downstream effects
     

Stopper block opportunities

1. Require backup technical contact from day one
2. Create knowledge transfer checklist for contact transitions
3. Implement configuration review checkpoint after personnel changes
   

DIVE implementation checklist

D - Discover assumptions

Questions to ask:

• What are we assuming about the customer's:
  
• Technical environment?
• Team structure and availability?
• Decision-making process?
• Success metrics?
• Internal priorities?
  
• What parts of our process do we describe with "it depends"?
• Where do we have the least visibility during onboarding?
• What have we labeled as "one-off issues" more than once?
  

Actions to take:

• Review the last 3-5 onboardings for common friction points
• Ask team members to list their top 3 onboarding anxieties
• Identify steps with the most variance in time or quality
• Document all conditions behind "it depends" scenarios
  

I - Investigate connections

Questions to ask:

• Which step delays have the biggest ripple effects?
• Where do we see the same issue manifesting in different ways?
• Which teams or people are consistently impacted by upstream issues?
• What problems tend to cluster together?
  

Actions to take:

• Map dependencies between onboarding steps
• Identify which teams are affected by delays in each step
• Calculate the average impact (in days) of common delays
• Trace one major issue backward to find root causes
  

V - Validate with data

Questions to ask

• How do we know this assumption is true?
• What evidence contradicts our current belief?
• Who could confirm or deny this assumption?
• What would change if this assumption were false?
  

Actions to take

• Schedule validation conversations with key stakeholders
• Review data from your CRM or project management system
• Create simple yes/no validation questions for kickoff meetings
• Establish metrics to track assumption accuracy over time
  

E - Engineer resilience

Questions to ask

• What simple check would have caught this early?
• How can we make this validation automatic?
• What's the minimum viable process to prevent this issue?
• Who needs visibility they don't currently have?
  

Actions to take

• Design checkpoints at high-risk transition points
• Create fallback plans for common failure scenarios
• Build templatized questions for validation meetings
• Set up automatic alerts for key risk indicators‍

Assumption audit template

How to use this template

1. List all assumptions surfaced during your discussion
2. Rate each assumption on the three scales
3. Calculate the Risk Score (multiply the three ratings)
4. Prioritize validating assumptions with the highest scores
   

"It Depends" trigger words

When you hear these phrases, document the assumption:

1. "Usually..."
2. "Typically..."
3. "Most customers..."
4. "They should know..."
5. "That's just how it works..."
6. "I'm sure they'll..."
7. "That rarely happens..."
8. "We can figure it out later..."
9. "I think..."
10. "Hopefully..."
    

Validation methods:

1. Direct question: Ask the customer explicitly
2. Data analysis: Review past onboarding metrics
3. Process test: Run a small test of the process
4. Expert consultation: Check with subject matter experts
5. Documentation review: Check for written confirmation
6. Scenario planning: Test what happens if the assumption is false

Common high-risk assumptions to validate:

1. Customer stakeholders have internal alignment
2. Technical requirements are fully understood
3. The customer has allocated sufficient resources
4. Customer timeline expectations match reality
5. All necessary data is accessible and clean
6. The customer understands their responsibilities
7. Internal teams have capacity for the implementation
8. The scope is clear and agreed upon by all parties
   

Deep-dive question bank

Use these questions throughout your onboarding process to uncover hidden risks and validateassumptions. They're organized by onboarding phase to help you identify and address issues at the right time.

Pre-kickoff questions

Stakeholder mapping:

1. "Beyond the people in this meeting, who else needs to be involved for this project to succeed?"
2. "Who can say 'no' to this project who isn't in the room right now?"
3. "Who will be using the system day-to-day that we should hear from?"
4. "How are decisions typically made for projects like this at your organization?"
5. "What's the approval process for unexpected changes or scope adjustments?"
   

Success definition:

1. "If we were to meet a year from now, what would make you say this implementation wassuccessful?"
2. "How will this implementation be measured internally at your organization?"
3. "What concerns do your executives have about this project?"
4. "What previous implementation went really well, and why?"
5. "What's the one thing that absolutely cannot go wrong in this implementation?"
   

Resource reality check:

1. "What other major initiatives is your team working on during our implementation timeline?"
2. "How much time per week can each of your team members realistically dedicate to this project?"
3. "What's your process for prioritizing this project if competing priorities emerge?"
4. "What skills or knowledge gaps on your team are you concerned about?"
5. "How comfortable is your team with the pace we've outlined?"
   

Kickoff questions

Technical landscape:

1. "What systems will our solution need to integrate with?"
2. "Where do you anticipate potential technical complications?"
3. "What data quality issues have you encountered in past projects?"
4. "How standardized are your processes across departments/locations?"
5. "What technical constraints should we be aware of from the start?"

Timeline validation:

1. "What dates on our timeline align with other critical events at your company?"
2. "Which milestones feel most at risk based on your experience?"
3. "What would need to happen for us to accelerate any parts of this timeline?"
4. "Where should we build in extra buffer time based on your past implementations?"
5. "How quickly can your team typically turn around feedback or approvals?"

Risk anticipation:

1. "What's gone wrong in previous implementations that we should avoid?"
2. "What dependencies are you most concerned about?"
3. "Where do you think we're being too optimistic in our planning?"
4. "What's the biggest risk to this project's success from your perspective?"
5. "What assumptions are we making that we should validate right now?"

Mid-Implementation questions

Progress reality check:

1. "On a scale of 1-10, how confident are you that we'll meet our next milestone?"
2. "What's one thing that's working better than expected? What's one thing that's morechallenging?"
3. "What concerns aren't being discussed in our regular status meetings?"
4. "Where do you feel we need more clarity or documentation?"
5. "What's one thing we could change about our implementation approach right now?"

Stakeholder alignment:

1. "How are you communicating our progress to your leadership team?"
2. "What feedback are you hearing from stakeholders who aren't directly involved?"
3. "Has anything changed in your organizational priorities since we started?"
4. "Are all the right people still engaged at the level we need?"
5. "What competing priorities have emerged since we kicked off?"

Technical validation:

1. "What discoveries have you made about your data or systems that we should address?"
2. "Are our initial assumptions about integration points still accurate?"
3. "What parts of the configuration need more testing or validation?"
4. "Where are you seeing potential gaps between our solution and your requirements?"
5. "What technical decisions would you like to revisit?"

Pre-launch questions

Readiness assessment:

1. "What keeps you up at night about going live?"
2. "On a scale of 1-10, how prepared do your end users feel?"
3. "What would make you want to delay the launch?"
4. "What's your backup plan if something critical doesn't work at launch?"
5. "What metrics will you be watching most closely in the first week after launch?"

User preparation:

1. "How confident are you in your team's ability to use the new system on day one?"
2. "What resistance points have you identified among end users?"
3. "Where do you anticipate the most questions or support needs?"
4. "How prepared is your internal support team to handle initial issues?"
5. "What additional training or documentation would be valuable before we go live?"

Transition planning:

1. "How will you manage the transition from old to new systems?"
2. "What business processes need to change alongside this implementation?"
3. "Who will be your internal champions after launch?"
4. "What's your communication plan for announcing the change?"
5. "How will you gather and address feedback in the first 30 days?"

Post-launch questions

Success verification:

1. "What's working better than expected? What's more challenging?"
2. "Are you seeing the business outcomes you anticipated? Why or why not?"
3. "What feedback are you getting from your leadership team?"
4. "What metrics have improved since implementation? Which haven't?"
5. "What would you do differently if you could restart this implementation?"

Adoption assessment:

1. "Where are you seeing resistance or low adoption?"
2. "What workarounds are users creating instead of using the new system?"
3. "What feature gaps have users identified?"
4. "Which teams are having the most success with the new system? What are they doingdifferently?"
5. "What additional training or resources would improve adoption?"

Continuous improvement:

1. "What processes could we optimize now that the system is live?"
2. "What's the next area of opportunity you want to focus on?"
3. "What unexpected benefits have you discovered?"
4. "What documentation or training needs updating based on actual usage?"
5. "What would make this system even more valuable to your organization?"
   

Remember Jasmine's rule: "If your process depends on the customer being easy, it's not a process—it's a gamble."