For several years, I was part of the second wave of the SaaS promise. After Salesforce.com, the first widely successful software-as-a-service platform that became the guiding light of SaaS, several companies tried to transform themselves into a similar solution provider. When the transition was completed, my role at a leading spend management solutions company was to support accounts after the sale was consummated when
At the beginning of the transition from behind-firewall solutions to a on-demand environment, the deployments generated a lot of friction with clients. Among the problems:
1.- Clients didn’t really understand what the software was capable of doing on an on-demand basis. Clients assumed that customizations were simple and readily available. Changes are possible, but within constraints of a multi-tenant environment, although Coupa maybe changing that.
2.- Timelines specified in the SLAs were unrealistic, because they assumed the client clearly understood what they were looking for. Not the case by far.
3.- The promise of the solution was based on a product-based sales cycle, instead of showing how life was going to be for the end user. This created big disconnects between the management at the client, who purchased the solution, and the front line people who were supposed to “just get it” and start using it right away.
4.- Almost all training and documentation were related to the product itself, using terminology that some people calls “gobbledygook” using terms such as flexible, scalable, groundbreaking, industry-standard, cutting-edge and the likes. More on gobbledygook here.
So, the problems were basically people and process related. A solution that didn’t address the particular problems of the front line team was bound for failure from the beginning, not because the selected solution didn’t deliver, it was because the client was not prepared to absorb the extra workload needed to re-train their teams due to misplaced expectations. And expectations management is the role of the sales and marketing team, not the implementation ones.
Conversely, client companies didn’t perform well in their due diligence either. Very rarely I found companies that had a very clear understanding of what was needed, what are the limitations of a SaaS solution or effectively collected input from end-users.
In the last few years, my professional career was centered around making my management and clients happy after the sale. It was a role that verged on advanced diplomacy, in which I had to “twist” statements of work into workable task lists, reselling the entire solution to end-users who where not consulted, creating new processes so clients could make better use of the solutions, etc. That in turn created a big push back from my leadership who were surprised that so much of my consulting time was spent convincing people to deliver information and not implementing the solution itself. The big disconnect was between the promised solution and the actual delivered product, and my task was to make those two converge into a single successful implementation. And then, and only then, the promise of SaaS was fulfilled, but after much pain and bad blood.
