IT Pre-Sales What & How I completed a three year stint in a Pre-Sales role at Oracle and moved to a new role

e outside. Here is my attempt to encapsulate some of the knowledge I gained over the years as a pre-sales consultant. Who is a Pre-Sales Consultant? If you look at the Sales Organization of an IT Software or Services company, there are two very critical roles: 1. A field Sales/Account Management role 2. A field Pre-Sales role. There are many other roles that play a part in a Sale, but in my opinion these are most critical roles simply because they work closest with the customer in converting an opportunity into a firm order. A Sales person/Account Manager is typically a quota/target carrying person, who is primarily responsible for bringing in business to the company. He would be the primary contact for the customer. While he is responsible for the sale, he typically will not have an in-depth knowledge of the products and services being offered. A Pre-Sales consultant brings this knowledge and is responsible for pitching the solution and convincing the customer that what your company is selling is the best solution that he can get in the market. What are the work products of a Pre-Sales consultant? Some people tend to equate a Pre-Sales role to a Product Demo role. While demonstrating a product is a critical aspect of a pre-sales consultant job, it is not the only thing that you do in this role. Some of the hard deliverables are: - RFX response (RFI, RFP, Tender etc) - Solution Presentation - Solution Demo - Proof of Concept delivery But there are many soft deliverables as well: - Objection handling - Return on Investment (RoI) assessment - Explaining how your solution is better than competition - Understanding what is important for each stake holder/decision maker and pitching in those things during various stages of customer interaction If you ask me - the job of a pre-sales person is to convince the customer that what you are offering is the "right solution" for him. It is the Account Manager's job to convince the

customer that he is getting it at the "right price". Having said this, the key focus of this blog post is: How one needs to engage with a customer in the run up of a solution presentation or demo. What are the various Stages in a Pre-Sales Engagement? Some of the key stages of a Pre-Sales engagement are: Discovery Solutioning Responding to RFx Solution Presentation/Demo Ofcourse, these stages are not sequential - there will be lot of overlap between subsequent stages. DISCOVERY This is the most important phase of the process and at the same time most neglected. Your objective at the end of the day is to sell a software product or a service. But what customer is interested in how you are going to solve his problems. So it is very important to first understand what the customers problems are. One of the important objectives of this stage is to understand customers Pain points/ Problem areas/ Improvement opportunities. Apart from this you also assess, who the key stake holders are, their motivations etc. Typical examples of problems are: - It takes a month to close my books - There are lot of adjustments I need to do in my books - Sitting at Head Office, I do not know how much inventory is available in each location - My data is not reliable - Etc. It is very important to know these because when you do your solution presentation, you need to refer to these. It is important that customer sees that you understand their problems. If he thinks that you understand his problem, there is a greater chance that he believes that you can solve those problems. Visiting the customer and interviewing the key stakeholders is the most effective way of Discovery. However this is not the only way. It can be done over phone. It can be done by talking to people who worked with the customer before (like your Partners or Consultants that worked on some other implementation or other pre-sales consultants or account managers if this is an opportunity that is open for a long time etc.). Nevertheless do not pitch in any solution without a Discovery.

You would find yourself in situations where the sales person would ask you to go and do a presentation/demo to the customer in your first meeting itself. The refrain could be: - It is only a standard demo/presentation that you need to do - Tell me what you want to ask the customer; I can help you with the answers - Customer is not open for such an engagement - I have already committed for this demo etc. Do NOT fall for this. It is better to have an unhappy sales person, than to go unprepared for a solution discussion. Your objectives from Discovery are: a) Map the people a. Identify a Coach b) Understand Problem areas c) Understand Business Processes d) Understand As-Is system map Having done your Discovery, the next step is to put together a Solution. SOLUTIONING / SOLUTION CREATION If you are selling Products (as opposed to services), you would be identifying the list of products/modules that you would want to position to the customer. But solutioning is not about identifying a list of modules. It is about identifying solutions to map the businesses processes / problems that you identified during Discovery (or to map the requirements given by customer as part of his RFP or tender). I think the best way to do this is: - Identify the critical business processes - Prepare a simple flow chart/block diagram for each - Prepare a fish bone diagram of sorts to link the blocks in the process flow diagram to various problems that customer is facing in that business process - Super-impose the features/functionalities of the solution that you are proposing on the diagram - Close out with the list of modules/solutions that you are proposing for that business process - Repeat it for each business process This way, customer would understand why you are proposing the particular solution. In parallel with the solution, you might have to respond to an RFP put out by the customer. RESPONDING TO RFx

Chances are, you would be competing with multiple vendors to win the contract. So customer would release an RFP (Request For Proposal), typically giving a list of requirements. If customer is evaluating an ERP, then most often the RFP would have a long list of features on which he would expect you to respond with a - Available out of box - Available with minor customizations - Available with major customizations - Not available My experience is that - responding to such a list is the most time consuming and at the same time least useful (for you as well as for customer) part of the sales cycle. The thing is most vendors tend to respond to such an RFP in a way that it looks like most of the requirements are met out of the box. And it is really difficult for the customer, even with a consultant advising him, to know the truth of the response. So it ends up that - the respondents would only differ by a few %age points when evaluated on such a list. And so it won't really help in deciding between the vendors. At best, the response will come handy to hold the vendor accountable during implementation. But vendors would always find ways to explain their response in the light of whatever limitations were found during implementation. If I were a customer or a consultant advising the customer in evaluating the solutions, then I would instead list down the key business processes and ask the vendor to identify if the business process can be mapped and how it is to be mapped. To understand what I mean, look into a tender released by CRIS (part of Indian Railways) for a Maintenance Management system. (I am searching for the URL of the tender. Will provide it, if I can find it) TO BE CONTINUED