Customer Success - What It's Not

Sometimes it's easier to wrap your brain around an idea by first defining what it's not; kind of like picking the right answer on a multiple choice test by eliminating the bad choice first.  Sound like fun? Let's give it a go.  For your edification, some examples of what customer success is not:

• Pipeline Management:  The idea here is to follow the classic sales funnel (aka the image below) by driving the customers up for renewals in the next quarter through that process.  The problem?  Most customers decide whether or not to renew long before the SaaS provider starts this process.  So this approach?  Not customer success.

• Project Management:  A great model to follow while a new customer is on boarding or while an existing customer onboard new applications or functionality.  But the Project Manager approach fails to address the subsequent crucial nurturing cycle that takes place after Onboarding.  That's not customer success.
• Customer Support:  The support approach, in practice, deals mostly with resolving escalations: "the customer is unhappy", "the customer has threatened to cancel", you know...all the unhappy situations where providers jump through flaming hoops to make a disgruntled customer happy again.  Activity is triggered by the escalation, and that activity is usually expensive.  In customer success, the idea is to be proactive and make an impact before the customer goes down the path of disgruntlement.  So Customer Support does not equal Customer Success by any means.

Note here that our discussion of what customer success is not has been focused on outcomes: renewals, onboardng, escalation resolution.  None fit.  So what's my suggestion?  Focus on the drivers during the onboarding and nurturing stages that provide your desired outcomes by influence.  That's right, manage a portfolio of drivers in order to add value through a customer success approach.  What drivers?  

Well, kids, it's Friday as I write this.  And T-Bone Walker taught us all that "the eagle flies on Friday" (Google up a tune called "Stormy Monday" for more details on that).  My eagle is set to fly. The next post will be about drivers...probably on Monday.  Y'all have a good weekend.

Defining Customer Success

Since I've started this new blog, people have noticed that I've picked up a real focus on customer success.  Some have even implied that it's the only subject I'll be writing about.  Seems those folks don't know me very well...I'll be writing about a wide variety of topics relating to enterprise software.  It's just that I've been deeply involved lately in SaaS Customer Success matters and I've learned a ton.  That's what bloggers do: we learn about something that is new and exciting and useful, then we share that learning with others by writing about it.  That's what I'm doing here.

On to the second thread of feedback I've been hearing:  define this SaaS Customer Success thing.  We've all heard about it, we know it's important, but we struggle to clearly define it.  OK, let's tackle it right now.

I actually go with two different definitions.  Because your definition of customer success in the SaaS world depends on your perspective:  are you a SaaS customer or a SaaS provider?

In providing a definition from the customer perspective, I'm spinning off a definition provided by SaaS Customer Success guru Lincoln Murphy:  customer success is the achievement of your desired outcome(s) through interactions with your SaaS provider.

• Achievement of your desired outcome(s) - did you get what you expected to get? Are things better than when you started your SaaS journey?
• Interactions with your SaaS provider covers all the interaction touch points:  market and sales, onboarding, nurturing...did it all work together to make things better as quickly and inexpensively as possible?  

So, you may ask, what is Floyd thinking with this latter portion of the definition?  I'm thinking that when we talk about Software-as-a-Service, we place a huge emphasis on the service - if it was just about the software, we'd call it Software-as-a-Software...and that doesn't make any sense at all, now does it?

From a provider perspective, the definition is a bit more quantitative than the qualitative definition customers use.  It's all about maximizing customer lifetime value:  CLV=APA/Customer Churn Rate

• CLV = Customer Lifetime Value
• ARPA = Average Revenue Per Account (Monthly)
• Customer Churn Rate = The Monthly Percentage of Customers Cancelling or Failing to Renew

Think about this formula for a minute and you'll realize the huge influence of the "interactions" portion of the customer definition on CLV.  So both customers while emphasize the importance of service interactions, SaaS providers are incentivized to optimize those interactions.

So now that I'm up to my eyeballs in the work of a Center of Excellence for Customer Success, what's my personal bottom line?  It's in creating more value more quickly for both the customer and the provider.  That's a tough nut to crack.  We'll talk about it in a subsequent post.

Needless to say, your feedback is always welcome.  Get intimate with the comments.

SaaS - The High Road and The Low Road

