The failure rate for sophisticated support software implementations ranges between 25% and 75% and the difference is not so much in the facts, just their interpretation.

If you only include cases where the support software system fails to ever go live and is entirely abandoned, the failure is probably only 25% or lower, but if you include major cost overruns, production delays, failure to meet expectations and soaring post-production costs, the failure rate may actually be higher than 75%.

Choosing the wrong vendor is the single biggest reason for such failures, and also the easiest to avoid. In this white paper, we recommend a detailed process for picking the right support software company to ensure a successful implementation. To do so, we contrast the standard approach taken by most companies with a recommended enhanced approach throughout each step of the evaluation process.

The Safety in Numbers Method

Rather than performing a thorough comparison of support software, some companies make a quick, seemingly safe decision: they pick a vendor with the largest market share. Naturally, there are solid reasons for choosing a well-established vendor as opposed to a new start-up. Yet, going this route can introduce several risk factors. First, their market share may have been gained a long time ago with technology that is now outdated and a company with declining market share is inherently unstable. Second, market share is often achieved success by focusing on typical customers. If your company does not fit that profile, you might need to look elsewhere. Second, extensive marketing, rather than a superior product, might be the reason behind the dominance of such vendors. Finally, expect market leaders to charge a price premium simply because of their popularity.

The Risks of the New Kid on the Block

There are solid reasons for choosing a well established vendor, instead of a brand new startup that is dependent on further rounds of funding from the VC to stay in business: A well established vendor is less likely to go out of business, the software has had time to settle down and is less likely to be buggy and the vendor has had time to sort out its support/maintenance and upgrade processes.

In summary, unless you really need some brand new technology that is only available from a startup, you probably want to compare HelpDesk vendors that have been around for a while and focus on product quality/applicability and company profitability/debt levels rather than just market share.

Now, let us examine how each step of the selection process is typically executed and can be improved upon.

Step 0: Write Down the Business Objectives and Define the HelpDesk ROI

Buying, implementing and training your staff on the effective use of a new system is a time-consuming an expensive process. Do not start it until you have a clear idea of the business objectives and what processes you want to improve.

Write them down and discuss with stake-holders, such as the VP of Support. Solicit their input on the value of objectives that are not directly quantifiable. For example, if the VP says that halving the turn-around time for support requests will so improve custom satisfaction that it will increase sales by 10%, that is a metric that you can build into your ROI analysis.

The key is to base your HelpDesk ROI calculations on hard numbers, or the estimates of senior executives, not on your own beliefs. The support software may help to:

– Reduce costs and the time required to execute a process
– Ensure that nothing drops through the cracks
– Automate processes such as support follow-up and emails
– Eliminate data duplication and reduce the time necessary to find information
– Keep stake holders up to date with automated reports
– Provide customers with 24/7 access to submit/update issues and track status
– Provide a full audit trail for regulatory or internal compliance
– Gain insight into staff productivity and bottlenecks
– Integrate processes that span multiple departments
– Help turn support into a profit center through integrated sales processes

Once you have decided what processes are most critical, how they should work and the value attached to their improvement, you are ready to put together an RFP that describes what business processes your need the system to support.

Your goal is to choose a system that can fully implement the business processes that you have identified as most critical at a reasonable cost. Every vendor claims that their system will increase sales, reduce costs, etc, so it is only by nailing down the details that you will find their limitations.

For example, rather than saying “The HelpDesk system must assign tickets automatically”, you might specify “When a request arrives, it must be assigned to the support team for that issue or time-zone automatically; the rep should receive an immediate notification email with a link to view/edit the issue; this email and link should be accessible from their smart-phone; if the rep does not update the record within 2 working hours, it should be re-assigned to their manager…”

Step 1: Create and Send Out RFPs

Many companies send out long RFPs with qualitative rather than quantitative questions to an extensive list of vendors. There are two problems with this approach. One, asking such general questions omits critical data, such as specific time-lines, functionality, and limitations. Two, lengthy RFPs are time-consuming for both you and vendors. All of your effort will be for naught if you do not get equally detailed responses, and the truth is that many companies simply will not take the time to respond. Those vendors that do fill out such RFPs are often desperate for business or will charge hefty prices to make up for such time expenditures.

The solution is for companies to first send out a mini-RFP, which most vendors will complete. Figure out exactly what you want and take the time to describe it in detail. This document should ask your top 10-20 questions, be available in document and online format, and take 20 minutes or less to complete. Although the exact questions would depend on your needs, they should include:

  • Can you implement all of the business processes that are described?
  • How much will it cost over the next couple of years? (The vendor may need clarification before providing firm prices, but should be able to provide a rough estimate here.)
  • How long and how many consulting hours will it take to implement?
  • Can you try the system before committing to a purchase?
  • What kind of expertise is needed to maintain/change the system?

