How Pando onboarded 20 enterprise clients in two years

At Rocketlane, we’ve been conducting Implementation Stories, a series of interactive sessions with leaders working in customer implementation teams to understand their journeys, discuss challenges and approaches, and share best practices and learnings with the community. In one such session, we spoke to Nigamanth Srivatsan, Director - Customer Success, at Pando, a freight management SaaS company.

Nigamanth has been part of the team that executed implementation for their first client and since then, the implementation for larger enterprise clients like Marico, ITC, Nestle, Tata, and more. In this freewheeling chat, he shares his early experiences, the implementation growth journey, and lessons along the way. 

Note: The conversation has been edited for brevity and clarity.

Please tell us a bit about yourself and your work at Pando 

I’ve been with Pando for two years—heading delivery for nearly two years, before transitioning into a Solutions role. My post-MBA experience of nearly six years has been in Supply Chain which is why I was excited to join Pando in the first place.

Pando is a freight management platform, or a Transport management Software in supply chain parlance. The logistical spends of our client companies are in the range of 10% of their revenues—up to 1000 crore. This means that up to 1000 crore of freight spend has been traditionally managed using spreadsheets and emails. Considering this scale of spend, you can imagine the amount of work. Also, the supply chain is external facing, so there are a lot of other stakeholders and companies interacting with the process. 

This is where Pando comes in. Essentially, we digitize the supply chain for a company. In addition to freight management, we also offer additional optimization layers such as data analytics and network spread so they can leverage data to improve deliveries and efficiencies. 

How many customer implementations have you been a part of?

In the last two years, Pando has established the right product-market fit. We grew rather quickly—by enterprise standards—to 20 enterprise clients as of December 2020. 

What would you say is your superpower in managing and streamlining implementation?

I think I'll use the analogy from the movie Kung Fu Panda and say that there is no secret to the secret ingredient. 

If I had to think about it seriously, I think it helped that when I joined, I came with a fresh pair of eyes, so to speak—the freshness brought in the element of fundamental thinking. There was no baggage, so we learned what we did - ground up and with a common-sensical–thumb-rule approach. Only once we set down these processes, did we hire the next round of people. We consciously brought in a mix of talent—logistics people, implementation people, and people who have nothing to do with any of this directly. 

What did implementation mean to you then? Has that changed now? 

I think because we were learning from scratch, we were a little unclear about the product we had and what we could promise. So we were not sure what if we were overselling, and didn’t even know what was easy to build, what added value to the customer, etc.

I think, at an early stage, when you don’t have too many processes—internal and for the client—managing client expectations correctly is key. There was the element of bridging towards what was promised to them in the sales deck—we had to assure them that we could and would build that out.

It is important to build comfort and trust with the client and thinking about what would add value to them. 

Initially, we looked at it purely as an implementation exercise - getting the client live was the focus. After the first two implementations, we reoriented the team and our approach. We moved away from a project basis approach that focused only on timelines and delivery through a typical Blueprint > System Setup > Testing > Go-Live flow. 

The two big learnings after the first two client implementations would be:

1. Focus on change management: When you go live with a product, it is a fundamental change in the way the user operates; it is a huge change for them. 

This made us think about what we can do to make the go-live much smoother and ensure the client doesn’t come back with feedback later, or completely abandon the project later. We preempted this big change and created a system of 3-5 change management programs - run by Pando or the client. This also meant saying that we would not roll out our product to the end-user on go-live day 1, but effectively on day 1 after the blueprint exercise. This way people were used to the product for almost two months, so we don’t wait till UAT to get feedback. 

This focus on change management can be carried out through marketing or gamification. For instance, we incentivize the fastest user to create 10 indents, to build awareness and engagement. 

Dean Colegate on effective change management during customer onboarding

2. Shift to a Value Delivery approach: At our end, we wanted to rethink how we tend to think of a client as out of our focus after go-live. We changed the name of our team from Customer Success and Implementation to Value Delivery. This brings a clear focus to the team. 

At the blueprinting stage, we make sure to understand what the objective of our tool is by speaking to the CFO or buyer at the customer end - in our case the objective is mainly cost reduction. We ask them to share metrics and how they are currently faring on those metrics. 

We then proactively measure these when we go live. We send out a monthly mailer (that we internally call an ROI document) to the client to ensure they see and realize value. 

Doing that baseline and being transparent with the client is very important. 

Creating early wins with the First Value Delivery Framework

Do you charge for implementation? If so, how do you do that? 

Yes, we charge for implementation. Most enterprise clients are used to this and willing to pay. We do not have a complicated system.  We have different versions of various line items like “light” vs “heavy” touch across the spectrum, for instance, in training. We don’t “offer’ it to the client, we take a call based on the kind of organization—instead of confusing the customer with options. We end up picking from different tiers of implementation plans such as Gold or Silver, depending on the right fit for the customer.

When to start invoicing customers: before or after implementation?

How did you formalize the team or go about hiring?  What’s the right stage to do this?

We were two people handling two clients. Our third hire was six months later and consciously so. The reason is that for the new resource to go from zero to one—where we were—would definitely either be a struggle for the employee or eat up our bandwidth. 

We decided that a new hire should breeze through what we had already learned. We called these value delivery foundational activities and set these right before a new hire. Here’s what we did:

1. Set up and develop 101 documents for different stages: Example, Project handling 101 - that includes project hygiene, when to send MOMs, when to send PPTs, 101 Blueprint workshop - includes everything on workshops - how to run a blueprint session, whom to involve, etc. 
2. Standardize project documentation: The language and style vary across project managers. Since all project documentation is sent to the client -  we standardized them and created boilerplate versions that had all possible combinations. 
3. Documenting and sharing FAQs for all modules: We added FAQs from previous implementations in all our customer documents. We'd seen these questions kept repeating and were often addressed in ad-hoc ways. 