O ye'll tak' the high road, and I'll tak' the low road,
And I'll be in Scotland afore ye
              - From "The Bonnie Banks of Loch Lomond"

So we just talked about the lifecycle in SaaS.  While we can see that it's more than a little different from what we've seen in the past, it's also a bit tough to match those lifecycle states to the types of activities SaaS service providers (both software vendors and partners) and customers.  One group  must 'take the high road while the other must 'tak the low road...two paths to the desired end results. With that challenge in mind, I offer up the following for your consideration:

Customer Activities play out like this:

• New:  A newly signed customer.  The important goal here is to gain user acceptance by winning hearts and minds.  The best tactic here is to get to "first valuable use" (aka "a big win") as quickly, easily and inexpensively as possible.
• Growing:  Customers want to be here most of the time.  If customers achieve their desired results, this is when it happens.  We're also looking for growth in value through an increase in engagement:  more users, more transactions, more use of features, subscription to additional products.
• Renewal:  A very short activity in which the customer (hopefully) opts to renew subscriptions and jump right back into the growth phases.
• Cancelled:  If the New or Growing phases have not been good experiences, customers will terminate subscriptions and move to another solution.  One of the benefits of SaaS for customers - doing this is easy in comparison to the historical effort of switching platforms, because there is no tech stack to transition.

In parallel to each phase of Customer Activities, Service Provider activities play out like this:

• Integrate Services:  This includes everything the Service Provider does to get a customer from "New" to that first valuable use.  Creating and provisioning instances, implementation, initial training, and whatever else is done to get the new customer's subscribed services up, running, and adding initial value.
• Tending:  Much like parenting a newborn child, the work does not end when the baby is delivered.  You tend to that child:  feeding, changing, socializing, managing health and development... It's much the same with SaaS customer.  You're continually working to develop value: new use cases, new capabilities, post-implementation training, and so on.  The quality and volume of the Tending effort here is directly related to whether customer accounts head to Realization or Churn.
• Harvesting:  This is when the Service Provider reaps the results of their efforts in Integrate Services and Tending.  If it went well, we'll see customers renew their subscriptions.  We'll also see opportunities to upsell (expansion to existing service subscriptions) and cross-sell (new services for existing customers).  But if Integrate Services and Tending did not meet expectations, we move into...
• Saving: Work done to address issues that may lead to customer cancellation.  This is always bad news, but the real bad news is this:  across the SaaS industry, we have yet to be able to consistently save projects that have gone off the rails during the Integrate Services or Tending phases.  To a very great degree, there is no saving the soup once it's turned bitter.

So the big takeaway here?  SaaS customers and service providers take different paths and engage in different activities to wind up together in the same happy Realization zone...it works better when each  knows how the other gets there.  And it's also important to realize (and this is a hint for the next post) that creating customer success is an exercise in portfolio management - it's not a traditional pipeline management effort.

Comments?  You know where we keep 'em.

Stealing Ideas

"It's not where you take things from - it's where you take them to."
                         - Jean-Luc Godard

In my role with Oracle's Cloud HCM Center of Excellence for Customer Success, I'll freely admit that I'm stealing things from others. One of my favorite sources of Customer Success ideas comes from Totango.  A pretty creative bunch of folks there...they worked through a model for SaaS customer success and then built SaaS applications based on that model.  Guy Nirpaz, the founder of Totango, recently released a book literally giving away the model and how it works - Farm Don't Hunt:  The Definitive Guide to Customer Success.  Great read for anyone in the SaaS business.  The following represents my own point of view on Mr. Nirpaz's ideas....credit where credit is due.

I've written recently about the calories I've burned on figuring out customer success.  Well, I'm still burning those calories...lately around figuring out the SaaS customer lifecycle from a customer success point of view.  I think it looks something like this:

Onboarding:  something is new.  New customer, new application, new feature(s), new users.  The key idea here is that SaaS customers/users have yet to derive value from the product or service.  The most important thing here is to get that customer to first use (or first value) as quickly and easily as possible.

Nurturing: all parties are attempting to develop the new thing in order to lay the foundation for growth.  Training, new use cases, advising, and whatever else you can think of here.  The idea is to promote acceptance and growth through engagement and adoption.

