The rapid growth of SaaS has had some profound effects on customer service, but probably not in the way that you think.

The proliferation of SaaS applications we’ve seen over the last several years has paralleled a general trend toward an increase in specialization in the software world. This is due in part to the very nature of SaaS itself; because the product lifecycle of these firms demands rapid development, along with constant innovation and improvement, many firms have chosen to integrate third-party technologies into their products to save time and development costs. Classically, this has been referred to as “embedding.” Consequently, the number and variety of specialized “embeddable” products have grown quickly. 

So, given this trend, what happens when a customer finds a problem with their software? Well, as consumers, we’ve become used to dealing with it by searching support sites, going to forums, etc. But we’ve also become used to software that, increasingly, works as intended a very high percentage of the time. It was one of the great promises of cloud computing: “Everything will run in the browser, the system will be taken out of the picture.” Not only are things generally more reliable, but new features and improvements regularly appear, as competing vendors leveraging SaaS architectures vie for market share with “feature duels.” In short, our expectations as users have become quite high. These apps are now running our lives, and they’d better work

But what happens when something doesn’t?

In the SaaS situation I describe above, the customer isn’t the end-user, it’s the SaaS firm that embedded the third-party app. If a SaaS provider hears of a problem from their end-users, and it relates to a technology they’ve embedded, they rely on that upstream provider to respond quickly. Any delay in getting answers threatens their entire business. With so much on the line, it’s simply unacceptable to ask them to “refer to your documentation.” This urgency places a significant burden on the embedded provider. Because of the expectation of high availability, each one of those issues becomes much more critical for the embedded provider, affecting an entire base of users with whom they have no direct contact. The rapid product development cycle inherent in the SaaS sector also adds its own pressures. When a SaaS provider needs to innovate, they’ll often call upon their embedded partners to see what’s on their roadmaps. It’s very much a strategic relationship.

So how can embedded providers adapt to this? It’s not like in days past, when these integrations were complex and lengthy affairs, with multiple rounds of prototyping and testing prior to release. Today’s SaaS environment enjoys no such luxury; these firms must be able to integrate, test, and release products quickly. What’s more, “embedding” now encompasses a much more flexible type of integration, one that allows SaaS firms to leverage such technologies in a much wider variety of ways, potentially across multiple products or features. For our part, we’ve found that the nature of our platform – quite intentionally – is designed to address a broad array of operational functions, from visual analytics to system performance. For this reason, our customers constantly test the limits of our software, sometimes even in ways we (and probably they) didn’t fully anticipate. Because of this, we realized from the outset that to provide a level of service that meets the needs of SaaS providers, we had to establish an unusually close working relationship with them, one that essentially makes them trusted members of our own development team. In order to do this, we’ve taken the step of providing them immediate, direct access to our lead developers, not service techs. Each of them has unlimited access via Slack, Zoom, phone, and email.

And there has been a huge payoff for us.

First, because we’re communicating with developers, they’re able to bring a level of understanding and insight into areas of product improvement and evolution that can, and does, directly influence our roadmap. They’re able to communicate at the deepest level what they want to see, and often have brilliant suggestions about how it may be done. In this way, they are in fact, key members of our team, helping us stay competitive in a market that’s moving faster every day.

So, the next time you find yourself having a problem with a SaaS application,  know that behind the scenes, at least two groups of developers may be working together to solve it, and it may very well be the relationship they have with each other which makes all the difference in getting it fixed. 

For all of these reasons, today’s embedded providers have to step up their game when it comes to their relationship with their SaaS customers.

Popular Posts

multi-tenant analytics

Why is Multi-Tenant Analytics So Hard?

BLOG

Creating performant, secure, and scalable multi-tenant analytics requires overcoming steep engineering challenges that stretch the limits of...

What is Multi-Tenant Analytics >

How We Define Embedded Analytics

BLOG

Embedded analytics comes in many forms, but at Qrvey we focus exclusively on embedded analytics for SaaS applications. Discover the differences here...

What is Embedded Analytics >

embedded analytics for startups

White Labeling Your Analytics for Success

BLOG

When using third party analytics software you want it to blend in seamlessly to your application. Learn more on how and why this is important for user experience.

White Label Analytics >