The Need For Speed

In the world of SaaS enterprise applications, starting a successful implementation project is all about the need for speed.  Customers have subscribed and are itching to work with the software.  Implementation partners want to quickly take that next step the change management process, which requires the customer getting familiar with the software.  

So setting your fledgling project on the road to success depends on getting an instance up quickly (among other things).  Call it "Conference Room Pilot 1" or a "sandbox" or "the staging instance" or whatever else you like, it's important to get an instance up as quickly as possible.  In all honesty, it does not need to be populated with customer data, customer configurations, nor customer business processes.  In fact, it is usually better to put up a very plain "vanilla" instance and encourage the customer to try out the business processes baked into the software in order to limit or eliminate customizations later in the project.

An important early step in the sprint from subscription to first valuable use...get an instance up as quickly as possible.   Embrace the need for speed.

Self-Service vs No Service

Self-service is a huge trend in enterprise software.  The basic idea is that, rather than expending the service provider's resources on simple matters, simply enable your customers to handle the matter on their own.

The idea did not start in enterprise software.  Think of self-service gasoline stations, buffet-style dining, loading items into your shopping cart at Trader Joe's; all examples of self-service.

Done well, self-service raises customer satisfaction while decreasing provider costs.  I'm a long-term fan of Expensify - a product that optimizes the experience of self-service expense reports.  They are an example of self-service done well.  Done poorly, customer satisfaction plummets to the point that customer loyalty is vaporized in an explosion of frustration.  Think of the virtual receptionist used with most customer support telephone lines...one wonders whether the idea is for the customer to help themselves or simply keep them in a a vortex of navigation options until they simple give up and hang up.  That's done poorly.

There is simply no better or quickly way to destroy customer loyalty to a product or service than to route communications with that customer through a service hub with an automated attendant. It's a strong message to customers that a service or product  provider does not care about you, your issue, or your feelings regarding the experience of using the product or service. "Thanks for buying...hope all goes well, we're outta here"!  No service.  I'm always a little taken aback when I see it.  And I see it more frequently these days.

Some self-service is good. For example, I prefer to write my own trouble tickets - I can be much more precise about my issue when writing it up myself as opposed to explaining things to an analyst.  But the follow-up should be someone reaching out to work my issue.  When Step 2 consists of automated self-help suggestions, I know I'm in for a frustrating experience because we've crossed the line into the realm of no service.  (it's like taking my iPhone to the Genius Bar and hearing the phrase "As it turns out..." - it's a guaranteed sign that frustration will follow).

Customer service still matters.  Want to keep your customers...and even make those customers advocates for your product or service?  Take care of them after they buy.  But don't make that transition into no service...unless you're ready to shrink your customer base.

I Love It When A Plan Comes Together

I love it when a plan comes together.
                    - John "Hannibal" Smith

So I had a really cool conversation with a long-time friend over the weekend.  The friend is CFO at a Fortune 2000 company…I won’t call him out here for privacy’s sake, but you would recognize the company name.

Anyway, friend was telling me their story in going to SaaS.  It’s worked out very, very well based on some decisions made early in the process.  We burnt the midnight oil together working through some of those decisions, so it’s always gratifying to hear that they worked out.  I thought I’d share a few here in the hopes it might help somebody reading this…

1. They knew what they wanted going in…much more specifically than simply “transforming the business”.  The desired end states were: a) an improvement in the speed of responding to market-driven changes, and b) a substantial reduction in IT operating expenses.  That’s it.
2. Their approach throughout the project was a strict application of Occam’s Razor:  the solution requiring the fewest assumptions was the right one.  They were passionate about keeping things simple.
3. Another thing this company was very passionate about:  letting go.  Very little data was converted to the new SaaS system.  They started with opening financial balances and historical queryable flat files from their legacy system.  They took a similar approach with their HR records.  Saved huge amounts of money and time in switching to SaaS.
4. More on the letting go thing:  they let go of all their old business processes, opting to use those baked into their SaaS applications suite.  At their first Conference Room Pilot, they came out with an 80 percent fit.  With careful planning and tailoring, they increased that fit to 90 percent by CRP 2.  The last ten percent?  Some of it they decided they didn’t need and some of it wound up on a small, on-prem server integrated with their SaaS apps…mostly at the reporting/BI level.

So the end results?  

