Just like you don't want to loose any customer getting in business to you, no customer would like to loose a service provider who creates value for their business. Customer retention is all about Delivering Value to the customer. Sometimes it is about understanding and delivering what the customer has asked for, and sometimes it is about proactively figuring out what the customer needs and delivering the same.
Let me try to put this together with a small example from the top of my head.
One of our customers had a BPM tool and they were integrating their product with multiple third-party CRM, ALM and SCM tools to push the product in the market. We signed the contract with the customer to integrate their product with a CRM tool. Before the project came to us, the customer’s product had already been integrated with a leading SCM tool and we had to start from that source base.
The customer had no requirements for creating a reusable design with respect to supporting multiple integrations. Somehow, the customer had carried an opinion that writing mostly independent code for different integrations will keep them in a better place to manage the code better in that he would have the flexibility to change one integration without worrying about the other integrations. So, we too didn’t carry this discussion forward as it was not the right time considering the facts - 1. Our team too didn’t know what were the variables of the equation and 2. There was no proper working code as a base for the discussion.
Here is how we approached this problem:
- First, we focused on these variables:
- How the existing integration was working?
- How did we need to integrate the new tool?
- For the new integration work, we implemented the necessary design principles like reusability, abstraction, error-handling and fail-safe and other things which were not respected very well in the previous integration that was already done. The new integration started working well and another tool was added to the product’s integration chest.
(As a side note - Because of the way the code was organized, a few of these things, with minor efforts from our side, came as a bonus for the existing integration. Not every single task can be billed to the customer if you are really worried about Customer Delight and Customer Retention.)
- Following this, we had a discussion with the customer on the need for reusable and extensible design - now with some working code as a base, and it was the right time for the discussion. Technically also, we had understood what precisely were the design improvements to be made.
- We worked out the details and implemented a reusable architecture for integrating more tools with the customer’s product.
From technical point of view, this example is about identifying and weighing the design decisions based on what-to-do, when-to-do and why-to-do as we discussed in the post - Business-Driven OR Fact-Driven Design. The rule of ‘Don’t change the working code’ didn’t apply here considering the ‘Return on Investment’ if it is overruled.
From business point of view, it is about identifying what the customer needs and Delivering Value to the customer. Again, this project is not one of those fortune-turner kind of projects that we handled, yet it carried some business importance and for a service based vendor, unless there is a very strong reason, every customer is as important as the other customers.
Does your team understand the customer's business enough to identify what the customer needs?
Do your team's decisions on the technical aspects, also consider the requirement of delivering business value to the customer?
(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)