Eliminate HelpDesk vendors that do not respond in a reasonable amount of time and based on the responses you receive from the remainder, narrow down the vendor list to three to five. Tell these companies that they have made the short list and send them complete follow-up RFPs. Since these vendors will know that they have about a 25% shot of earning your business, they will likely respond.

Make sure that the questions in this follow-up RFP are probing and quantitative. For example, instead of just stating, “The system must allow the creation of custom tables,” ask questions such as the example below. As you will see, the exact answers can make a huge difference in terms of timing and cost.

How long does it take to create a custom table and what expertise is required to do so?

The truth is that creating a fully functional custom table can take anywhere from a few minutes to a few months. If the latter is the case, this can cost tens of thousands of dollars in consulting fees. Unless you ask explicit questions, the vendor will not provide such details.

Do custom tables behave exactly like native tables?

Probe even deeper with questions such as: Can you create links between custom tables and native tables? Can you search and create reports and business rules on fields in custom tables?

Can custom tables pose any obstacles to system upgrades?

The additional effort involved in upgrading a system with custom tables can range from “no impact” to exporting and re-importing all data, redoing the entire custom table from scratch, and praying that nothing goes wrong.

If you are unsure which probing, quantitative questions to ask to compare HelpDesk software systems, contact the vendors. Say to them: “I am pleased that you support feature X. What should I ask your competitors? I am trying to determine how fully the vendors that I am considering support this feature and whether there are any limitations or additional costs associated with its implementation.” What they tell you will expose weaknesses among their competitors and, possibly, themselves.

Step 2: Ask for Demos

At this stage, most companies go one of two routes for a HelpDesk demo. The first is to attend a “standard” demo that allows the sales person to display the parts of his system that he wants you to see and allows him to mask the weaknesses by simply not showing them. The problem with this kind of demo is that it does not tell you whether or not the system is capable of actually meeting your precise needs, and if so, how much effort it will take.

The second route is to ask vendors for a demo of your complete desired solution. However, most vendors are not going to invest man-weeks in customizing a system to comply with such a request, so unless your requirements are simple, they will instead insist upon leading you through a standard demo.

Designing and implementing the full set of requirements and maintaining/enhancing the initial installation to reflect experience and address changing needs can easily exceed the cost of the software. Therefore it is critical to find out both how easily the software can be configured and how much help you can expect from the vendor when it comes to process and automation design. So what can you do to learn these things in a demo?

The solution is to twofold:

1) Give the vendors a limited amount of time to prepare a custom demo illustrating just one business process of your choice. Choose the process and requirements that are either the most critical for you or that you believe are the most unique to your organization. If a vendor can map these process, they will likely be able to manage the more standard ones. Limit the time to prepare the demo to something between one and five days, to see how quickly the product can be tailored to your needs. You may extend this deadline, but be aware that if it takes the vendor a week to meet your needs pre-sale, it will probably take at least that long after they have your money.

2) During the second half of the demo, ask them to modify the system to implement some other requirement. Warn them in advance that you will be asking them to configure the system during the demo. That way, they can have technical resources at hand. However, do not give them sufficient information so as they can prepare everything in advance.

If they fail to meet your stated requirements during the first half of the demo, you can skip the second half. Although this may sound brutal, it is completely fair: after all, you will be betting your reputation and, quite possibly, your company’s future on making the right choice.

An important benefit of using this process is that you will be able to tell, from the kinds of questions you are asked before the demo about your process and requirements, how easy it will be to work with the vendor. Do they exhibit a ready understanding of your needs and grasp what you are trying to accomplish? Do they ask questions that help you to formulate your process more precisely and make it more efficient? In other words, are they experts at process automation and design? Or are they just going to sell you a software package and leave you to your own devices?

During the demo, assess whether your staff could make such changes without their help. You can also measure the honest of the vendor. For example, assume your HelpDesk RFP asked two vendors how long it would take to create a custom table and one responded “five minutes,” but struggled to complete the task in 20 minutes. The second responded “30 minutes,” but finished in 25 minutes. You might consider the second vendor a more honest potential partner, or you might at least adjust the first vendor’s other RFP responses based on their tendency towards optimism.

Step 3: Get references

Ask for at least one reference from the vendor’s other customers and talk to them privately, without the vendor’s sales or PR staff on the call. If the vendor insists on setting up and joining the call, treat it as a very strong danger signal.

