Credits based software support pricing, departure from ‘Eat all you can’
Everyone (well almost) who has ever been through a residential program or stayed in the hostel accommodation during their studies would acknowledge that there are a whole lot of memories to cherish!
The most memorable years of my student life are the ones spent in college hostel during my engineering. Playing cricket in the hallway, watching the India-Pakistan cricket matches in the houseful TV room with lots of whistles, the card games from dusk to dawn, playing video games whole night…there are many! The only spoilsport was: Food! The college mess seemed to have only one charter…the students should just manage to survive. Sometimes I wonder if the name ‘mess’ was deliberate :) . As the college was far from city, there were no eatery options available nearby but as development kept spreading its wings, small eateries started opening up nearby. The big moment was when a small eatery came up with the option of ‘Eat all you can*’ in just about Rs 40. Now that was something! Think of students with limited pocket money and fed up with the mess food. We started flocking at this restaurant and soon, its business was booming. But the euphoria settled down quickly as we realized there were two problems:
- Not everyone ate as much. Nibblers were content with just 2 chapattis (flatbread), bit of Dal (pulses) and curry while others used to gorge like it was their last meal
- After few weeks, perhaps after getting sense of economics, the restaurant limited amount of gravy you could take! Only one ladle full
Now, suddenly this wasn’t a good deal for anyone! The nibblers were already feeling that they are paying too much money for what they could eat (hell man, others are eating so much for same amount that it seems we are overpaying!). The gluttons were even more furious owing to restriction cuz they weren’t eating ‘all they can’
The footfalls started dropping gradually and were lower day by day. The eatery tried reducing the prices, switched to à la carte but by now, the customers had found other options…
The important lesson learned: all you can eat is not always a great model. Customers may not always find value in it and may leave you after some time.
The typical enterprise software support pricing suffers from same problem. They are offered as all you can eat model with high annual recurring costs. As the deployment matures, a majority of customer needs are met and then customer may start feeling if it’s worth paying the substantial cost for what they are getting in return. The ideal solution is that periodic upgrades and software support should continue to add value to the customer so they see the ROI. However, for a mature product, more often than not only sustaining innovation is possible. Can sustaining innovation provide the ROI to the customer for the AMC? Mostly not. This calls for a re look at the existing support pricing models and come up with an innovative approach which can meet the below needs:
- The customer should pay only for what they get
- The vendor should not lose customer
- Vendor should not lose revenues attempting to retain the customer
I spent some time trying to figure out just the right model which could be a win win situation for both the stakeholders here. After evaluating multiple models, a potential model which seems to have a perfect balance of financial gain and customer satisfaction is:
Yearly product upgrade fee + Support Credits fee
For simplicity, in rest of the article I’m going to refer to above as UF&C model. Let me explain this with an example. A software company X sells its product ‘S’ to its customer ‘V’ and apart from the product license, for AMC it charges $60,000 for 2 upgrades in the year and $40,000 for 100 support credits valid for one year (both mandatory). Now, as V uses the product, it needs support for resolution of issues, enhancements, help etc. and they raise SRs using the support credits. Say, at the end of the year, customer is still left with 15 credits. Upon renewal, X will charge the customer $60,000 for next 2 upgrades and then offer a 15% discount (proportionate to remaining credits) on the Support Credits fee so the effective cost is: $60,000 + $34,000. This translates into a 6% saving for the customer compared to first year. Next year, 40 support credits remain unused. This gives the customer savings of $16,000 next year hence giving effective 16% savings.
This approach can raise the below questions though:
- What if X provides inferior quality of product deliberately so support credits are all exhausted?
- Can the customer redeem the support credits for cash?
Well, let’s see if we can address them both! For #1, X doesn’t put a restriction on the number of SRs the customer can raise in a year. After using up the credits, customer can still raise issues and these ones will be effectively served for free. This means that X doesn’t gain by keeping the product quality inferior because if they do, they still have to provide support without getting any extra revenue. Whereas if they keep the product quality good, apart from better customer satisfaction they would save time and resource on bug fix, support costs. If the product quality is terrible, customer would end the association sooner anyways resulting into irreversible loss. On the other hand, if customer still has some credits remaining, they wouldn’t want to waste it over petty issues and would raise SRs only if the issue is indeed impacting the business.
For #2, short answer is ‘No’. The customer can’t redeem the credits for cash. For the remaining credits, they can only get discount on next year’s support credit fee upon renewal. In case the customer wishes to move out, they would have to forego these credits. Treat this as a minor exit barrier for the customer. I guess it would be fair to the vendor :)
This approach solves the problem for both stakeholders. They both have to be equally committed and need to work towards betterment of each other.
The next big question! How to arrive at pricing breakup and the ideal number of credits so it doesn’t seem too less for the customer and vendor doesn’t end up giving substantial discounts every year on the balance credits? Well, I would say dig the customer support data goldmine and put #machinelearning at work. This becomes a three part solution.
Segmentation of the customers on revenue and choose the segments that matter the most to the vendor. These can be segments with maximum attrition or the ones that have highest revenue potential that vendor would want to focus on to preempt potential losses.
Build a classification model for the chosen segments to predict if the customer left or remained with vendor after a certain period. Few of the attributes (or independent variables) like average number of support requests raised by customers severity wise, average turnaround time for support requests, the number of years they renewed etc. can be useful.
Analysis of customers who have left vs the ones who remained with the vendor to arrive at potential minimum, average and max revenues that can be made from each customer so that they don’t leave the vendor. This analysis can help Enterprises determine the key metrics of Upgrade Fees and Support Credits. Some of the considerations could be average number of support requests raised by customers severity wise, average monetary value of resources spent on addressing each such request, the number of customers who left quoting high costs, the number of years they renewed, the number of customers who continued etc. Once this analysis is complete, based on the outcome, the UF&C can be offered tier wise too if the data suggests that would be the best approach to handle different categories of customer.
Is it likely that there are few companies following this model? I would say, very much possible and I’ll be happy to know as it would only validate that my analysis is in right direction. I’ve seen few companies using the support credits but haven’t come across one which uses the same model for enterprise software.
What do you think? Do you know of any organization following the proposed model or a variation of the same? Please let me know your feedback in comments.
Disclaimer:
- This views presented in article are strictly my own and in no way represent the views/policies any of my current/past employers.
- The names used in the article are imaginary.
- The images in this article are subject to copyright.
