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.)
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.
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.
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.
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.
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.
In our customer environments, data centralization is a tough ask. The implementation team gets two kinds of data
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.
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
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.
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.
This is where the relationship progressed from a vendor-client relationship to a partnership.
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.
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.
These are just some of the KPIs we look at:
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.
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.
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
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.