Best practices for onboarding and implementation?

Ellisa Feinstein

I've worked in CS for 5+ years for SaaS startups, creating processes for onboarding and implementation. As I've looking to join non-SaaS companies, that are larger, would love to learn more what best practices in these areas have worked well for others in CS roles (or in "implementation manager" type roles). Thanks.

Melissa Logothetis

Having worked in both spaces I personally have not seen a difference in the onboarding and implementation. The biggest difference has always been the product itself. 

Scott Hopper

@Ellisa Feinsteinif we are talking on-premise, keep the products complexity in mind. 

Some of this based on complexity might be in the hands of a consulting team or a business partner.  In large server based architectures naming is an important consideration in how the architecture is implemented. So possibly more communication is necessary to understand the status of an initial deployment and onboarding process.   

More modern software distributions such as dockerized server deployments should ease the support burden.  A true rich client still will faces challenges to deploy across a large organization.  Be prepared that the support cycle tends to be longer of critical tickets.  

Vijaya Vardhan P

@Ellisa Feinstein I worked in a enterprise software on-prem company which pivoted to SaaS cloud over the last 2 years.

1. Customer Success is seen more as a "shiny new object" to make sure the renewal rates for the first cycle are high. The CS leadership is worried about their survival. So, it is all about product adoption and usage.
    
2. The back-end sales and account management process were not aligned to the CS teams during the first year. The CS leadership was "tasked" to get the retention numbers no matter what. The painful lessons were learnt in the second year. 
    
3. CS is more operational rather than customer centric, in a bigger company. I'm talking about customers whose min annual spend is $ 1 million and above. Each of these got a dedicated CSM, as part of the "deal". The CSM struggled to position themselves as a value add to customer.
    
4. There is no low touch. All the remaining are tech touch with CSM involvement on a case by case basis. 

As a Priority Support site leader, I saw all of these first hand because I helped set up the initial CS operations for the tech touch customers. We had a good overlap between tech support, CX and CS for these. I learnt a ton on how to operationalize the processes and set up metrics. What I did not get was the exposure to CS engagement with Sales/Pre-Sales early on where success criteria are defined. From what I have seen, that exposure is common in early stage SaaS companies. 

Ellisa Feinstein

Thanks Scott. It wounds like the CS org is not that involved with the implementation part of onboarding at large organizations b/c it's usually a lot more complex than at SaaS, which of course, makes sense. 

Scott Hopper

@Ellisa FeinsteinI think the typical take is you have visibility to the account and the "End of  the implementation"  If you have a more transparent company like GitLab they have in there "canned" implementation marketing documentation that the CSM will be introduced after the implementation. 

 

Things like DB companies, DevOps , Monitoring software are some examples of where there is likely separate implementation services.   If you have friends at Slack or MS Teams I'd be curious how they run their large implementations.   

Scott Hopper

I don't think that's so uncommon.  What evolved with the Lotus brand products at IBM.  Were initially extremely high touch.  Originally a Renew and Cost Recovery program.  Most were 1/3. time per customer. It morphed both ways to ultra high touch.  1 or multiple per account and a Global CSM concept  and  smaller accounts that paid for less time and services probably 5K users were smallest.  

Now there was certainly less outcome activity driven in the first 10 years of the program.  I will also say scalability wasn't resolved for several years and things that people take for granted in the cloud, like redundancy were not initially widely deployed.   

I don't know how long it was your product existed .  But it does take time to build relationships and for your product your customers might not in the first year of the program. It's also some of this gets slapped together.  I worked in a tightly coupled Field Support team for 3 years as there was a need for Emergency On-Site, but also a vision that the product was complex and customers needed 10 business days of Field Support to get them over challenges in the year.  

Certainly in the first few years I worked on that team there was both a problem of getting accounts to use their days and probably equally our team not be able to put together offerings that  the CSM understood or the customer wanted. 

 

 

Ellisa Feinstein

Thanks for sharing Vijaya.