Realization:  when nurturing goes well, users see realize the value they hoped for when they subscribed and onboard.  Things for the customers/users are going better, faster, cheaper, or some combination thereof.  Partners see stronger relationships and additional work opportunities from those customers/users.  SaaS vendors see more use of subscribed seats by customers/users, higher levels of use for subscribed features, and customer user growth: more features, more user seats, additional applications.  Of course, all growth drives everyone through another cycle of on boarding, nurturing and realization.

Churn:  this is an ambiguous term for all the things we don't like to talk about:  escalations due to issues with the service or product, or *gasp* cancellation of subscriptions.  While we all try for saves when experiencing churn, industry statistics for SaaS indicate that we're not very good at it.  Prevention is the best means to dealing with churn.

Next up we'll talk a bit more about what all this means.  But at this point, we're just stealing ideas to establish a framework for talking about this stuff.  

Thoughts? You know what to do...

Customer Success - Three Little Birds

Rise up this mornin'

Smiled with the risin' sun
Three little birds
Pitch by my doorstep
Singin' sweet songs
Of melodies pure and true
Saying', ("This is my message to you")

Singing' "Don't worry 'bout a thing
'Cause every little thing gonna be alright."
Singing' "Don't worry (don't worry) 'bout a thing
'Cause every little thing gonna be alright!"

               - From Bob Marley's "Three Little Birds"

Having been at this enterprise software game for awhile now, I've gotten fairly good at looking at trends and describing what happened (I'm good at spotting developing trends as well, but my track record at predicting the timing of results is weak sauce at best).  Over the past decade, I've seen the shift in customer relationships.  Success for any enterprise software provider is no longer about making the sale...it's about customer relationships that lead to customer success.  Granted that sounds a bit like sales and marketing fluff, so let me share three little birds of change to drive home my point:

1. We've gone from a software licensing model to recurring revenue model baed on software subscriptions (SaaS, PaaS, DaaS, or whatever _aaS you like).  The seller does not get paid up front as in a software license deal, so the pattern of customer relationships has shifted from an all-out, one-off effort to score the big deal to one of more consistent investment in helping customers achieve desired outcomes - which, in turn, keeps the subscription revenue flowing.
2. Everything has a digital component supporting real time data streams.  This is the big promise of the "Internet of Things".  It's all about providing value via services while the customer uses the products.  And it's made possible because products are digitally tied together.  GM knows when my car has low tire pressure and sends an alert to my dashboard.  DaaS vendors know when my subscribed database hits 85 percent of storage capacity, so they can offer more storage before I hit the limit.  My neighbors know when their children wander out of a certain physical area because they get an alert on their cell phones...including the location of the child when the alert was sent.  Everything is connected or soon will be.
3. Customers expect more.  They've seen what highly-responsive consumer software can do: Google, Facebook, Snap Chat, Amazon, LinkedIn, Evernote.  And that's now the expectation of enterprise software products.  And to take it even further, cloud and SaaS enterprise applications make it easier than ever to simply click in order to try the next thing.

Faced with the combined impact of these three changes, enterprise software vendors can no longer focus on the one-time license sale by emphasizing a technical platform, or breadth of features, or even ease of use.  To win and keep a customer's business, we have to focus on helping that customer achieve and maintain desired outcomes.  That's the upshot of customer success.  And customer success is the gist of succeeding in enterprise software.

One last thought.  Customer success is a relatively new thing.  Vendors and customers alike are still learning how it works and how to use it.  And that's why you need a Center of Excellence for customer success.  More on this later, but comments are welcome now.

Testing - Make Sure It's Right

We've seen lots of brain power expended over the past several decades on the subject of software testing. Static, dynamic, white box, black box, gray box, API, code coverage, fault injection, mutation (yeah, really...you can't make this stuff up!), equivalence partitioning, value analysis, fuzz testing (my personal favorite, as I keep hoping that working with fuzz will resurrect my hairline), use case, unit, integration, system, acceptance.  Not nearly an all-inclusive list, but you get the point.

As for me, my approach to testing is really, really simple:  does product and/or service work the way we expect it to work?

Despite my simplistic approach, I'm also a big believer in testing.  You absolutely, positively have to do it and do it well.  Make sure, beyond any shadow of a doubt, that software works as expected before sharing it with your users.  May I offer a somewhat related experience here?  Granted, my experience consists of first-world problems.  But if you can look past that, you'll see why this relates.