First, I should mention that it took this particular company four months to implement and cut over; it could have been quicker, but they invested about one-third of the project effort in “kicking the tires” before going live.  Brilliant...and definitely not my idea.  The testing effort turn out to be a huge help with user adoption within the company.  

Second, they have reduced their IT operating costs.  According to the CFO, IT operating expenses dropped by over 60 percent, mostly due to eliminating the need to maintain their in-house applications suite.  Although my friend also cynically notes that most of the savings from software licensing and support fees was consumed by SaaS subscription fees: “all the SaaS vendors had already worked the numbers on that part of the deal.  Even so, the savings realized through reductions in infrastructure and in-house support were a little more than we expected.”  

Third, are they responding to market changes more quickly?  “The jury is still out.  We just don’t have enough data over a significant period of time to know for sure.  But we have made a few changes based on reactions from our customers and we’re responding in days and weeks rather than months.  We hope that continues."

Are there speed bumps in this story?  Of course.  There's always a little manure involved with the prettiest flowers.  But overall, it's a pretty gratifying story.  By understanding their desired end states before starting the project, by treating simplicity as a discipline, and by letting go of the past to embrace new things, they have some pretty solid early returns.

So, real life.  Somebody got it right.  I love it when a plan comes together.  Don't you?

An Old Trick From An Old Dog

Old dogs look you in the eye, they hold your heart, they never lie,
They bark at planes up in the sky and wish that they were fliers.
Old dogs dream about the past when they frolicked fields of golden grass,
And chased the icy winter's blast, to lie by home fires burning.

Old dogs wander off alone but old dogs know the way back home,
The slightest scent, the buried bone, the hunter home returning.

                                                   - From "Old Dogs" by Bill Staines

I was recently asked how I evaluate different enterprise applications systems.  In all honesty, it's pretty simple:  I use a conceptual chart.  Yeah, really, a single chart.  This is it:

So I look at three different layers of components:  business value, development and deployment.  And I consider the components listed above in each of those three layers.  

I may dig a little deeper in some areas.  And I may even get into some classic system engineering analysis, with figures of merit and all that, but this is the upshot of it.  No sales hooey, no trendy buzz terminology, no nothing.  This is it.  I also use it for solution evaluation:  it's a great little framework for peeling back the layers of the onion and exposing solution risks.

Been using this framework for around seven or eight years now, so I guess that it qualifies as an old trick from an old dog.  But it still works.

An Old Trick From An Old Dog

Old dogs look you in the eye, they hold your heart, they never lie,
They bark at planes up in the sky and wish that they were fliers.
Old dogs dream about the past when they frolicked fields of golden grass,
And chased the icy winter's blast, to lie by home fires burning.

Old dogs wander off alone but old dogs know the way back home,
The slightest scent, the buried bone, the hunter home returning.

                                                   - From "Old Dogs" by Bill Staines

I was recently asked how I evaluate different enterprise applications systems.  In all honesty, it's pretty simple:  I use a conceptual chart.  Yeah, really, a single chart.  This is it:

So I look at three different layers of components:  business value, development and deployment.  And I consider the components listed above in each of those three layers.  

I may dig a little deeper in some areas.  And I may even get into some classic system engineering analysis, with figures of merit and all that, but this is the upshot of it.  No sales hooey, no trendy buzz terminology, no nothing.  This is it.  I also use it for solution evaluation:  it's a great little framework for peeling back the layers of the onion and exposing solution risks.

Been using this framework for around seven or eight years now, so I guess that it qualifies as an old trick from an old dog.  But it still works.

SaaS - Some Food For Thought

Had an interesting conversation with a new SaaS customer this week.  Big enterprise customer, along with an implementation partner, is making the move from on-premise systems for all of their Sales applications and HCM applications to SaaS applications. And they're leaving their financial systems on-premise, hoping to integrate between the SaaS apps and the on-premise apps.  To make the mix spicier,  they've picked different platforms for the Sales apps and HCM apps...same vendor, but obviously different platforms for HCM and Financials.  The approach they're taking is "lift and shift" - we want all our existing processes and reporting to survive the transition.  And they want to go live with Sales and HCM simultaneously...aka "big bang."  Fortunately, it's all in the planning stages...no purchases of SaaS yet.  I got called in to provide some advice.

I'm sure you can imagine my muffled screaming while drowning my frustration in Dr. Pepper over the approach this particular customer has planned out.  No need to hash that out here.  But my advice actually turned into a set of questions...good questions actually, which is why I thought I'd share them here.  Here we go:

