How Innovaccer’s Customer Engineering Team Handles Implementation & Onboarding

Ashish Singh, Head, Customer Engineering & Analytics at Innovaccer, about Innovaccer’s data-focused approach, its focus on transparency
Kirthika Soundararajan
March 14, 2021
Implementation Stories
Main Illustration:

How Innovaccer’s Customer Engineering Team Handles Implementation & Onboarding

Ashish Singh, Head, Customer Engineering & Analytics at Innovaccer, about Innovaccer’s data-focused approach, its focus on transparency
Kirthika Soundararajan
March 14, 2021
Implementation Stories
Main Illustration:

In this session of Implementation Stories, we spoke to Ashish Singh, who heads Customer Engineering and Analytics at Innovaccer, a healthcare data activation platform with global clients. Ashish joined Innovaccer in 2019 as VP of Customer Engineering and Analytics. Before that, he had worked with Barclays and Tech Mahindra, having experience of close to over 11 years in banking and telecom.

In this session focused on customer engineering, we spoke to him about Innovaccer’s data-focused approach, its focus on transparency and openness – in culture and code, challenges, and learnings for people working in customer onboarding and implementation.

 Let’s get started. (The conversation has been edited for brevity and clarity.)

We’ve seen different models of implementation – some where the customer does most of the heavy-lifting, in others, it’s mostly third parties. How would you describe your implementation model?

In our case, the implementation is done entirely by our internal team. Once Innovaccer signs a contract with a customer, our customer success team gets involved. We have two parts here – one for account management and the other for delivery/implementation. The account management team’s job is upselling and managing customer relationships

On the implementation side, we (Customer Engineering) do everything – AWS, Azure, setting up the environment, ETL work, creating data pipelines to pull data from the customer environment – all of it. After that, we run analytics, create dashboards, power up the application. Only once all this is operationalized, do we hand it over to the customer. All the integrations - DB connects, the API for their data to flow to us, the bidirectional connectivity is managed by us 

Of course, the customer gets access to the dashboard and has the flexibility to experiment, but getting the platform ready is completely our job.

How big is your team? How many members typically handle one delivery?

The size of the team depends on the scale and complexity of the project. A typical healthcare project has 50-60 integrations on average. It takes a team of 4-8 members – including the management layer -  over a couple of months. 

How long does your implementation typically last? How do you work that out?

Implementation takes anywhere between 6-9 months. But our focus is to deliver some value to the customer at the earliest. So our delivery is incremental and continuous so they don't have to wait nine months to access the platform. We try to give the customer the first value at the earliest, say a couple of months.

Tell us a little more about this Value Delivery model. Is there any math to the ROI?

So, we have a Value Level framework that we have developed. Based on this framework, every customer will have value levers mapped to their business model or problems. This makes it possible to show the ROI to the customers in dollars.

For example, take the Emergency Department(ED). Patients frequently come to the ED, but the incentive model works the other way around for the companies. The companies would want to restrict the visit of patients to the ED. The model takes inputs like the number of patients to suggest assets that can bring down the visits and hence impact the incentive.

Does ROI computation involve a timeframe? Who does this?

We closely monitor 'Time to Value' - the first time a customer realizes value on our platform. When we talk about contracts or charters, we clearly indicate the deliverables and value to be delivered on 30/60/90 days.

Defining this scope is the biggest challenge. So we involve the customer and map their challenges or opportunities with our framework. We make sure we agree on and close this within two days.

For us, this is done by a combination of Sales, Customer Success (CS), and Customer Engineering (CE) with Success and Sales doing most of the front-ending.

How do you handle data curation?

In our customer environments, data centralization is a tough ask. The implementation team gets two kinds of data

  • Structured: Comes from vitals in a specified format and goes into the system.
  • Unstructured: Includes doctor prescriptions in PDF format.

When we get any data we agree on a set of rules – to set expectations on what we can do with the data. We have Quality Checks or automated suites that run data profiling. Where possible we infuse this data with our data pipelines. Where this is just not possible, or we’re missing some mandatory attributes, we discuss this with the customers up-front to course-correct data capture at the source.

Do you provide a demo environment for the customer to experiment with before go-live? 

We offer a demo environment called 'Playground.' It gives them the feel of software without the actual data. Customers get to see the software's capabilities, how data moves, reports, and everything else. However, we try to get the customer to go live with their data in 8-12 weeks - we give them something very specific, in line with the value delivery framework. The idea is to box the implementation for release - for 90 days and keeping that goalpost intact is the biggest challenge 

How do you handle change requests? 

Transparency is a core value for us at Innovaccer. We make everything visible to the customer. We even give them visibility to our project management tool. So, they can see our project plans, story points, our sprints, down to the last detail. 

So, if there’s any change request, we ask them to fill a change request, we evaluate it in terms of effort and time, and communicate very clearly the implications of this change – that we need more people or more time or ask them to tell us what we can deprioritize from the current release. All this while making sure they see how it affects the end outcome as well. We’ve seen that talking about the impact on deliverables discourages customers from randomly adding things.

How do you handle rollout-related change management at the customer side? Is that also done in stages - say training on certain modules in one phase and the others later?

Different personas of users use the platform. For example, InCare is a product for care operators. For them, we do user mapping and pre-training analysis. And then, we provide online courses, face to face training, etc. Our trainings are conducted by people from the same healthcare field. This ensures the expert has more empathy and a common vocabulary with the trainees.

When we are ready to go-live, we land them into our staging or UAT and start training them. We monitor usage and take steps in keeping up with users.

Even in cases where there is high attrition within our customers’ users, we rely on online training, or a repository, or a Train-the-Trainer approach to ensure that we support users without repeating training. 

