In this session of Implementation Stories, we spoke to Soham Basak, who heads Delivery and Customer Onboarding at Darwinbox.
In this session, Soham talked about:
... and more.
In the rest of this article, we share the key takeaways from the session.
Darwinbox is an end-to-end HR-tech platform. It helps organizations handle employee lifecycle management, workforce management, talent acquisition, training, core HR (employee data storage, employee lifecycle events), talent management and development, and employee financials. The platform also has an analytics and reporting layer, which collates data to provide a consolidated view of what is happening within the organization’s HR ecosystem.
Soham shared that defining the intent of the HR transformation is the first step of every engagement with a new customer.
In their case, this begins by ensuring alignment on the usage of Darwinbox for digitization, not merely automation. This is important because the customer must also be committed to streamlining their existing processes and removing any redundancies in their processes in terms of practice, data, or policy. Darwinbox ensures that the customer knows that this includes re-evaluating every current process—even if it works well in the current context.
Lastly, they make sure to communicate that Darwinbox is a system that needs to be owned by the customer. Darwinbox does not need niche expertise or dedicated personnel/team at the customer’s end to handle and maintain it. Anyone who becomes an admin or a power user of the platform can own the platform without needing to depend on the Darwinbox team.
As Darwinbox entered new markets, they realized that most customers wanted something that they could readily use. This was especially true in the case of mid-market companies.
They developed a package of pre-configured practices and policies that these companies could readily use. If there are any changes to be made, they are incorporated into the system.
Since the primary intent is to enable the customer to do everything independently on the platform, Darwinbox follows a ‘Train-the-Trainer’ approach so that the customer essentially owns the entire platform, without the need to rely on the Darwinbox team at all—once they are provided the support, the material, the collateral they need.
The framework is divided into six distinct stages of delivery:
Typically, the process spans 4-5 months, with Elaboration being the longest and most important phase in the delivery journey.
This phase focuses on understanding who the customer is and identifying the project/delivery team from Darwinbox. This phase also involves identifying the audience in the kickoff meeting, developing the kickoff presentation, finalizing the project management structure, and sharing a high-level project plan with the customer. Approximately 30 to 40 hours of work happens even before the kickoff.
During this stage, there is an automated sales handover and a pre-kickoff meeting with the sales and pre-sales teams, after which stakeholder mapping is carried out. They match different stakeholders at the client-side with various people within Darwinbox to maintain relationships with them. This matching is not hierarchical and depends on the commonality in the system or between the relevant people.
A key aspect focused on in this phase is getting the customer to decide the measurable success metrics for the project.
This phase is focused on understanding the day-to-day operations of the customer’s HR team. This is done through different workshops or sessions. New recommendations are made and showcased in a controlled environment. Elaboration is done through a process flow diagram and by mapping gaps with leading best practices. If they find that the customer is doing something that is not in sync with the market, they highlight and discuss that deviation from the market practice.
The Darwinbox team ensures that they are transparent about what they can and cannot do on the product and have walked out of client implementations when there was a deadlock. This is one element that they have maintained even though they compete with giants such as Oracle and SAP, who make a lot of client-specific customizations.
Though they sometimes take in client requirements for the product roadmap, they make sure to call out that any dependencies on product delivery cannot define the go-live. This is done to ensure that future product/feature delivery is kept separate from project delivery.
The outputs given at the elaboration stage are sign-offs on all the documents and discussions of the different plans for the integration plan.
This is the most critical stage and takes up almost 40% of the entire delivery duration. One of the key attributes of this framework is sign-offs on every activity and documenting gaps at every stage.
The staging or test instance is set up in this phase as per the understanding received during the elaboration phase.
All clients are supplied with two instances: the staging instance and the production instance.
The staging instance is set up for the client to conduct their UAT. Any revisions in the process mapping (or the process documents) from the elaboration phase are done at this stage, though, as mentioned earlier, product delivery is kept separate from implementation delivery.
The primary output of the construction phase is a configured staging instance that is ready for the client.
In this phase, the customer team is equipped to run and own the system themselves. This phase also includes the train-the-trainer sessions where power users are trained to train their end-users.
The deployment of the integration pieces and customer UAT happens during this phase.
The platform is rolled out to the entire organization during this stage, and all the employees get their login credentials.
In this phase, though support is provided to customers, there is no dedicated Support team. Instead, customers are offered a support portal to log queries that are then taken up by Darwinbox’s support team. The support portal also has resources, including FAQ documents, product manuals, videos, etc.
After Production, Darwinbox offers 20-30 days for stabilization to solve any teething issues that might crop up. After this, they introduce the Customer Success team, which essentially owns the relationship with the customer throughout their lifecycle. The CS team also ensures that the success metrics that the customer laid down at the beginning of the project are being met.
They run monthly service calls and quarterly business reviews to showcase to the customer the adoption over a period, the volume of transactions, ways to improve adoption, etc., and keep the customer updated on new releases.
An important aspect of Darwinbox’s implementation is that it cannot start without certain inputs from the customer. This period where the customer teams need to collect all the relevant data for the project is called Week Zero—though the period may last anywhere from two days to two months.
In a typical 16-week implementation plan, the customer spends up to four weeks on activities from their end. During the delivery, 70% of the activities are done by the Darwinbox team. However, the remaining 30%—primarily focused on change management—needs to be carried out by the customer. The Darwinbox team highly recommends that the change be driven by the customer’s business or department leaders. Another key practice they recommend is incentivizing early adoption.
Though this is largely contextual, the Darwinbox team captures most use cases in a repository they share with the customer so they can borrow or use them if required.
Darwinbox’s implementation fee is a fixed price independent of time/resources.
Over the course of 650+ implementations, they realized that they had to force customers to have a specific subscription start date, regardless of go-live or usage.
In their current model, for customers with fewer than 20,000 employees, they include in the contract a clause that the subscription typically starts 90 days from the date the contract was signed.
When customers want to add modules or have another cycle of implementation, the Darwinbox charges a fee to run another round of implementation.
The team makes sure to communicate the nature and volume of effort needed from the customer right at the start. Another element they focus on communicating is the expectation of input data quality to ensure that the onus of providing clean and correct data lies with the customer.
As for customizations, Darwinbox steers clear of client-specific customizations. Even if a request is taken up for productization and added to the roadmap, it becomes part of the next version of the platform. However, they make sure to communicate that the product roadmap is independent of the delivery of Darwinbox as a platform and that product delivery and project delivery will happen on parallel tracks.
Like what you read? Join our private, invite-only Slack community and attend the next Implementation Stories session. You will also gain access to peers and can share knowledge on customer onboarding, implementation, and customer success.