Written by: Sanjutha Ravindrakumaran
How does INFORMATION ANALYSIS supports ‘solution-driven approach’ for software solutions?
I hear people say, “Selling software products won’t work,” “Software products are the hardest ones to sell,” “How can I sell a software product by just describing it?” I agree. You can’t sell a software product! You should change the approach how you should sell…err…provide a solution and must keep in mind that it’s not about selling a tangible product. The selling approach should be solution-driven and not sales focused.
Being solution-driven is undeniably important. There is absolutely no reason to say that a product couldn’t be successful unless it’s was just presented as a mere idea or plainly described. We may also think that software solutions can’t be sold which gives impact to the fact that software products are intangible—not simply experienced by just mere touching.
This is an extremely lousy way to run a business. Anyone who’s coming up with an idea and thinks he/she should take it to the market really needs to focus on the solutions instead of the problem.
In terms of software selling, it requires extra effort. Let’s say ‘Information analysis’ is a part of the solution-driven approach. It may be an unfamiliar term but it would be the perfect terminology for ‘business analysis’ when it comes to the software’s solution-driven approach consultancy before signing up with the sales.
Will you pay for a solution without experiencing or testing it? That’s where pre-sales (sales support with technical-based approach) comes into the picture. Also, the information analyst gets involved in here. He/she will contact a sales person and may engage into the project as well, if it’s a solution to be developed from scratch. Though product-based solution is the main focus, an information analyst should understand that it won’t be ideal to provide the solution during consultancy. The he/she should be well-equipped with the product-based knowledge. One should go out of the box: gather and analyze information, focus more on business pains and gains, talk more, plan, design, consult, check the solution’s infrastructure, recommend the it appropriately, implement it with an approval, and most importantly: provide post-purchase support.
Speaking of post-purchase support, how many of us provide solution and get rid of clients’ contacts? Is it fair? If it’s a tangible product with a user guide, you may get out of the buyer’s circle. But what about the situation where the users are not THAT knowledgeable with the solution?
Always remember that not all buyers of a solution, especially of software products, are tech savvy. They might purchase a solution not because of the technicalities it can add up to their workflow but primarily for its functionality, which should be well-delivered to them.
So be open for their questions, confusions and troubles in maneuvering the solution you provided them. As for solution providers, each of their employees should be highly knowledgeable from the solution’s basics, and if possible, to its technicalities. This will not just prepare them for future extra mile assistance they can give to customers but will also see the product as a moldable subject for improvement.
Question: whose responsibility to check the internalization of the solution, the top management’s? The answer is NO. Since the project team conceptualized the solution, it is all their accountability. Also, who is in charge with the delivery and efficiency of the software solution? It’s the project manager and his/her team. He/she has to ensure the project delivery and execution is successful. Just going and implementing the solution at the client site or signing off with the UAT won’t bring in a successful delivery. It has to be internalized by the customer. Post- purchase checkups and support are very important.
As a practice, we do provide SLA and SA, with cost or as FOC. But in reality, we do get into the client’s purchased solution in times of technical problems. We still plan for the first level to the next levels of support matrix.
But what about for the assurance whether the users are comfortable with the solutions or not? Do you expect users, with limited fluency in computer technicalities, won’t be fed up with unknown/unfamiliar solutions provided? The answer must be a big NO. The head of the project will not be the only one responsible to ensure the quality and efficiency of the software solution. Still, I would say, though they are users of the provided solution, it’s all of the project team is responsible. When planning on a project, it’s a must to strategize post-purchase support and the timelines for its success.
The solution’s smooth delivery and the project’s success are in your hands. It’s all about how you do it, not on what you do. Just keep calm, then responsibly and properly deliver the solution.
