SaaS implementations often don't get the attention they deserve though they lie at the core of successful customer onboarding. A dedicated team that handles implementations in a purposeful and mission-driven way can set your customers up for success. But how do you form an implementation team to suit your business’s needs?
In this Implementation Stories session, we talked to Jeff Kushmerek, founder of Jeff Kushmerek Consulting, who helps companies in different stages in stepping up their implementation teams. He shares his experiences building the implementation team from scratch at Virgin Pulse, his experience with his clients, and lessons on implementation processes and methodologies he learnt along the way. In this hour-long chat, Jeff focused on three areas:
In the rest of this article, we share the key takeaways from the session.
Before Jeff joined Virgin Pulse, deployments were on-premise (on customers’ servers), and the account management and sales teams managed all aspects of CS. As things became SaaS-based, he began to notice the divergence between the product feature set that customers needed and what the product offered. Bridging this gap by mapping the customer’s requirements to the product capabilities led to a CS function getting created, and Jeff believes that these are the skills a CS professional should possess.
When Jeff joined Virgin Pulse, the company was already mature in terms of revenue and employee count. However, the CS team was experiencing launch and churn issues. He spoke to everyone involved with customer processes in Sales, CS, and Support to identify the underlying issues.
Launching Virgin Pulse’s employee wellbeing solution for customers was a highly technical implementation. It needed the team to look at health data, fitness data, and how they would integrate into their systems. Since the platform needed to interact with employee health records, security and tech issues needed to be carefully handled.
The core problem, Jeff found, was that the CSM team was handling everything post-sale - except support tickets. They were in charge of launching customers, handling renewals, and configuring systems. There were other challenges too:
Most importantly, customers weren't happy because they were not launching on promised times and were not getting the attention they needed. Creating an implementation team seemed to be the smartest thing to do.
The model in place at the time when Jeff joined was having junior employees handle all configuration-related work. Jeff observed that this was a problem because junior resources alone couldn’t be relied on to have VP-level or SecOps/Dev-level conversations with enterprise customers.
Jeff’s hypothesis that a standalone team that handles only implementations could help solve this issue. This implementation team would run the configuration part of things and work with the CSM on the relationship strategy if needed.
Jeff set up this team starting with existing CSMs who wanted to move out of CS. These early team members had already handled CS but preferred the implementation aspects (over the relationship management aspect) of the role. The idea was to set up this team before hiring externally after about 6-8 months (the organization had to hire additional CSMs to fill gaps in the CS team to keep up with how fast the organization was growing).
In the early days, the team could not charge customers for implementation since the sales team wasn’t sure what it entailed and how to communicate this to customers.
Jeff analyzed all the tasks being carried out across different implementation projects and created a three-tier implementation fee system consisting of three segments - small, medium, and enterprise levels. This created an additional revenue stream since there was a mandatory implementation fee declared upfront.
Also, it was made clear that the implementation team wouldn’t charge a commission and that Sales would get theirs from the implementation base fee. In exchange, Sales involved the implementation team during pre-sales to talk about the product’s value, explain the implementation plan, and ask the right questions about the customers’ needs, current methods, and expectations. This made the kickoffs easier as the team understood the customer before sales. Additionally, interacting with customers helped the organization develop the right cost structure and negotiation contracts before Sales closed the deal.
Drawing from his 20-year-long experience with the pre-sales process, Jeff believes that setting up an implementation team to be commission-driven can make it less of a trusted advisor to the customer.
He recommends that the implementation team members come into the equation focused on answering the customer’s questions and solving their problems instead of approaching it from a commercial angle. Their focus should remain on understanding what the customer is trying to do, their requirements, their business processes, and mapping them to the product. Without commission, they can show their commitment to the customer and assure them that they’re driven by the need to make them successful. However, Jeff observed that having Presales engineers report to the PS department has been beneficial in ensuring seamless transitions between teams.
Jeff stresses the need to lock down the implementation dates within, say, a 90-day watch phase, and lay that out explicitly as a part of the contract that covers the duration, the cost, the number of the implementation team resources, and the time after which the customer would be transitioned over to the CS team. This builds more urgency as it sets clear expectations and gives the team some leverage for when customers show signs of ghosting.
Another critical aspect for the implementation team to keep in mind is the importance of demonstrating authority over the product and the implementation process to push the customer to make the right decisions.
As Virgin Pulse’s customers were growing 2x, implementation teams faced another problem. The team needed to scale, but simply multiplying the team’s strength made the team too big to manage. What helped was understanding exactly all the jobs the team needed to do and those that needed specialization. Jeff noticed that most implementation experts or ‘configurators’ were bogged down by status reports, chasing customers for updates and files, and project management. They solved this problem by hiring project managers to handle these aspects while the ‘specialists’ focused on the core implementation aspects.
This specialist-generalist approach helped because if there was a tool being used through the process to manage the implementation, the project resource needed to manage that and keep track of the project. At the same time, the specialists worked on core configuration or data or migration requests. These people were hired from across departments such that a CSM operated within a pod structure with specialists and generalists.
Jeff recommends bringing in project managers as one of the easiest ways to scale the implementation team quickly and effectively.
Jeff’s recommendations are to use CSMs who want to switch from managing customer relationships/accounts to handling implementation. However, since they are the first few people, they would need to do project management, configuration, and relationship management in the early stages.
Building people up from Support is a great idea since they understand the product well, as long as they possess customer-facing personas.
Jeff observed that implementation projects rarely need PMs with a PMP-style rigidity in their working style. There is a need for flexibility; the goal isn't to run the ‘best’ project but to get the customer launched successfully and happily. Jeff recommends looking out for a sense of empathy, flexibility, and a natural interest and ability to handle customers.
If the CS analytics is about business analysis and mapping customer needs as in a classic business analyst role, Jeff’s approach is to bring it within CS or Implementation.
Of late, however, thanks to pressures from VCs, there is a growing need for CS Ops to be locked in as well — to know how much money is in implementation, at what stage, KPIs, metrics, etc. For this, Jeff recommends starting with a Sales Ops person (as a shared resource with the sales team) but working towards having them within the team in six months to a year.
Jeff stresses the need to get Sales on board and to make sure the sales leader is on the pipeline call every week as part of ongoing training for the team. Some companies have measures to ensure that Sales teams can freeze the conversation only after implementation has been discussed and checked off. For instance, companies ensure that sales commissions are paid out only if the right order (having a call with the implementation team brought in, say 75% of the sales cycle mark) is followed. In some others, Sales Ops terms are designed such that order forms cannot be generated without having the implementation discussion checked off.
While this is heavily dependent on the product and how easy it is to onboard people, it is best to enable mid-market customers to onboard themselves while providing the option of paid CSM support to them. This allows the CSM team to be highly focused on enterprise customers.
Another approach that Jeff has observed is having partners for onboarding. This approach only works when there is enough work for them to continue to work on. Otherwise, there is the risk of them either forgetting how to do implementations or having to unlearn/relearn the implementation process due to the product’s changes. Jeff recommends guaranteeing the partner at least 40 hours of work a week to deploy resources accordingly.
Jeff has observed that companies in the $3M - $10M stage mostly have one person doing everything. Companies in the $10M range have too many customers to satisfy, and hiring CSMs to handle everything is not feasible. In such cases, Jeff recommends the approach of hiring specialists such as project managers, migration specialists, business analysts to save 50-70% of the cost.
From his experience, Jeff has seen that for simpler SaaS solutions, the system can be up and running in 30 days (implementation may even be completed in 14 days, but this timeframe accounts for customer education as well).
In cases where there are integrations, the timeline ranges from 30 to 90 days.
For solutions that take longer than 90 days, Jeff recommends making it a white-label solution. If there are too many customizations after the sale, the product no longer remains a true SaaS solution.
For companies in the revenue range of 77K ARR, Jeff recommends at least 10 to 15K as a mandatory implementation fee. Any lower, and customers don't value it as much. Jeff’s preference has always been a 3-tiered package that drives people towards the middle.