top of page
Search
Writer's pictureAdmin

Wayback Machine: SaaS Before Customer Success Existed

Way back in 2006/2007 I had the pleasure to work with a team of folks from the PSVillage community on a book of professional services best practices.


Having worked with emerging cloud application solutions starting in the early days (2003-ish), as "thin client" and "hosted" transitioned to Software-as-a-Service, I'd seen a few iterations of common problems. So I decided to focus my chapters on PS in SaaS. This was before the term "customer success" existed. We were still "pro serv", "support", "client services", "consulting", "training", "managed services", and "customer operations" at times. Getting customers up and running with, confident in the use of, and receiving value from the nascent cloud applications sometimes rolled up to one leader, but most often did not.

I thought it would be interesting to revisit those thoughts here, 15+ years later, and see if they still apply. Are they relevant today, and have they been solved, or simply replaced with more sophisticated issues as we continuously progress?


Those chapters from the book follow below.


Sell and Deliver What You Have

Takeaway: In some cases, back in the day, sales opportunities were closed with product features that had not been completed yet. Which, while painful in the on-premise application world, could be disastrous in SaaS.

Is it still relevant: My experiences have been, this is largely resolved. Companies I have worked with recently have been very good about not selling "futures". With startups, there may be some reprioritizing of releases to assist an opportunity.

Did we solve it: Yes!


saas implementation considerations customer success



Don't Sell Your Projects Short

Takeaway: Early SaaS seemed to promote a myth that implementations would be short and easy. In reality they were often not - requiring solid project and change management, dependent upon solution complexity.

Is it still relevant: My experience is that it is still very relevant. Especially around customer change management efforts needed to successfully implement and adopt even moderately complex B2B SaaS solutions.

Did we solve it: No!!! Some companies have, but I feel it still exists as a major issue for adoption, time-to-first-value, and customer satisfaction.




Implications of Using the SaaS Model

Takeaway: SaaS increases responsibilities for the customer-facing teams, with overlap that includes traditional product, IT, account management, and operations tasks. Team charters and responsibilities may not be clear.

Is it still relevant: Yes. "Customer Success" and "Customer Experience" are the new orgs that encompass this larger scope, but I see disagreements about org charters come up frequently still. Recently I heard a CS leader comment that they were doing ETL tasks for live customers that they felt were a bandaid for product and infrastructure shortcomings.

Did we solve it: No - but it is a work in progress with CS and CX evolution. Healthy, professional, and respectful conflict/discussion needs to be part of the company culture to resolve the gray areas.





Internal Coordination is Key

Takeaway: In SaaS companies every org contributes to "customer success" in some way. Goals should align.

Is it still relevant: Yes. My experience is that internal collaboration is still very key to SaaS, and still hard to do.

Did we solve it: No - but we've gotten better about org design, strategies, shared goals, and metrics that enable it. I still see frequent discussions such as "who owns renewals" that indicate there is a lot of conversation to be had in this area. Also, I feel "ability to collaborate with your peers" needs greater focus as a requirement for SaaS department leaders. See the above chapter with respect to healthy conflict.



So how have we done? Solving one out of the four is not bad! Customer success communities have come a long way to help build institutional knowledge regarding many of the continuously improving (sounds better than "unresolved") points above. In the least, we have developed a common language to discuss approaches, even if their implementation is often company and solution dependent. There is no "one size fits all" in CS/CX orgs, metrics, motions, etc., so the need to collaborate to find what works for your company and solution will likely always exist. CS Ops teams play a key role in this.


Thanks for reading. I'd be interested in your thoughts in the comments regarding lingering opportunities for improvement in the CS world!


bottom of page