Customer Success Engagement Model

Content Source: Priyadarshan Patil on LinkedIn

The  technology companies (experts in building Bespoke Platforms) often have a unique focus on developing new apps, products, and  web platforms. We at Neebal are always curious & excited about all things technology and the process it involves. From writing a new piece of code, to designing a new product or testing  pipelines.  We believe that – “Real customer success lies in running these technology platforms with minimal disruptions after they have moved past their early launch & adoption phase”. In this period businesses start deriving value from the IT investment made for the product. From a technology perspective, this phase is often termed as “support & maintenance”. The team managing the same is called the “Support Team”.

The support team plays an integral role in ensuring that front office, back office & field users can use digital platforms with minimal disruption to become more efficient. Prompt responses, quick debugging, hot production patches, frequent app monitoring & the list goes on. Any instance of delays in responding & resolving these issues would directly impact  employee productivity, and indirectly affect  the  business & its revenues. Thus, the support team’s performance plays a pivotal role in the success of the customer’s business. Hence, at Neebal the support team is named as the Customer Success Team (CS Team ) i.e., the team responsible for ensuring customer success.

Several industry-standard delivery models are available and followed by IT service companies for their customer’s application support & maintenance. The table below provides a comparison of these different support models based on our experience of working with them:

Comparison Metrics	Shared Service Support	Ticket Based	Hour Based
Value Measurement for Transparency	– SLA for Ticket Resolution	– SLA for Ticket Resolution   – No. of Actual Tickets resolved vs Ones in Contract	– No. of hours spent in a month on Support (timesheet)   – SLA for Ticket resolution can be measured
Maintenance Focus	– Focussed more on corrective rather than preventive actions (monitor crash reports & fix them, proactive product upgrade for new device OS upgrades, identify transactions impacting system performance, so on and so forth)   – Requires Strong Customer IT Focus & motivated Vendor to drive preventive maintenance measures	– Focussed on Corrective maintenance	– Focussed on Corrective maintenance – Requires strong customer IT focus, business team understanding of preventive maintenance measures & a motivated vendor to suggest preventive maintenance measures
Customer Interest	– Application Stability	– Application Stability – Control Ticket Count	– Application Stability – Control Hours Count
Vendor Interest	– Increase team utilization across other customers to derive greater EBITDA	– Increase Ticket Count (contradictory to Customer interest)	– Increase Hours count (contradictory to Customer interest)
New Feature Development Support	– Requires separate hours based contract   – Business process improvements and changes are customer driven   – Vendor lacks dedicated customer business focus because of shared allocations across different customers	– Requires separate CR Contract   – Customer driven   – Suffers from same problem as shared service support	– May get covered within the contract   – Requires separate rate contract for specialised skills for CR Project   – Customer driven because of lack of dedicated focus from vendor team
Fitment	Suited for Standard Products like ERP & CRM where business processes are standardized across different customers and their businesses	– Suited for Standard Products like CRM & ERP – Suited for Small and matured Bespoke Business Apps	– Suited for small to medium sized Bespoke apps

As shown in the table above, every model has its  pros, cons , and measurements forcost and value. But all of them lack proactive focus on continual value delivery to business through either preventive maintenance actions for increased platform stability & regular feature delivery (within the support team) since teams are shared across multiple customers.

Apart from the above standard models, there is one less commonly known and seldom adopted – “Core Flex Model” that addresses gaps of models described above.

A typical Core Flex model consists of the following:

• Core dedicated client team
  • Customer-facing team understanding business domain & existing systems
  • Typical team members  – Project manager, Business analyst, QA Engineer, Integration Engineer, Server-Side Developers
• Flex Team
  • Consists of 2 teams
    • Generalist Team
      • Developers for enhancements and low priority ticket resolution
      • Onboarded on demand during peak requirements
    • Specialist Team
      • • SMEs consisting of architects & process consultants, Service delivery head, DevOps engineer
      • From shared resource pool working
      • Procured on-demand basis workload
      • Cost spread over multiple clients creating value and efficiency

Lets cover the Pros & Cons of this model:

Pros	Cons
Continuous focus on value delivery for customers with a dedicated core team with a deep understanding of customer’s unique business processes and bespoke applications.	Not suited for small business applications requiring continuous support and minimal enhancements (in case of a matured business process).
The team of a specialist in the flex team brings the value of their knowledge and expertise to add value to customer business.	Fixed partial allocations for flex team means fixed monthly outflow for business in case of unused flex resource hours.
Flex Team provides flexibility to add or remove resource basis peaks and low of delivery.	The dedicated core team also means minimal cost optimization opportunity for business in case of unused resource hours.
Any business process change can potentially be executed within the core team who is managing support too.	Not suited for SMEs/SMBs who work with minimal IT budgets.
With a dedicated team from vendors, continuous pressure on them to keep generating value every month.	No real-time view of consumed budgets to the customer to decide if they can get delivered more change requests in a month.
The team can be leveraged to build RFPs & business requirement documents for significant business process change, which have to be executed as a different project.	For projects requiring a multitude of development skill sets, for example, android, iOS, integration, Java – every skill set type needs to be budgeted, resulting in cost escalation.
Relatively cost-optimized in comparison to pure agile TnM team with the partial and on-demand allocation of flex Team

The choice of Customer Success Team model would vary basis the Business type, the degree of uniqueness of their business processes, the choice between a bespoke product built vs. standard product leveraged to support these business processes. There is no one model which fits all.

In my next article, I will talk about Neebal’s unique offering of the Customer Success Team  Model which focuses on value delivery to business rather than cost . I will also cover a decision tree thatCIOs & IT Heads of Businesses can use to decide the Support & Maintenance model that best supports the systems that facilitate/drive their business.

 The  choice of support & maintenance contract type for IT systems supporting Businesses is often a dilemma for CIOs, IT Leaders & Business Heads. What are the choices available, what’s best suited for my enterprise ecosystem & how do I derive maximum value out of it?. These are a few difficult questions to answer. In a series of 2 articles, I would try to cover such questions around IT system support engagement specifically for Bespoke IT platforms. Please do read it and share your views. This is the first one in the series.