Last week, while I was out of town, the dishwasher began to act up.  At the same, we were having some problems with a back flow regulator for the sprinkling system in our front yard.  My wife called in a plumber for the dishwasher, who assured her he could handle the back flow regulator too.  Killing two birds with one stone seemed pretty efficient, so she went with that.  Said plumber was wrapping off just as I returned home from the trip.

A few hours after the plumber's departure, I fired up the dishwasher.  Didn't work.  Some relatively embarrassing language flew out of my mouth.  And I hunkered down with the assistance of talented son Brian to fix the dishwasher.  Long story made short, Mr. Plumber failed to turn on the water feed to the dishwasher after completing his work.  In addition, Mr. Plumber failed to reset the electronic controls for the dishwasher after interrupting electrical power to the dishwasher (SIDE NOTE:  each and every dishwasher in the US has the service manual in a plastic bag just behind the interior faceplate on the front door...including all the reset codes, of which there are usually three).  The bottom line is that Mr. Plumber did not check his work or conduct any testing after completing his work.

Given the dishwasher fiasco, I immediately became curious about the back flow regulator.  So I walked outside to turn on the watering system.  Sure enough, water shooting straight up into the air.  Mr. Plumber failed to open one of the plug valves in the regulator after completing his work.  Painfully obvious he did not check his work.

After a rather vigorous three-party discussion between my credit card company, Mr. Plumber and me, you can rest assured that Mr. Plumber has not been paid, has lost a customer, and has really bad reviews on social media (including the Better Business Bureau) intended to save others from this experience and chip away at Mr. Plumber's business reputation.

Mr. Plumber expended time and materials, but did not get paid.  In addition, Mr. Plumber lost a customer.  Even worse, Mr. Plumber's reputation has taken serious damage.  Why?  Because Mr. Plumber failed to test.  Don't be like Mr. Plumber.  Make sure your product and/or service (enterprise software) works the way you expect it to work.  Test - make sure it's right.

First Use - Get It Right Or Go Home

First time use is my ultimate go/no-go test for a mobile app.  And I admittedly have a low tolerance for issue or failures:  zero tolerance.

The first time I try a mobile app on my phone I expect it to install quickly, load quickly, be easy for me to use, and work as advertised.  Zero tolerance for speed bumps, poor UI, failure to meet expectations, etc.  I immediately delete any app that fails to meet these standards right off the bat.

I recently tried the Bizzcard iPhone app.  Seemed pretty cool...it only does one thing, which is to send a digital copy of your business card.  The app claims the ability to import a pic of your business card for use.  I tried it:  the image size taken by my iPhone camera is too big for the Bizzcard app.  Gone.  Deleted.  Might be a workaround or a fix.  Don't care.  It didn't may the cut at first use.  Don't have the time or the willpower to fuss with it.

Ditto for Photoshop for the iPhone.  The process for linking my existing Adobe Creative Suite account to the iPhone app was too hard.  Too much manual input.  The mobile app wouldn't accept the login info from the web account.  Gone.  Deleted.  Fail.

I don't think I'm alone in this...the Low Tolerance club membership has been growing over the past few years.  And I don't think it only applies to mobile apps.

I had a recent discussion with a customer who just killed a SaaS project and went back to their legacy ERP applications.  You'll love this.  Their provisioning went well, their partner brought up a conference room pilot in days, and set down the customers team of super users in front of the app.  Question 1:  "How does this work?"  Answer:  "We'll conduct a half-day class to teach you navigation."  The questioner immediately got up and left the meeting without another word...walked by to her office and called the company lawyers:  "Terminate the subscription and partner contract - today.  We're done."  She is VP of Finance.  Her reasoning:  "A four-hour training class on basic navigation tells me the app isn't ready for our culture of zero patience for unnecessary difficulty.  They can come back and try again when they're ready.  In the meantime, we don't have time for that nonsense."  Well-known company, good mid-size SaaS vendor, strong partner.  Gone. Deleted.  Card-carrying member of the Low Tolerance Club.

BTW, this particular story?  Not an isolated incident by any stretch of the imagination.  In today's marketplace, software users have high expectations and low tolerances when it comes to the first use experience.  Get it right and you have a customer; blow it and you're irrevocably out the door...recovery not likely.  

