There has been a great deal written about the sales process, the customer buying cycle and how to align selling with the customer's buying process. But most of what I've seen is still written from the seller's point of view. What's really going on behind closed doors when customers are making decisions?
We have interviewed countless senior technology and business executives in tier 1 and tier 2 sell side banks, brokerages and exchanges to better understand their internal buying processes. Here is a summary of our findings, along with some tips for how you can use marketing content to help influence each stage.
To simplify understanding, we've broken the process down into stages, but it's important to understand that the customer does not necessarily view their buying process according to these stages. They may see only 3-4 distinct stages in their buying cycle - awareness, evaluation, commitment and implementation.
The buying process generally begins as the client becomes aware of a problem or need. This generally starts with one or two people and gradually bubbles up in the organization. Individuals might begin an independent analysis of the problem and possible solutions, but this approach will not yet be institutionalized. Here, your content plays an important role in helping different parts of the organization develop awareness - help them identify and understand the problem from their perspectives.
As the early individuals gain enough understanding of the problem, they'll start sharing their thoughts. Once enough people are aware of the issues and generally agree with the business impact, the organization will assign resources to better research both the problem and potential solutions. This may be informal in small organizations, or a formalized process in larger enterprises. But in all cases, a team is formed to research the problem and figure out how to solve it. In some cases, a consultant may be engaged to help define the problem and recommend solution alternatives.
Vision of a Solution
Gradually, individuals in the organization will begin to gain a vision of how the problem can be solved. This vision will generally need to include one or more vendor products, internal development and integration with existing infrastructure and systems, plus an understanding of the need for internal or external resources to implement and run the solution. Usually, the vision will be vague and heavily influenced by one or more vendor solutions. Different individuals and different groups will be arriving at different conclusions, and opposing visions are probably developing.
Generally, a team will be asked to shortlist 2-3 options (may include both vendors and internal development). To do this, they may issue RFIs or RFPs, they will meet with sales teams, review product demonstrations, and try to come away with a clear sense of how each option would work in their environment.
Writing RFIs and RFPs is difficult and time consuming. Often, teams will look for ways to simplify this task. If a vendor can offer a template RFP as a starting point, teams will often use it, customizing and adding functionality based on their understanding of the requirements. But obviously, the RFP will be skewed to the vendor that provided the information at the beginning.
RFPs are generally designed to accomplish 3 things - evaluate the options to see what functionality can be included, understand the relative strengths and shortcomings of options based on the team's understanding of the problem, and gain a better sense of the costs. The team will use the RFP to create a short list of options.
Shortlisted vendors are generally asked to perform some kind of proof of concept. In some cases, this is a custom demonstration. In other cases, it's a trial. Generally, the client will go to some lengths to design tests for the functionality that is important to them. But that doesn't always mean they're testing all the functionality, or that the tests are reasonable. In many cases, they're designed to demonstrate a reasonable level of diligence in care from the decision committee.
During the evaluation process, the champions of the various visions will make efforts to sell their ideas to each other and to decision makers. For example, one bank we talked to had opposing visions for how to automate testing of their trading technology. The US QA team wanted vendor #1, and the UK team wanted vendor #2. Both teams had compelling reasons for their choices, and argued passionately for their positions.
During this process, champions of various options may look for ways to position their favored choice on top, they may look for ways to actively derail what they perceive as competition, or they may "lay low" and let the "cream rise to the top." While companies always try to make careful, logical decisions, it's important to understand that evaluation processes can be heavily skewed and is often fraught with emotion and conflict. This is a point where the vendor that does the best job facilitating internal selling can impact the decision, but it's important to acknowledge that the level of political influence each team has will weigh heavily in the resulting decision.
In most cases, at this stage in the buying process, a business case is required. If the solutions are priced under $100K, the cases are likely to be fairly informal and may involve just a discussion. If costs swell above $500K, a more formal process might be needed. The evaluation team may be required to make some kind of presentation of the business problem, risks of inaction, costs, how the products will be used, their plans for the overall solution, results of the evaluation, and cost justification. Sometimes, they'll need to produce an analysis of the total cost of ownership.
In many cases, the TCO analysis will win the deal if one vendor or an internal build option looks like it will have a substantially lower TCO. If your product has a higher starting price point, but you can demonstrate a lower total cost of ownership, it's important to provide content to demonstrate this.
Different organizations have different approaches for risk management. Some will be relatively painless and require just simple reference checks and legal reviews. Some have an approved vendor requirement that can be a fairly involved process. Purchasing, Legal, Compliance, and Risk Management may all be peripherally involved.
Generally, if this stage in the buying process is painful or time consuming for the vendor, it's doubly so for the client. So clients are unlikely to take a new vendor through the process unless they are convinced that the return will be well worth the personal cost. Sometimes, vendors can streamline this process by working with partners who are already approved vendors. But that also comes at a cost. Screen partners carefully before entering into these types of agreements.
While the contract signing is a "closing" event for the vendor, for the client, the process is not over, and the real pain may just be beginning. Now the client has to make sure that the implementation goes smoothly, that the product meets expectations, and that customer and workflow impacts are carefully planned and managed. Vendors who make special efforts to partner closely with clients through this implementation process generally come away with the most successful and least painful implementations. If you can demonstrate your ability to reduce implementation pain, provide content to explain how. It will help prospects overcome commitment risk and may help skew a decision to your firm.
For more information on the customer buying cycle, download "Thought Leadership to Support the Entire Buying Cycle".