Tell the vendor that you are still looking at a couple of alternatives (even if they are actually way ahead in the evaluation). There are two reasons for this: You retain your leverage during the final price negotiation and the customer is more likely to provide honest feedback if the vendor has no way of knowing why they are not chosen. Even so, be aware that glowing references cannot always be trusted, any more than such references about a job candidate are a guarantee of their future performance. They are just one part of your due-diligence.

Incidentally, you should entirely discount web-based references that are posted by “current customers” in response to on-line requests for vendor recommendations. These are almost all posted for the vendors themselves. Customer case studies at the HelpDesk vendor’s web site should be viewed with caution, but are at least they are honest about what they represent and may be trusted roughly in proportion to the amount of hard quantitative information that they contain. “We went live in two months” means something. “The implementation was really fast” doesn’t.

Step 4: Negotiating the Price

At this stage in the process, do not be blind-sided by “discounts.” You might perceive that you are getting a better value if you purchase a $200,000 solution for $75,000 rather than a $75,000 solution for $50,000. However, keep in mind that you will be locked into a pricey solution and the vendor will have full leverage, likely charging you full price for implementation services, support, upgrades, and additional licenses. Surely, the vendor will have a strategy for recouping the $125,000 “discount” with interest.

Still, you should not necessarily buy the least expensive product, but rather the product that will fully satisfy your requirements at a reasonable price. After all, software that does not satisfy your needs will be very expensive in the long term. Either it will fail to support your business or you will need to invest in custom software development and maintenance.

When negotiating pricing, avoid the following common traps.

1. Bait and Switch

Some vendors offer cheap or free entry-level packages that lack the functionality for successful long-term use. Their goal is to get you trained and committed to their system before you discover the bad news and have to pay to upgrade. You can avoid this trap by working down from their most expensive offerings and asking yourself at which point you will have what you need. After all, it is much easier to ask, “May I need functionality X in the future?” than “Can I think of functionality I may need that is not covered by this low cost option?”

2. Nickel and Dime

In a variant of the above, some vendors sell packages, then nickel and dime their customers for all extras. For example, “Software as a Service vendors may include so little disk space with their base offering that they know their customers will outgrow it within a few months and pay for additional space. You can avoid this trap by asking vendors to write down ALL “optional” extras and that they will not charge extra for any functionality not on this list.

3. Implementation Costs

In a practice that seems to have been learned from the construction industry, some vendors will lowball the estimate for implementation costs and then double or triple the actual cost during the course of the work. With each price-hike, they may say, “We are 80 or 90% of the way there, but there were ‘unexpected’ difficulties.” You can avoid this trap by initially detailing your requirements, asking for fixed price quotes and making sure that the system is easy to configure by your own staff

4. Maintenance Costs

Similarly to the above, some HelpDesk vendors will lowball the initial implementation, knowing that you will need to pay for changes later on. The standard metric in the software industry is that initial development accounts for around 20% of the cost, while bug fixing, support, and maintenance make up the remaining 80%. You can avoid this trap by ensuring that your team can customize the system themselves. If a vendors system is easy to configure, their consulting fees will probably be more reasonable; after all, they will realize that you are not at their mercy and could always do the work yourself.

In general, try to get a package or discount that will cover additional licenses and upgrades for at least the first year. Look at the list price and assume that once the discount period elapses, it will be close to what you will be paying. Then, finalize your detailed specification of the desired system and ask for a fixed price bid on the implementation itself. You may not get it. Still, it can make for an illuminating conversation when the vendor who estimated a two-week completion in their RFP response will not commit to a two-month completion on a fixed price basis.

Vendor List

The following is a list of leading HelpDesk vendors to which you may want to send the preliminary RFP. This is not an exhaustive list and additional vendors may be found at this site and sites such as,,

Be aware that almost all sites that prominently list or praise particular vendors are being paid by that vendor for such placement.

Right Now Technologies

There are four steps to finding the right vendor:

  • Figure out what you want and take the time to describe it in detail. You will have to do this eventually in any case and it will save you from making an expensive mistake if you do it up front.
  • Find a set of potential vendors and send a brief version of your RFP.
  • Narrow down the list of potential vendors and ask the remaining 3 to 5 vendors detailed quantitative questions in the full RFP. If you do not know how to quantify, ask the other vendors for their suggestions.
  • Get a demo of your desired process from the remaining contenders shortly after your provide the full RFP and ask them to make modifications during the demo. Ask yourself whether you would be able to make such changes without their help. Request a fixed price implementation and negotiate pricing for additional seats in advance.

Choosing the best support software vendor is critical. Yet, it can be challenging, but it is a lot less work than trying to make a bad choice successful after the fact. By following the above guidelines, you will greatly increase your chances of a successful implementation.

Leave a Reply

Your email address will not be published. Required fields are marked *