We also added a dedicated section for the client to add in their questions - in addition to these existing FAQs. 

Setting up your first customer onboarding team

What have been the most impactful tactical changes in your process?

1. Clearly identifying client inputs and our outputs till go-live: This meant clearly outline our deliverables of each milestone and clarifying the client inputs. We ensured that we communicated that our outputs would not be delivered unless their inputs were given. So, we made sure to lay these out very clearly.
2. Having regular steering committees: A steering committee was set up with senior members on both sides - at the COO level. We built a cadence where we meet every week - irrespective of progress. Even if things were on track, these meetings would still be conducted. We set objectives with the steering committee - the project metrics, the business metrics, setting the process.
3. Placing ownership on the client - This includes all the activities including change management, bringing in KPIs for certain people. On the client-side, there are project owners (or a committee) that implements the project and the business owner (or core committee) in charge of rolling it out.  Since the project team is focused on usage while the business team focuses on the value derived through your product; the KPIs for each of them should be tabled as part of the kickoff. 

Getting estimation right and winning over customer expectations

What is the communication protocol post-handover?

Great questions,  I had these questions myself - since I didn’t come from an implementation background and we didn’t have a value delivery approach in the initial days. 

In terms of frequency: 

1. Before go-live, we were in touch every day, once a week, at the very least - even if everything is in the green. 
2. Post-implementation: At least once a month, a one-pager ROI followed up by a call
   

First, in SaaS customers need to know now what value they are deriving from our product. So, we send them these auto-captured metrics, say the freight cost moved via Pando, etc on a monthly basis. This is more of an assurance.

Second, these conversations, beyond upselling or cross-selling, keep us close to reality and help us build other things we can offer our next customer. For instance, with our client Marico, we had nearly 17 change requests even six months after go-live, and we worked on them because they would solve critical and urgent problems for them. 

While on the subject of change requests, how are these handled post-go-live? 

We have a process involving a Product Council, that compromises senior leadership such as the founders, head of sales, etc. Any request gets recorded in a product council request followed by a discussion - after which, the product managers take a call. This Product Council meeting minimizes the tussle between product and implementation, and most importantly, brings in the perspective needed in such cases. If the product council says no, it is a no. 

We have also realized that it is good for the client also to be aware of and understand our internal practices. For example -  our clients also know that new requests have to run by the project council and that their decision is final.

The way I see it - it is good to remember our role enabling getting people into the same room to enable decision making, and sometimes that’s all we can do. 

What to do when your sales team overpromises to a customer

But, what is it is a yes -  but there is disagreement in priorities?  

Here, again, what has helped is the customer understanding our process well. For example - we then go back assuring them that it is on our roadmap but not on immediate priority. 

In case, they insist on still prioritizing it immediately, we charge them for the said request. We’ve seen that with large enterprises, if the feature is really of value, they are okay to pay, and in some cases, this either puts things in perspective for customers or helps us push back. 

At Pando, this aspect is handled by the sales team and not the implementation team.  

Since your system integrates with ERPs or third-party systems which can sometimes be like a black box to you, how have you evolved for this?

So, there are steps we have taken and steps we’re still working on. Here are two things we’ve already done:

1. Making the requirement document extremely clear - an integration guide very similar to API documentation — in a common language that a functional consultant can understand. 
2. Conducting daily standups with the integration partner along with a phased deliverable plan for us -  that way, they roll out a testing plan for us.
   

What we are currently doing: 

We realized that it is important for third parties to understand what we do and own the end-to-end integration themselves.

This was not the case. For example - if they were testing SAP to Pando, their testing would end at the entry point to Pando and not further to see if it has entered Pando.

Now, we will give them training about Pando and where the data points are to be seen, and what they would be. They don’t need to understand all of our product but instead the importance of those data points. 

This way, the third-party project-manages end-to-end and drives the UAT conversation with the client.

Takeaways

We loved how Pando’s journey from 0 to 20 has been focused on the value for the customer and looking at implementation beyond just delivery and go-live. There are lessons and takeaways for all of us - a shift to value delivery, focus on solid processes at every step, and customer relationship-building. Here are some of our key takeaways from the conversation.

1. Go-Live is not the Be-All and End-All - Change management and getting the results/outcome, etc cannot be left to the customer. The focus needs to be on value and ROI for the customer to ensure adoption and recognition of value. 

2. Value delivery, beyond just implementation -The focus on value delivery (starting from changing the team/function’s name) sets the focus on value and understanding baseline and expected value from the implementation. 

3. Change management -Adoption is a big change for the user. Giving early access to the product and using gamification and marketing to get people accustomed to the product even before integrations and go-live. 

4. The importance of  making the customer “own” the product and outcomes - Keeping the customer project team accountable for a successful roll-out and adoption through KPIs, and the business team tracks and realizes actual ROI from the product. 

5. The role of the steering committee- Setting up a committee comprising the key executives and sponsors of the project to ensure that functional owners take ownership of the metrics and KPIs. This creates a win-win situation and ensures that there is the alignment that ensures that everyone is focused on not just the project completion but also adoption and delivering results from it. 

6. Value delivery foundational activities: Documentation and Templates- Crafting strong implementation plans and integration guides documents that cover every scenario has helped newer employees and the customers. 
   A good idea is to include FAQs from previous clients in all modules and templates so that every new customer benefits from the clarity that has been shared with earlier customers, and the team doesn’t have to expend energy making the same clarifications over and over

7. A Product Council for Change Request Management - Instituting a Product Council comprising product leaders, founders, and head of sales, that meets on a bi-weekly cadence to discuss new request handling and prioritization.

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.