Anyone running a CS team for an on-premise software company?

I may be taking a new role building and heading up a customer success team for a company that has exclusively on-premise software. I've got some experience running CS for on-prem systems but most of my experience is in SaaS.

There's a general concern among the company's management about building a health score or getting adoption/usage metrics to gauge what's being used, etc. Putting in telemetry/"phone home" capabilities might be an option but it's not happening soon, and won't fit across all our customer base.

So, if you have a black box for customer usage info, etc., how would you handle it? Happy to set up an offline call with anyone that would be willing to share ideas. Thank you.

Find more posts tagged with

Technology

Comments

ERIKA COWEN

Hi Victoria, this is interesting, how did you do this? Via Salesforce or?

Victoria van Antwerpen Spencer

Another thing to consider: do you have enough bandwidth to provide 1:1 attention to your entire installed base? Or do you need to apply different CS model to different customer segments, aiming to balance business-feasibility / ROI with desire to ensure 100% install base coverage? How to care for the "long-tail" customers, if you have them?

One idea for a low-touch approach is to create an ability for your entire customer-facing part of organization (sales, services, support) to be able to flag a "customer at risk" based on a specific criteria or even a subjective observation. This flag should be picked up by the CS org for triage and remediation. This approach is less than proactive, but a lot better than reactive, while the costs are minimal.

Emmanuel Malanda is definitely the true pro here and it's all important to mention that he's an all-around great guy! He has spent a lot of time with me and has provided me with invaluable advice around Customer Success for an on-prem solution.

One of his first recommendations to me was to conduct a churn analysis. In the non-SaaS world, churn can equate to non-renewal of Support contacts. Dig into each Account that "churned" and try to discover why it occurred. For example:
--Were there Support-related issues that caused the customer to churn (multiple escalations, sev 1 cases, slow time to relief)?
--Constant unresponsiveness or general lack of engagement when called upon
--Was the customer properly onboarded to drive consumption?

Other areas/things you may want to consider:
Customer "interviews":
--Take special notice of any trends and commonalities across the group of customers you interview. Things to pay attention to may include product features being called out that are more useful or less useful than others, specific areas constantly being called out (eg. "your documentation is lacking" or "nobody ever responds to my questions in your forum"),
Community Engagement
--If the vendor has a customer community, how active in the community is the customer?
--Monthly newsletter and/or webinar engagement
Agree Upon Milestones and a Timeline with Your Customers
--If milestone dates are being missed, understand why and adjust the health score as necessary

Anyone else up for a "team call" around this topic? I'd love to hear other ideas and to learn from each other

Regards,
Daryl

Daryl Colborne

Victoria van Antwerpen Spencer

Hi, Jim

I have established a CS practice for on-prem SW for HP Software a few years ago. Happy to share experiences. Let me know if you would like to have a direct chat.

Cheers,
Victoria

Andrey Tirel

One more thing @Jim Jones, how sticky is the hardware? will they rip you our and go with a SAAS offering, how can you tell?

Andrey Tirel

@Jim Jones I personally have not covered hardware but I have seen competitors that we have replaced at Snowflake and even some now at Lacework. The focus of CS in those meetings, from what I have heard from my clients, is staretgy. Does the hardware solve the use case it was bought for, how is the engagement with the maintenance plan?, when will things need to upgraded/replaced, EOLed.

Having a regular cadence with the core team to understand how they used the hardware, where they see challenges, share new things you are working on and honestly, just build relationships.

Jim Jones

Hi Scott - thanks for your insights. I may very well take you up on the offer to chat directly once I start working more on the index.

Thanks again.

Scott Morgan

Hi Jim,
Emmanuel covered the options well. In my world of cybersecurity, the on-prem solutions do not "phone home" and usually are air gaped from the world. We built the health score base on engagement frequency. How often is support contacted. How often does the account executive and CSM make contact and who is at those meetings. The sentiment of the AE and CSM. How often is the software upgraded. We tracked all the data. Through data analysis we discovered these points were the best indicators of success.
Our goals for the CSMs were to have them meet the economic buyer at least twice a year and the technical buyer each quarter. Part of the CSM or AE meetings with the customer offered and encouraged free conversation.
I am happy to discuss any ideas further with you.
/scott

Jim Jones

Hi @Emmanuel Malanda:

This is great stuff, thank you for the detailed reply! I wanted to quickly acknowledge this and thank you for all the info...I'm going to digest it more and I may end up reverting back with some follow on questions.

Jim

Emmanuel Malanda

Hi @Jim Jones,

Few things i have experimented with to understand scale, scope and value derived from the product which i will share here and will also share how i have adapted that in relation to the Health Score.

Option 1 is to have a capability within the product to send the metrics back to you and i see on your post that the "phone home" capability is something that you are exploring however that in itself has challenges e.g. not every customer will be willing to configure their system to automatically send metrics to their supplier, in the world i operate (FinTech), I often get the "we cannot send you this data due to confidentiality" or other variations of the same confidentiality card...

Option 2: for those customers who might not want to share data regularly but who might be open to allowing an annual/ quarterly audit. this could be an option although, this will not give you the real-time view that you would get from a SaaS setup. It is something and way better than nothing.
.
Option 3: is using the Support activity (tickets or enquiries raised) to have an idea on where most of the issues are coming from and thus deduce the usage from there. This could be as simple as getting a regular report that shows each customer and the areas of the product affecting them or areas of the product they are enquiring about, to a more complex set up that combines support activity with usage analytics derived from a customer portal that requires authentication in order to access for example knowledge articles, guides, training material etc.

Option 4: using the CSMs to get this information via their regular catch up meetings etc and for them to feed this information back in a form that could be exploited.

Short of having Option 1, everything else would be a "not so complete picture" and therefore should be reflected by the weighting allocate to usage data on your Health Score. I generally go with this simple rule, the less accurate the telemetry, the less weight it will have in the Health Score and if it is really unreliable, I do not consider it at as its just noise that will decrease the accuracy of the Heath Score.

I see you mention that "There's a general concern among the company's management about building a health score or getting adoption/usage metrics to gauge what's being used"

I would say that before trying to build the Health Score, you probably want to spend sometime understanding where the reluctance is coming from. Is it because they feel the usage data will be unreliable and thus will affect the Health Score or is there an underlying concern about the Health Score which is not specifically linked to usage data?

When implementing Health Scores and especially in an On-Prem setup, I have often deliberately avoided "usage data" at least when rolling out version 1.0 or even when rolling out version 2.0 of the Health Score. I generally ensure there is a generally accepted understanding across depts. on what makes up the Health Score i.e. the parameters, their associated weights and that i am comfortable with the level of accuracy. I fine tune that until everyone is comfortable thus giving me the time to also assess the reliability of any data I might eventually use to represent usage data.

I would say, start small and usage metric is definitely not the place to start if you are introducing Health Score in an On-prem business. it will scare off too many people :-)

I am free to have a chat if you so wish and i will walk you through some of the stuff i have done in the past.

Best,