I often hear that selling should not be confused with implementing.
As with many such statements I hold two opposing views.
It is important to make the pre-sales process simple and ensure that the client understands the value of the solution that they are considering BUT equally important that the client understands the technical merits of the product and how they will implement and use it.
Don’t over-complicate the process but don’t treat me like an idiot.
Too many pre-sales people have only ever been in pre-sales; they lack operational knowledge and have no benchmark for the way that an organisation will work. I would not buy from someone who lacks the depth of knowledge and expertise necessary to deliver my project.
Pre-sales must prove they have the competency to implement my solution and guide me to use it: I need my pre-sales team to:
- develop the architecture for my solution
- advise me on the project plan; the whole plan including my activities – afterall they have done this before?
- articulate the assumption and likely risks they are making
- tell me what I must do to make the project successful
- lay out the milestones and measure of my project so I can judge success and risk
- work with me and my technical team to solve the inevitable problems that will arise during my project
How many of your suppliers are able to deliver this and how many of the pre-sales people are capable?
Customers buy technology for three reasons:
- to reduce cost
- to reduce risk
- to enable them to do something that they cannot do without the investment
If someone tells you otherwise you are entitled to raise an eyebrow and it’s your decision whether to show them the door.
Vendors and especially cool new tech’ loves to pronounce that they are visionaries or have unique intellectual property and disruptive technology [so what?]. It is all about value.
I work for a software house and even I glaze over when I hear these terms. At the end of the day if I cannot show how the technology is relevant, reliable and can answer , 2 or all 3 of the points above I would not expect you to show more than a passing interest.
Tranditional licensed software vendors talk about buiness value but their modus operandi is to understand a clients pain in order to establish the optimum price for their software. Their commitment to your business and demonstrating both the value in the product and benefit you will achieve from working with their team is often spoken of but I think clients want something more tangible.
An emerging band of open-source advocates will tell you that they do not make their money by license but from service, support and throught the innovations they deliver to make the open-source software easier to manage [which is still packaged as a product].
How do you prove that the software will support your business needs, determine that the vendor is a good partner who will provide the required level of service and also determine that they will be in business in 2-3 years?
- measure and track every interaction with the vendor from sales call through support
- make support calls during any evaluation and test the response and also whether they can operate in your timezone and language
- don’t let your technicians run an evaluation in isolation; they must test the solution and understand its’ architecture and how it will support your business
- IT REALLY IS ALL ABOUT HOW YOU PLAN TO USE IT – THE NUMBER OF TECHIES I SEE IN THE BUSINESSES I SUPPORT WHO ARE LOST IN FEATURES AND FUNCTIONS AND IGNORANT OF USE CASES IS REALLY WORRYING
- engage with service managers, line of business and end-users: develop use cases around how you plan to run this aspect of the business and even determine whether your supplier has enough vision to help improve the processes and even the capability to advise you as you deploy and mature
In parallel with the technical evaluation:
- work on the implementation and adoption plan
- establish the operating costs of the solution
- determine how you will partner and jointly deliver the value
- Create a realistic and defensible business case
- if it sounds to good to be true……….
- decide whether you can work with the supplier at all levels and especially whether you can solve problems in the bad times
- meet the leaders within the organisation and ask yourself ‘do I / can I trust them’
- develop a business case that you feel comfortable with; encourage the supplier to contribute but do not lose ownership and make sure you retain ownership
- prove that the software works; works in your organisation and is applicable to the way that your business operates [or will operate]
- expand the evaluation to the point that you can understand and share a vision on the overall solution, how it complients your goals and where you expect to have problems
- do not accept mediocrity. A supplier must show that they will go the extra mile – stretch every aspect of the suppliers service
- establish your delivery team and ensure everyone is aligned, competent and personally responsible for success
- do not delay but do not rush; if you do not know what the investment model or architecture is you are not ready to proceed
- if you cannot specify how you will address the use case or do not know how to transform the organisation do not proceeed in the blind faith that it will come together in a miracle
- hold your supplier accountable