First use...it's the key to customer adoption.  How do you handle it?  Feel free to share with the class if you have something that works...

The Center of Excellence Discussion

Lately, I've had lots of conversations like the following:

"How is the new job?"

"Love it!"

"What is it you're doing?"

"Working in the HCM Cloud Center of Excellence."

"What's that?"

"We help customers have great experiences with HCM Cloud Applications."

"How do you do that?"

"We solve the challenges nobody else can solve."

"So you're a customer support group?"

"More than that.  We also provide tools, white papers and best practices."

"Still sounds like support to me."

"We're more proactive; not just reactive with challenges as they arise, but also anticipating before the challenges arise."

"Oh, so like proactive support?"

"Sigh.  Different from support...as much as I admire the work those people do, this is different.  Let me try again..."

What I do is sometimes a tough thing to put into words.  In fact, I've had trouble wrapping my own brain around what a Center of Excellence does.  There are elements of work typically done by a development organization, a program management office, a customer support organization, a consulting organization, an engineering design organization, an account management organization, and a sales organization...all rolled up into one big ball of wax.

But I think I've worked it out.  Our particular Center of Excellence focuses on the journey of customers subscribing to HCM Cloud applications (i.e., HCM SaaS applications).  Now, before you say "journey of customers...just another swell catch phrase...pure fluff", let me lay it out.

In our Center of Excellence, we focus on the touch points and interactions with customers that come after the point of sale.  That includes working with those customers as they actually configure, use, and get help with our product offering...and in the world of SaaS, that service includes both the software and the services associated with that software.  And doing so requires a pretty wide breadth of expertise:  functional, technical, business process, reporting and BI, UI Design, etc.  We could be trouble-shooting, guiding customers and partners through various features or processes (including the processes involved in working with Oracle).  We can also be involved with strategic, proactive, and reactive challenges.

To boil it all down into it's simplest terms:  we focus on making the post-sale customer journey better for HCM Cloud customers in any way we can.  That's my quick definition of what we do.  And I'm sticking with it until I hear something better...like maybe from you in the comments.

Adopting SaaS

The working model I'm currently using for the SaaS Customer Adoption Lifecycle looks something like this:

Frankly, I saw this somewhere online and played with it for a bit.  Seems to work pretty well, so I'm using it with gratitude to the unrecalled author.

Note that most of the risk in this model appears early in the game.  Also note that there is no recovery path once the customer's SaaS experience goes off the rails.  The lack of any recovery path is one of the reasons why account churn (customers dumping one SaaS vendor for another) is so prevalent


So my thinking is that SaaS vendors should be focusing on making the transition from "Start" (which is really the moment a customer decides to subscribe) to "First Use" (the first use by customer users...not people on the implementation team) as quick and easy as possible.

That's really a critical component for success with SaaS, whether you are a vendor, implementation partner, or customer:  make that path from "Start" to "First Use" in fastest and cheapest manner possible, while still providing users with the best possible overall experience at the time of "First Use."  Fast, inexpensive and high quality...that's a tough balance to strike.  How are you doing it?  Share in the comments.

Pickin' Up The Pieces

Well, there's just a little bit of magic
In the country music we're singin', so let's begin
We're bringin' you back down home where the folks are happy
Sittin' pickin' and grinnin', casually, you and me
We'll pick up the pieces, uh-huh
                       - From Poco's "Pickin' Up The Pieces"

So here we go, kicking off a new blog.  My hope here is to drive discussions exploring the various pieces of enterprise software and how they fit together to complete the enterprise software puzzle.  This blog will be a bit like it's predecessor, ORCLville, but won't be so focused on specific products or platforms.  We'll dealing with issues and ideas across a wider base.


The Enterprise Software puzzle has a pretty wide range when it comes to types of pieces we'll be pickin' up:  applications, Anything_as_a_Service, mobile, business processes, user experience design, practice standards, user acceptance, project management, enterprise industry software observations...all fair game here.

And for those of you who want more Oracle-centric thoughts to chew on, I plan to make regular contributions to the Oracle Fusion HCM Center of Excellence blog...much like what we all used to discuss on ORCLville.

OK, enough of the introduction.  Time to write something somebody will care enough to read...and maybe even comment about.  You'll get the idea as things evolve.