
•
•

Summarize blog with








In this session of Propel 22, Mikael Blaisdell, Executive Director, Customer Success Association, and Kristen Hayer, Founder & CEO of The Success League, shared their thoughts and insights on where customer onboarding should be placed within a company’s organizational chart.
They discussed:
Here are the takeaways from the session.
Earlier, CS and Support teams were introduced to the customer at the same time. Over time, this changed with CS being introduced much earlier—mostly at the beginning of onboarding. Today, companies introduce CS as early as the contract signing or prospect qualification stage, with support, training, and user-level QA falling under its ambit.
Today, onboarding has gone beyond merely getting the customer on the platform to ensuring customizations and change management.
Change management, though often ignored, should be a part of the CS or onboarding function.
In 2016, most companies believed that CS should not own revenue. However, in 2019, over 90% of Mikael’s clients have CS teams owning revenue.
Revenue and profitability can play a massive role in raising the status of the CS function within the organization.
In most cases, it makes sense for CS to own onboarding (with direct reporting to the CEO or the CRO).
However, early-stage companies could benefit from the product team handling onboarding (for product feedback), though in this case, the function should eventually transition over to CS. Additionally, it could be better to put it closer to tech teams for the occasional extremely complicated onboarding journeys.
Though companies are observed to have onboarding as part of their sales team’s responsibilities, this is primarily ineffective—except in cases where senior CS executive/s have peer sales executive/s within the sales function (as opposed to employee/s handling both functions).
Marketing, sales, and CS benefit from using centralized tools for handoffs. To ensure efficient handoffs, a manager should own the aspect of holding teams responsible for sharing information – such that ensuring timely updates and flow of data is linked to the team’s goals and reviewed as part of their performance.
Additionally, there’s a utilization issue with all the data that CRMs contain. CS Op teams can help review and analyze this data to identify gaps, issues, and areas for improvement.
Placing onboarding within CS ensures more efficient use of people – given the knowledge of customers, product, and domain expertise.
However, onboarding and CS have inherently different approaches; onboarding needs to be viewed with a short-term, time-bound lens, while CS focuses on a long-term relationship and growth-oriented approach.
One way to look at these functions within a team is to allow them to be feeder paths to each other. For instance, teams could set up a bench of junior resources –between onboarding and CS – for better control over staffing.
In businesses with a seasonality element, it can be helpful to enable employees to flow back and forth between CS and onboarding based on the timelines and demands of the customers.
Customer Success is yet to reach the resource utilization maturity that Professional Services currently possesses. CS teams need to sufficiently understand resource utilization (X customers = Y people in CS or onboarding) to predict staffing requirements.
Given the close communication and collaboration that onboarding demands, it may be helpful to handle/structure onboarding regionally (say in APAC regions) and take cultural and linguistic nuances into account.
However, this comes with the risk of teams working in silos. Focus on ensuring that:
What I appreciated most about Rocketlane is its seamless approach to onboarding and project management. The ability to collaborate in real-time, set clear timelines, and track progress across multiple teams makes it incredibly efficient. The built-in document-sharing and communication tools reduce the need to switch between platforms. It’s especially useful for client-facing projects, where transparency and accountability are key


AI that executes your delivery work (Add to any plan)
Most popular
Ideal for expanding organizations needing more in-depth capabilities and integration for scaling.
Most popular
Great for teams desiring tailored workflows with comprehensive reporting capabilities.
Most popular
Tailored for large enterprises requiring a fully customizable, comprehensive delivery engine.
A Forward Deployed Engineer (FDE) embeds in the customer environment to implement, customize, and operationalize complex products. They unblock integrations, fix data issues, adapt workflows, and bridge engineering gaps — accelerating onboarding, adoption, and customer value far beyond traditional post-sales roles.

A Forward Deployed Engineer (FDE) embeds in the customer environment to implement, customize, and operationalize complex products. They unblock integrations, fix data issues, adapt workflows, and bridge engineering gaps — accelerating onboarding, adoption, and customer value far beyond traditional post-sales roles.





70–85% utilization. 94% G2 rating.
One platform does what the entire table above tries
to split across tools.
70–85% utilization. 94% G2 rating.
One platform does what the entire table above tries
to split across tools.

70–85% utilization. 94% G2 rating.
One platform does what the entire table above tries
to split across tools.
Enterprise implementations fail because customers don’t follow the process or provide clean data on time. Most delays are purely “customer-side” issues.
Implementations fail because complex environments need real-time technical problem-solving. FDEs unblock workflows, integrations, and unknown constraints that traditional onboarding teams can’t resolve on their own.
Get a better all-in-one PSA
Get a better all-in-one PSA
Companies that embed engineers directly with customers see significantly higher enterprise retention compared to traditional post-sales models — because embedded engineers uncover “unknowns” that never surface in ticket queues.

VP Sales, Intercom

A Forward Deployed Engineer (FDE) embeds in the customer environment to implement, customize, and operationalize complex products. They unblock integrations, fix data issues, adapt workflows, and bridge engineering gaps — accelerating onboarding, adoption, and customer value far beyond traditional post-sales roles.






.webp)