1.  Can you describe the desired outcomes you hope to achieve by moving from on-premise to SaaS for Sales and HCM?
2.  What synergies do you hope to achieve by transitioning Sales and HCM simultaneously versus taking a staging approach?
3.  Do you have an inventory of your current assets?  Especially the state of your data?  How much historical data to you plan to convert to the new system?  How about a list of current data model customizations and the reasons behind each customization?
4.  Have you considered and examined the business processes baked into the SaaS apps you're considering?  Could the baked in business processes work for you?  And, if not, why not?  Could the gaps be addressed within the functionality of the SaaS apps?
5.  Have you measured how often each of your current reports is used?
6.  What are the metrics that will help you know that you've achieved or fallen short of each of your desired outcomes?
7.  What do your stakeholders - especially your administrative specialists and first-line supervisors - think of this project?
8.  Has anyone attended any training for any of the SaaS apps you're planning to implement?  If so, what feedback do they have from the training?
9.  Who are the C-Level sponsors for this project?  What is the plan for keeping those sponsors engaged?
10.  On a scale of 1 to 10, how willingly and quickly is your enterprise willing to change?  Just gut feel, right now...what's the number?

I had a few more questions that are unique to this situation, but I started with these.  Any guesses on how the conversation went?  Bottom line is the customer is taking a step back to reconsider their approach and the partner is grateful for that (the partner execs had that look on their face that you see when they realized that loss hemorrhaging on a fixed-price contract is about to begin).

Now nothing special came from me here.  Just a few simple questions, most of which we've been kicking around for at least a decade now.  So save your project early...feed your stakeholders some food for thought.

If you've got more good food for thought questions relating to SaaS implementation, feel free to share in the comments.

Stick To Your Knitting

In the States, "stick to your knitting" is an idiom for focusing on an already-familiar activity.  For SaaS vendors, better advice was never given.

The SaaS market space is young and still evolving.  As SaaS companies evolve and develop, there is a huge temptation to be all things to all customers.  After all, with 40 percent growth rates across the board, isn't it tempting for a SaaS HCM vendor to grab more revenue with a new financials suite?  Yeah, unless you're an Oracle or a Salesforce or an IBM...don't do it.

The most important key to success as a SaaS provider is staying in touch with your customers:  knowing their desired results and providing the best experience in achieving those results.  That requires serious knowledge of business processes in a specific area of expertise, such as supply chain or project management.  It's tough to build that expertise in-house.  Without naming names, we've all seen recent examples of successful SaaS vendors branching into new product areas only to get their heads handed to them on a platter.

The alternative?  Partner with other SaaS providers offering complimentary expertise.  Don't build up that new HCM Suite if your strength is in Sales software...team up with somebody already dominant in that market space.  If you focus on project management, find a partner with a solid financials offering.  Build win-win relationships that benefit you, your partner and your customers.  Doing so keeps you nimble, responsive, and best-in-class.

Stick to your knitting.  Your customers will love you for it.

Let Mikey Try It

Life Cereal came up with the perfect early adopter commercial back in the 70's:  Let Mikey try it.

It seems as though the providers that have mastered SaaS have a few things in common; one is leveraging an early adopter program.

The idea is that the provider shares new applications or new major releases with a small set of specific customers before making the new software generally available.  They do that because it allows them to learn from those customer experiences: catching software bugs and...just as important...perfecting the service component in the offering.  It's the latter component where an effective center of excellence comes into play.

By addressing service and service process issues based on learning acquired in the early adopter period, an effective center of excellence will have standardized processes and procedures for customers onboarding and starting with the new software by the time the product is generally available.  Which makes getting from onboarding start to valuable first use happen better, faster and cheaper.  And, in a SaaS world, that's the key to customer success.

It's a good model:  let Mikey try it.

A CoE for Customer Success?

So if the model we've put together in the past few posts is the key to the SaaS lifecycle, how does a Center of Excellence tie into all this?  Good question.  Let's take a look at it.

The CoE I work in, which seems typical for the industry, essentially divides the work into three categories:  Programs, Customers and Solutions.  The detail plays out in the following table:

BTW, don't thank me for this work breakdown.  It's the brainchild of Oracle's John Cafolla.  My particular role, which falls mostly into the "Solutions" category, is currently focused on building tools and technologies that improve the transition of our SaaS customers from "Start" to "First Valuable Use" - yup, another application of the "better, faster, cheaper" mantra.

