Customer Success

Don’t Fear Business Process Change. It’s (Usually) a Good Thing.

echojason@gmail.com'

Jason Lemkin

Recently I was having a discussion, not quite a debate, but a discourse with an extremely smart VC — far smarter than me — who was relatively new to SaaS, having spent more time in B2C.

Like a lot of folks tip-toeing from B2C to SaaS, his first stop was in freemium.  He was obsessed with apps that you can “grab and go” with — use in just seconds.  Like Facebook.  Or Slack.

Screen Shot 2015-11-29 at 4.02.45 PM

The thing is I told him, I hear you, I get it.  For a simple, cheap tool that totally makes sense.  If I’m paying $0 or $5 a month, I better be able to start using your SaaS app in about 60 seconds ideally.  10 minutes max.

But a true solution to an enterprise-grade problem almost by definition requires business process change.  Which can and indeed usually should include onboarding, training, follow-up, and often, a full-time admin of your product on the customer side.  And that’s a good thing, at least, 8.5 times out of 10.

In fact, my uber-learning is one of the Top 10 reasons customer success is so important is to make sure this business process change is implemented.  If you do nothing else in Customer Success, make sure you have full engagement by Day 5, Day 15, Day 30, Day 60 … whatever exact amount of time is right for your app.  But make sure it happens.  And what you are really making sure happens is business process change.

It’s OK your app is more work to deploy than Facebook:

  • Changing say, how you manage your call center, how you train your workforce, how you manage your customer relationships, etc. — the things that many of our apps do — is a big deal.  And a lot of work.  But along with this big change (should) come big returns.  And thus, customers are willing to invest the time.
  • Most SMB SaaS apps are really ERP 2.0 for a vertical or industry.  A new ERP, to get the benefits of that ERP … always requires business process change.  You can’t pick this up in 60 seconds.  A new financial system, a new task management system, a new order management system … can be epic.  But it ain’t an Instagram-like deployment, even in an SMB.
  • If you don’t actively manage business process change, engagement will be far lower for most business process SaaS apps.  Yes, I can grab Slack for my product team.  But want the whole frickin’ enterprise to use it?  You better have training.  Emails.  Follow-ups.  Active management of usage.  And yeah, probably — a Slack Admin.  Otherwise, outside of its hot spots — you’ll only hear crickets on most Slack channels.

Now it’s not quite all this simple.  The bigger the customer, the most likely it is they’ll have someone fully dedicated to deploying, managing, and tracking your app.  That’s a good thing and can help a lot.  Often times, post-sale, your customer success team will spend a huge amount of time with these folks.

The smaller the customer, the less likely it is your customer will have a person to help manage this business process change.  Your team then will more likely be doing the training, doing the change management themselves.  That means often times, business change has to be more incremental, and managed in stages.  And it will take a lot of time.  A lot of time.  And a lot of follow up.

But wherever your product comes out on the “work to deploy” spectrum, don’t fear business process change.  I say run to it, embrace it.  If your app could either be a “grab and go” tool or a full business process change solution, I say, let it do both, but embrace the work it takes to make your app 10x-20x more valuable to your customers.  Yes, this will help with churn, it will make your app stickier and harder to rip out.  But it’s much more than that.  It will ensure your app truly changes a core business process in an important and fundamental way.  That’s what really matters.  And customers will pay a lot, lot, lot more for that.  A lot more.  At least — once you get good at it.

Published on November 30, 2015
  • Brendon

    I think these are two different things. There is technology that is hard to implement/rollout/configure (which is just bad 100% of the time no matter what) and there is business process that is hard to change (table stakes for SaaS).

    If it is hard to setup, configure, and deploy your application it isn’t good, ever, unless you are so upmarket and your ASP is so high and you own your market (which means you aren’t a startup anyways) or the customer doesn’t even really need to evaluate your technology. (i.e. you’re Salesforce)

    If it’s that hard to implement from a technology standpoint, then you just plain defeat the purpose of software as a service really. May as well just start selling on prem and pretend it’s 1999 again.

  • Your core message resonates with our experiences thus far. Instead of running away from the change we are causing, we are implementing change management techniques as part of our customer success methodology. This is invaluable for us, and our customers.

  • I couldn’t agree more. Every application (SaaS or on-premise), if it is going to make a difference,will require the client to change their business processes.

    Sadly, what has not changed in the last 20 year is how vendors, implementation consultants and clients go about executing that business process change. They are still using whiteboard, yellow stickies, Powerpoint, Visio or Gliffy to document processes as HUGE flowcharts that only the authors can understand. Yes – really.

    And then they wonder why end users struggle to adopt new working practices consistently – and consequently the underlying applications are underexploited. This is presented as “the application doesn’t work”. Clearly unfair, as any end to end process is over 50% manual activities, and therefore the fault probably lies in end users not doing what they should be doing…. because nowhere is it laid out in a way that is easily understood – “who needs to do what, when, why and how”.

    For 14 years we developed a client-server software application for documenting and communicating business change for 1000’s of clients who got remarkable results and won awards. That software company was acquired in 2011. After several years off, the founders have got back together and seen that the business problem is still as large as life. As evidenced by this blog.

    And there are still no modern SaaS solutions. Until now. Q9 Elements launches in Feb with a freemium model – with a twist. The core functionality to enable any company deliver any change project of any scale will be free. Forever.

    Out aim is to make it easier for every vendor to get their application implemented more easily – reducing the load on their customer success teams – and having happier, stickier clients.

  • Sunil

    This is 100% consistent with my experience, having worked at an enterprise software company for the past decade.

    Often times, company management realizes they need a process change to achieve some benefit, and a new technology initiative provides good cover to catalyze it. Most people will accept that software has some learning curve, and their existing process has to change to reflect the paradigms of the new solution, so change management is easier than if the process change was done without technology.

    If a company is willing to change process and tie your solution to other IT systems, you’ve got a sticky customer for a long long time (assuming the initiating value driver is realized). Plus, you can likely negotiate price increases over time. Otherwise expect churn, with the time the clock ticks dependent on the ACV (more investment = more leeway before they pull the plug).

    Thanks for calling out the importance of services in a business SaaS offering.

  • Thanks Jason – great article.

    We are just starting to set up in the US and are finding selling implementation & training very difficult here. We keep hearing that the client wants to do it themselves, even though there is massive process change required.

    In our markets in Australia, New Zealand & the UK there is virtually no resistance to paying for professional services.

    Is this a common issue in your experience while trying to implement large systems in the US?

Share This