When the economy is bad, businesses hold off on buying new enterprise apps and instead try to prolong the life of the ones they have. But there's still the significant expense of vendors' support contracts. Third-party support contracts may be the answer to reducing that cost.
Software vendors don't want to lose those support revenues, especially since they're making less in new and upgrade sales. Some even have tried to raise their support income through schemes such as tiered support (a debacle at SAP) or all-or-nothing support (Oracle's most recent approach to extracting nore money from customers) -- but doing so risks driving customers even faster to third-party offerings.
[ Demonstrating the high stakes of software support, Oracle won a victory years-long support-licensing legal battle with SAP. | Get sage advice on IT careers and management from Bob Lewis in InfoWorld's Advice Line blog and newsletter. ]
Software vendors will tell you that their support is better than the third-party support and, thus, worth the higher cost. Though it's true that third-party support is usually cheaper, it neither as feature-complete nor as up to date as vendor support.
Here's how to evaluate the third-party support option.
Is third-party support right for you?
The answer depends mainly on two factors, says Forrester Research analyst Paul Hamerman: where the application is in its lifecycle and how important it is for you to stay current with software upgrades. "If [a user] has an installation that's a couple releases back, customized, and difficult to upgrade, third-party support is a more viable option," he says. "If it's an expanding business or a new installation, third-party isn't a good option because you're off the enhancement pack."
If you are set with your software deployment, don't need to get software updates, and primarily want someone to turn to when you run into bugs, you're in a good position to take on third-party support.
What should be in the support contract?
Jason Mark Anderman, president and co-founder of WhichDraft.com, has negotiated many maintenance agreements and has even created one of the leading contract templates for software support. "You need to strike a deal that sets expectations properly and creates a strong sense of trust," he says. "If you don't have that, things often go wrong."
Perhaps the most important aspect of the service contract is that it clearly defines who is expected to do what, and at what cost. Will you be responsible with providing the service vendor with onsite office support? Is the support vendor required to address a bug, even if it can't reproduce it? Does escalating a problem also escalate the cost? The contract should explicitly answer these types of questions, Anderman advises.
Both sides should also be very clear on fees, when they are levied, and how much they will cost. Neither side wants surprises when it comes to money, so it is very important to define hardware and software resources, what actions will result in what charges, and how the payment process should work. "You want to set up a situation where it never comes to litigation," says Anderman. To do that, "you cover all your bases so that terms and procedures are clearly defined."
The contract should spell out exactly what happens when something goes wrong. If there's a bug, you want the contract to define the bug: What priority is it? Critical? Somewhat important? Easily worked around? Based on those priority levels, you need certain vendor resources to come into play.
If, for example, you have a major system shutdown, you'll want a rapid response. Your support contract should spell out the nature of that response -- a callback within one hour, the bug fix within a certain negotiated time period, and so on -- and make sure to specify whether this happens during business hours only or 24/7. "You need to establish hard deadlines for response time and correction time," Anderman notes. "If you can't get hard times for that, then you want 24/7 coverage with X amount of resources working on it until it's corrected."
Anderman recommends putting a requirement in the contract for a primary support contact or a project manager whose job is to coordinate everything and be the sole liaison with the support vendor. That way, you'll have a consistent relationship with somebody who knows what you need, you'll know who to contact, and your contact will be fully aware of any bugs that have been reported in the past.
This sort of one-to-one relationship is invaluable when it comes to getting problems fixed -- and it's something you're more likely to find with a third-party support vendor than with a big software vendor that also sells support for its products.
You should also think about the potential for escalating bugs up the support vendor's chain of command and how that escalation should work. Anderman notes that a clearly defined escalation clause can be a helpful provision in case a high-priority bug needs to be moved up the executive chain, perhaps even as high as the support vendor's CTO, in order to guarantee that critical bugs get the appropriate response.
How should you handle negotiations?
The basic conundrum of software support is this: You can spend a lot of money and get full support, or you can spend much less money for lesser support. But with good negotiations, you can get what you need out of a support contract, leave out the parts that don't apply to you, and save a nice chunk of change.
Before entering negotiations, Anderman asks two basic questions about the support vendor: "How bad does it want my client's business?" and "How big is the company?" These questions help him ascertain a support vendor's flexibility in negotiating a support contract. Big support vendors tend to be rigid, often preferring to offer set packages or otherwise dictating the terms of the contract to the customer. Bigger support vendors also have many more layers of management than smaller ones, so it's less likely the salesperson you're dealing with will have the authority to adapt their negotiating terms.
Smaller third-party support vendors are generally more able to wheel and deal than, for example, the support division at Oracle, Anderman says. These companies do nothing but offer support, so they typically are more willing to accommodate your needs.
But even bigger support vendors can bend a bit if they really want your business.
Regardless of size, if you have certain demands that a support contract must meet, a vendor that wants to land that contract will try to accommodate you. If a support vendor presents you a contract on "take it or leave it" terms, your choice is simple, Anderman says: Take it or leave it.
You can also try playing third-party support against vendor support. Go to the software vendor and ask, "This is what this other company is offering me; can you come with a better deal?" Presenting a company with a credible threat of losing your business can go a long way toward convincing it to make some concessions to keep you. After all, with the support revenue stream becoming critical, even big software vendors are learning the value of losing a small piece of that revenue versus losing the whole contract to a competitor, Anderman says.
Ultimately, what's most important is that you get your software support needs covered at a price that works for you. These days, you have many more options than just your software vendor to accomplish this goal.
This article, "Is it time to switch to third-party software support?," was originally published at InfoWorld.com. Follow the latest developments in enterprise software at InfoWorld.com.