Keep in mind that it's an evolving approach...note that "Escalation Support" (which we're previously defined as a negative-value activity in SaaS) is still such a substantial part of our workload as to hold a spot in the table.

It's also important to keep in mind that our particular CoE also deals with a huge base of customers coming to SaaS from legacy applications.  Due to the sheer volume, moving those customers forward is just as significant as helping customers who are new to us.

Finally, it's also worth noticing that the Solutions work focuses on the "Onboarding" stage of the SaaS Lifecycle...for the moment.  As our own journey as a SaaS provider moves forward, we'll eventually shift into an emphasis on tools and technologies to improve customer experiences in the "Nurturing" stage.  But that's a topic for another day.

So you asked how a Center of Excellence fits into the customer success - oriented SaaS lifecycle model?  Well, here ya go.

Comments encouraged.

Drivers

About the driving wheel
Want to know how it feels
To be taking time out, turn it all about
We're taking hold the driving' wheel
            - From Poco's "Drivin' Wheel"

If you can't measure it, you can't manage it
             - Peter Drucker

In my last post, I promised we would talk about influence drivers here.  So let's do that.

In any endeavor we undertake, we naturally want to achieve success...one or more positive outcomes.  But measuring the positive outcomes themselves give you after the fact information; puts us into reactive mode.  And, in customer success, we want to be proactive rather than reactive.  With that in mind, the idea is to measure drivers that influence positive outcomes...drivers that indicate how we're doing during the journey to our outcomes.

A really convenient point here:  most of our resulting outcomes are really determined during SaaS onboarding and nurturing...and most of the influence drivers we find relate to onboarding and nurturing.  Cool how that logic ties together, isn't it?

In a nutshell here, the idea is to measure influence drivers in a timely fashion (note that I'm avoiding the discussion of real-time, near real-time, and the related technical dogma - I'll only say that sooner is better).

So if it were me measuring customer success, I'd focus on something akin to the following:

Onboarding Drivers

• Time to Provision:  Measure in days the time from when the customer subscribes to when they have access to all the SaaS environments promised.  The smaller the number, the more positive the influence.
• Time to Value:  I'd measure this in days from the completion of the provisioning to the time of first value use or "go live" date.  The quicker the better.
• Initial Adoption:  What is the rate of use by the initial individual users at the time of first value?  I'd measure this by transaction numbers or usage (daily, monthly, and/or frequency).  We're simply setting a baseline here to measure growth or contraction during nurturing.
• Customer Satisfaction:  This comes down to a basic yes or no question:  would the initial set of users recommend your service at the time of go live.

Nurturing Drivers

• Adoption
• User Adoption: growth in usage - more transactions, more users
• Feature Adoption:  do we see new types of transactions?  We're looking for growth in use case solutions or in the use of additional features included in the applications.
• Capacity Utilization:  how many seats a customer is using relative to those they are paying for in the subscription?  the higher the ratio or percentage here, the better.
• Business Results:  measurable gains that relate to the outcomes desired by the SaaS customer.
• Escalations:  the number of open inbound requests, the number of closed requests, and the time to resolution for closed requests.  The smaller the numbers here, the more positive the influence.
• Customer Feedback:  The same deal here as with Customer Satisfaction, just a different point in the lifecycle.  This comes down to a basic yes or no question:  would the initial set of users recommend your service at the time of go live.

Not only would collect these for onboarding and nurturing metrics, but I would share the metrics for each customer with that customer.  Because influence drivers matter just as much for customers as they do for providers.

In addition to the metrics above, I would also measure these outcomes:

• Renewals:  both in terms of dollars and number of customers who extend their subscriptions
• Growth: both in terms of dollars and number of customers who subscribe to additional SaaS products
• Churn: both in terms of dollars and number of customers who cancel their subscriptions

Let me sum it up.  The mission of customer success is to add value for both customers and providers.  To add that value in the world of SaaS, you must be proactive rather than reactive.  And the best way to start being proactive is to measure influence drivers.

Last point for the day:  I'm stealing a huge portion of these ideas from Guy Nirpaz's book "Farm Don't Hunt: The Definitive Guide to Customer Success".  A very worthy read if you're into SaaS and customer success.

Comments welcome...

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.

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.

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.