The ultimate dream of a SaaS product is to have a context agnostic product that any customer can sign up and start using successfully. In reality, most B2B SaaS product use cases are context dependent as most workflows in any organisation have some context that cannot be abstracted out. For example, travel policy or leave policy in a large organisation will have context dependent rules that does not apply to any other organisation using the HRIS product, usually ability to accommodate such odd rules becomes the decider in clinching the sale. Usually, the product team provides a workaround that is rolled out to the client by the customer success (CS) team.
The workaround helps in clinching the sales it creates multiple problems for the CS and product teams
- The work around fails when there is a product update that did not factor in this work around during the design stage
- The CS process becomes person dependent as the context is known to the onboarding person or the first CSM handling the account, leading to inflexibility in account realignments or onboarding newer CSM s to an old account.
- High level of contextual support increases the cost of CS as the number of accounts per CS person is much lower as compared to a low context situations
So the conundrum is how do we provide some amount of customisation while not compromising the scalability of the product and CS process. The ability to accommodate unique customer workflow is a double edged sword, when the workaround works well it is a delight for the customer but can become the source of friction if and when the workaround fails.
As an operations professional leading customer success in B2B SaaS, appropriate handling of such requests becomes critical to delivering predictable customer experience metrics within the planned budget.
I have a three pronged approach for handling such requests from the sales and product team.
- Have a definite criteria for the use cases that can be dealt with outside the product.
The only workarounds that do not fail and work consistently without increasing cost of CS are the ones defined for infrequent but calendarised use cases. For example, a work around required to make a GST adjustment happens once a month and always on the 8th to10th of a month. Such a workaround can be managed well without any slips. However, adjustments to travel allowance approval can happen at random times and is likely to be missed by the CS person.
- Define a target sunset date for the work around, so that there is a date by which this manual intervention is removed. The review of processes to be sunset and/or built into the product needs to be driven by CS as it affects predictable customer experience metrics.
- Project revenue at risk and cost of servicing for all the work around currently operational in CS. TRacking and projecting this cost and revenue at risk for each workaround will help build a business case to invest in the product or to do away with the manual intervention.
- Have a definite criteria tied to the customer experience for refusing work around use cases.
- Usually any use case that has a high frequency of occurrence and does not have calendarise occurrence is likely to fail at random times. Human interventions work best when the occurrences can be predicted and planned. It is better to say no to a customer than fail when the customer needs us the most.
- Any work around that has a customer dependence is likely to fail as soon as there is change in the personnel at the client side. The new person invariably questions the choice of product and the relationship starts going downhill. It is better not to take up such engagements than to lose the client after investing a lot in onboarding and stabilisation.
- Document and collect all the client attritions ( revenue loss) resulting from the workaround failures. CS is the only team that can provide this vital information to the product team, hence it is important to collect and review this data atleast once a month.
These five steps help in managing
- The number of outside product manual interventions within limits to manage the CS cost within budget
- Predictable delivery of the workarounds by the CS team to meet the targets of CX metrics
In your experience are there other scenarios that can be managed with manual interventions?
Have you used any other approach to manage the number of manual outside product interventions in the CS process?
