In my previous article, I discussed the different Customer Success Team Engagement Model, their Pros and Cons. Neebal has always believed in knowing the industry's best practices about delivery processes. Tweaking & customizing the training as per its work culture, delivery processes, customers, and nature of their business & technology platforms.  In this article, I would cover a customized Version of Core Flex Model adopted by Neebal for its Enterprise customer. The later part of the article would also discuss how to identify which model suits different requirements since no one size fits all models.

In line with our philosophy, we have come up with our version of the core flex delivery model, which has worked well with our customers and us. We had tried to overcome the cons listed above of conventional core flex model with our tweaks:

• Flex Model within the Core Team

• The dominant tech stack within the application(s) is identified
• Engineers with dominant tech stack skill need to be allocated 100%
• Less dominant tech stack skilled engineers are treated as flex resources. They are billed on an actual basis
• For example, if for a product, multiple tech stacks are involved, say Java, Angular, Android,iOS, System Integration, etc. More than 70% of the application code is written in Java. Then only Java engineers need to be allocated 100% to the project. Other skill sets are brought in as and when required. Billed only if they are used in a month for support or new feature delivery
• Business analysts, project managers, are also treated as flex resources with fixed allocation every month. But they are billed on actual efforts spent and not for the fixed allocation period
• This allows the customer to cost optimize within the core team

• Customer Transparency

• Real-time Power BI dashboards are made available to customer business & IT SPOC.
• The dashboard has real-time integration with Neebal’s Agile tool used for ticket & project management  & time reporting.
• Customer can see in real -time following key KPIs
•  Current spent budget for the month
• Support tickets resolved
• Change Requests have been worked on, their estimated time vs. actuals
• Efforts contributed against every support ticket & change requests by different CS Team members
• Resource efforts spent a month to data against actual
• This builds a lot of trust with the customer when they have transparency on data

• Dedicated Knowledge Manager

• The knowledge manager’s responsibility is to study the ticket/support incident data every two weeks and find patterns in incident and service requests
• Work with the core team to reduce frequently occurring requests with self service panels or automation & long term fixes for recurring incidents
• Focus on creating Knowledge Base (KBs) and wikis to counter attrition & resource churn

• Business Governance over IT Governance

• Weekly review meetings with business & IT SPOC on the status of support tickets
• Suggests identified system improvements to reduce time spent on support and increase time spent on new feature development
• Business SPOCs define priority for change requests & new feature development for next week
• The core team is continuously aligned with business priorities

• Cover A to Z (Support Coverage from Single Product to suite of products)

• The model can be scaled from single product support to a suite of application support
• An enterprise’s every application big or small can be covered in this model, helping them optimize cost
• Core flex team is assigned to support the application suite with governance spanning across multiple businesses

• KPIs beyond traditional SLA tracking

• Following Key KPIs are tracked on a monthly basis apart from Team SLA:

• Quantifiable improvements in Ticket resolution time for same category of tickets

• Month on month reduction in Incident Rate against no of transactions executed in the system

• Hours spent on every service request & incident

• No of change requests delivered & efforts spent against them

• Total cost value of CRs delivered against Incidents & CRs

• % Effort Reduction recurring service requests

• Budgeted vs. actual spend for every  core flex Resource

• No of Wikis/KBs created

Find below a sample dashboard shared with one of our customers for their Core Flex Team:

• Capping of Costs of Large CRs Delivered

• Small CRs with Dev Efforts <10 days are executed without estimates approvals allowing agility to delivery small but important feature releases quickly

• Estimates shared & agreed upon for CRs with estimated Dev efforts  > 10 days

• The customer pays for the agreed efforts for the month’s billing

Thus, the Core Flex model is value-driven, unlike traditional TnM model & Shared Service Models of support. Rather than focus on the number of hours spent, importance is given to value derived from change requests delivered & reducing the number of service requests & incidents occurring in the application.

Having Implemented this model across multiple Enterprise customers, we have observed the following Gains: 

The question arises on how CIOs; IT heads of enterprise companies decide which model to opt for considering every model has its pros & cons. Neebal has created a decision tree to help IT leaders determine the Customer Success Team Engagement model.  The decision tree has been provided here:

Typically, application maintenance & support consumes 80% of total application lifetime cost. Hence, identifying a cost-optimized support engagement model is critical to reducing overall lifetime support costs. The decision tree made above is an excellent guide to arrive at an engagement model. Any engagement model you agree with, identifying quantifiable KPIs & objectives which the customer believes creates value for them for the money they are paying for the engagement is significant. Tracking these KPIs regularly and reviewing them with vendors would allow a Customer Success Engagement model, which fits your business & applications/platforms, supporting it.