What would you say were the most impactful changes you made?

  1. Value delivery framework: Though we always had a customer-driven approach, the value framework and talking about ROI upfront allowed us to align expectations and work towards a common goal.
  2. A fully transparent delivery approach: Customers could see everything – how users were moving between stages, number of users, active users, dropped users, new users. We gave them a centralized capability to track everything – even our end of implementation.

This is where the relationship progressed from a vendor-client relationship to a partnership.

  1. A scalable unit/pod culture: In the growth phase we are, we must have a structure we can easily scale. To do this, we started defining the unit of different operations. For example, we started defining ‘pods’ as a self-sufficient unit to deliver – that includes everything from a Customer Engineering Manager to a Data Analyst to a QA team member. This way, we didn’t end up doing things on the fly – we could predict how things would look 9, 12, or even 24 months later.

How has this transparency changed behavior – at the customer end and even your own?

To give you some context, we were getting data from different sources - project management data from JIRA, deals, etc from Hubspot, not to mention all the data in emails on agreements and revisions, It made sense to centralize everything and create a holistic view of everything

 So, we built InCustomer, a tool where customers had complete visibility of what was happening with the project.  InCustomer covers everything – from abstract view to the detail - - from revenue to our team members’ names. This includes the contract, the scope, the stage the customer is at, how sprints are distributed, who is working on what. This way, they could view the dependencies on them, what was blocked, the due dates to remove a blocker before it becomes a show stopper, the works.

This greatly helps in expectation setting and also in value realization. For instance, we add the value delivery numbers that the customer CFO can view, a customer PM can see how the implementation is going, the coverage, what assets are coming in, etc.

InCustomer became a part of every meeting - at every level – from the daily scrum to the weekly meeting – it’s the only tool we use. It has taken the PPT culture out of the picture as there is no longer anything to prepare – since everything gets updated and shared in real-time.

For our teams, since customer centricity is our DNA - the moment we expose something to the customer we are disciplined immediately. It plays a huge role in shaping and driving the culture. When you are working in a fast-paced environment, creating documents or updating them becomes the last priority. We’ve all seen a PM chase nearly 20 people for a weekly status update. That’s no longer the case.  

How do you define the ‘pod’ you spoke about? What goes outside the pod right into the product?

We are focused on making Customer Engineering (CE) self-sufficient. This is why a lot of configurability has to stay with CE. We have an open-source culture within the company. So, even Customer Engineering can build and contribute directly to the product. 

We’ve given the CE team configurability related features, so in the next deployment, we can retain the configuration they have made.

How do you measure and benchmark how pods are doing? What metrics do you track? 

These are just some of the KPIs we look at:

  1. Throughput: How many story points are being covered, how many user story points are we can delivering, etc.
  2. Overall timeliness: Based on sprint deviations
  3. Defect ratio 
  4. Cloud cost for implementation

Do you support new users after a module was implemented?

We have user tracking on InCustomer, where the customer and we monitor the frequency of usage and how it measures up against expectations. If we observe a significant drop, we see what we can do to avoid that.

Before we close, what would you say is your superpower in your current role?

It has to be my team. They’re extremely talented -  throw any problem statement at us and we look at it as an opportunity. This keeps me motivated. I am a huge believer in continuous learning -  learning something new every day.

Another thing I’ve learned - Give your team the full picture, don't just give them a part - tell them why, and what the impact is going to be.

Summary and Takeaways

Besides the focus on value delivery and transparency - keeping the customer in the center at all times, Innovaccer’s engineering-focused approach to implementation stood out to us. Here is a quick summary of some of our key takeaways from the hour-long conversation with Ashish. 

1. Changes that moved the needle for Innovaccer

  • The Value framework makes it possible to set clear expectations and show what customers would get in terms of ROI.
  • Making the delivery process transparent with centralized visibility into progress and defects. The team became partners with customers.
  • Building for scale, using the concept of ‘pods’: A pod is a self-sufficient unit that can deliver implementation independently.  A pod includes a CS manager, data analyst, and a QA. 

Scaling the implementation team then becomes about adding more such pods. 

2. Role of the implementation team in the product roadmap

The product and the culture at Innovaccer allow configurability for the customer engineering team that performs implementation and onboarding for clients. The team handles all configurability, building out more connectors, etc, and adds them all to the product itself so that the new configurations are available to everyone for the future.

Join our private, invite-only Slack community and attend the next Implementation Stories session. You will also gain access to peers, get to share knowledge on customer onboarding, implementation, and customer success.

Industry insights you won’t delete. Delivered to your inbox weekly.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Kirthika Soundararajan
Content Marketer @ Rocketlane

All things content at Rocketlane. I run on coffee and cat videos. Follow me on Twitter @kirthikasrajan

You might also like...
Here are some other posts from us you may enjoy reading
Implementation StoriesApoorva, Branch.io on High-touch Onboarding for Experienced Customers
Apoorva shares how she designs differentiated onboarding journeys for different customer segments
Kirthika Soundararajan
Content Marketer @ Rocketlane
Implementation StoriesAlex, Freshworks on the Impact of Culture on Project Execution
Alex talks about implementation and onboarding success in a multi-geography environment having cultural barriers
Varun Singh
Product Evangelist @ Rocketlane
Implementation StoriesNimesh of Rockmetric on working with enterprise clients in finance
Nimesh Mehta, founder and CEO of Rockmetric, shares his honest reflections on his implementation journey
Varun Singh
Product Evangelist @ Rocketlane

Bringing order to your
implementation and onboarding chaos.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.