Negotiating the Contract


Down to the nitty-gritty. You are satisfied with the product, the references checked out, and now you're ready to sign. Well, almost ready: you should pay careful attention to the terms and conditions you are agreeing to, especially since the contract is likely to tie you to the vendor for a long time.

Warning: I'm not a lawyer and if there is ever a time to get your legal department involved, it's when you negotiate the contract. Do not rely solely on the recommendations listed here.

When Should You Negotiate the Contract?

It's impossible to complete contract negotiations before you complete the evaluation process, and it's also silly to spend time negotiating contract terms before you are fairly certain that you want to proceed with a particular vendor, so wait until you have a short list to negotiate the terms. However, request a standard contract from the vendor early in the evaluation process so you can get your legal department to start working on terms you want to change. Be ready to negotiate as soon as you are reasonably sure you want to select that particular vendor.

Negotiation is partly a game of patience, so it's important to strike a good balance between reaching an expeditious conclusion and getting what you want. Vendors are remarkably flexible at quarter-end, and even more at the end of their fiscal year, both on prices and on contract terms. Take advantage of these deadlines to facilitate a fruitful yet quick conclusion.

In brief:

  • Get the standard terms during the evaluation phase.

  • Get the legal team engaged as soon as you get to the short list stage.

  • Don't let up on negotiations even if you are thrilled with a particular tool: you can get a bad deal on a great tool by failing to obtain favorable terms.

  • Schedule the purchase for quarter-end.

Who Should Negotiate the Contract?

Contract negotiations are usually dictated by your organization's rules and customs . Do accept the help of the purchasing and legal groups; they have plenty of practice and they often find angles you would not have thought about. If they need to formally approve the purchase, you'll be better off if you involve them early.

On the other hand, purchasing groups may not grasp the business requirements behind a particular vendor's selection, and legal teams are notorious for fostering complex contracts, so you can't simply abandon the process to them, unless you are comfortable waiting a few months for a signed contract. The best strategy is to create a small, focused negotiation team with representation from the legal and purchasing groups and the CRM project team (typically the project manager, although the IT owner is often a part of it too). It doesn't make sense to involve the entire CRM team in the negotiations, especially the super-users and the IT staffers , except perhaps as advisors on specific points, and even that is unlikely .

If you buy at quarter-end or fiscal year-end to get favorable terms, as discussed above, make sure that your legal department is indeed available to you at that time.

Contract Points to Consider

Be careful with standard contracts, as they are always written to benefit the vendor. If you are making a small, straightforward purchase, a standard contract may be just fine, but most CRM purchases are neither small nor simple. Here's a list of points to consider.

  • Are all terms clearly defined? One of the very critical items is the definition of a user , since it drives the price structure in most cases. Is the vendor using named users (you have to buy a license for anyone using the database, even if they only log in occasionally) or concurrent users (you buy licenses to cover as many users as will use the system at the same time)? The method doesn't matter as long as it's clearly defined ”and of course you should expect to pay more for a single concurrent seat compared to a named seat.

    Pricing may be based on all kinds of other parameters, and they should all be clearly defined. I've seen pricing based on sales volume, number of customers, and number of support issues. Be sure you understand how the pricing is computed and what it will mean for you in the short term and in the long term .

    What is the effective date of the contract? The effective date often drives lots of other items such as the start of the warranty and the support contract.

    What are acceptance tests? Who conducts them and who audits them?

  • Who is licensed to use the software? Can the software be used anywhere in the world (it better be if you have or plan to have overseas offices)? By subcontractors ? By a subsidiary or acquired company? What about an outsourcing partner if you use one for telesales or support? What if your company is acquired or reorganized?

  • What if something happens to the vendor? Contracts are all about laying out what happens when things don't work out. Check what would happen if the vendor were acquired: the license should survive the event. Contracts sometimes call for some kind of code escrow arrangement as protection if the vendor disappears altogether, although it's not clear to me what you would reasonably be able to do with the code.

  • What products are included? Vendors often combine their products in many different packages, so double-check that you are purchasing everything you need but no more (there's no need to pay for the CTI integration product if you are not interested in a link to the phone system). Vendors typically list the licensed product as an appendix to the contract, usually Appendix A.

  • How is compliance checked? Try to avoid forced audits that can disrupt your business operations. It's entirely reasonable for the vendor to want to check that you remain within the constraints of the license, but it should not create big problems for you. Most software does not include automatic compliance checking mechanisms so audits may indeed be required.

  • What happens if usage goes up or down? For traditional (licensed) software, you need to buy additional licenses (usually at list price) if usage exceeds what you have purchased, and you continue to pay maintenance for the number of licenses you purchased even if you are not using all of them. If you are pre-paying for users or products that will be deployed later, try to delay paying maintenance on them until they are deployed. If you anticipate needing more users or more products, you can try to get favorable terms in the contract. We'll come back to this point in the next section. What's important here is that the use of the product not be blocked because you are exceeding the licensed levels.

    If you are using ASP software, you should be able to pay lower fees if your usage goes down. Make sure you understand the formula to adjust the payments up and down.

  • What exactly is included in the warranty? Many standard contracts essentially include no warranty. The software is what it is when delivered, and the only remedy is some kind of best effort, such as delivering fixes or workarounds on reported issues. Try to get a money-back clause if serious problems are discovered during the first few weeks or months. This is very hard to get because it creates revenue recognition problems for the vendor.

  • What happens at the end of the license term? If you are purchasing a limited-term license, try to get some commitment for what happens at the end of the term. If you are getting a so-called perpetual license, you should be able to use the software for the life of the product, but even products with perpetual licenses are sometimes sunsetted.

    If you are working with an ASP, are there any termination fees? How will you get your data back?

  • What is supported? Vendors usually provide support for the latest release, including bug fixes, and the one preceding it, but usually excluding bug fixes. Make sure you understand how releases are numbered and what constitutes a new release.

    Is there a guarantee on how long releases will be supported? You don't want to be forced to upgrade at a time that's awkward for you.

    Check that the particular technical environment you want to work in (hardware, operating system, database, web servers, etc.) will be supported for the foreseeable future with adequate provisions as those vendors upgrade. The IT owner should be able to help define what's required in this area.

    Finally, check whether licenses may be transferred from one environment to another as required. For instance, you may want to change the operating system you are using but continue to use the tool. That should be possible at no cost to you.

  • What is included in the maintenance contract? Many high-end vendors bundle maintenance releases and new releases with support, but only for the particular products that were purchased. Some particularly unique new features may be packaged as separate products, for which there will be a separate fee. Make sure you understand what is included in the maintenance fee because you will need to work with it for years .

    If you are using an ASP, what is the process and schedule for upgrades? Will you be forced to upgrade at a time that's convenient to the vendor or do you have some leeway?

  • What is included in the support contract? This is just as important as the maintenance issues, and for the same reason: you will be living with the support terms and conditions for years. Many vendors put the support terms and conditions (Ts and Cs) in a separate appendix.

    When it comes to support, you typically will have a choice between several packages. It's usually easy to switch packages when needed so you can select the one that best matches your current needs, but confirm the pricing strategy for higher-level support packages to avoid unpleasant surprises . For instance, if you need business-day support during the implementation and 24x7 support when you go production, it should be possible to upgrade the support contract at the time of the rollout for a reasonable fee. It may be cheaper to purchase 24x7 support from the start if you can get a better overall discount that way. Ask.

    The support package determines support hours, the number of individuals allowed to contact support, how quickly your requests will be attended to, and whether any account management or proactive support will be available. You will notice that the support Ts and Cs are pretty vague about details and focus on just a few things, typically speed of response and bug fixing strategies. It's usually easy to attach the support datasheet to the contract and to refer to it for specific commitments.

    Speaking as a not-yet-reformed VP of Support, I would advise not pushing too hard to get basic support Ts and Cs changed, for the very simple reason that in most companies the systems and processes in place are unable to accommodate exceptions. If you absolutely need a 45-minute response time when the commitment is for 60 minutes, save your breath and ask for a bigger price discount instead, or whatever else would make you happy. While you may be able to get the 45-minute response time enshrined in the contract, chances are that it will not be honored in the long run. It's not that the vendor doesn't love you; it's just that support works best as a large, one-size-must-fit-all machine.

    That being said, there are lots of interesting areas to check with support including:

    - Online self-support: is it available? Is it mandatory as a substitute to having a live person available? Are all contacts with support constrained through electronic tools?

    - Any limits in the number of issues you can get support for. For high-end systems, support is almost always unlimited, but mid-range vendors sometimes limit the number of issues you can log over the course of the contract. Try to get an exception at least for the first few months since you may have many questions at the start.

    - Support contacts: many vendors restrict the number of individuals allowed to contact the support group in an effort to minimize the number of requests and to increase the knowledge level of the people allowed to contact support. Vendors sometimes require minimum training requirements for the technical contacts.

    The number of allowable contacts and their qualification requirements are highly negotiable, so go for it if that's important to you.

    - The hours: if you are buying a round-the-clock contract, known as a 24x7 contract, does that include all issues, or just priority issues? Who answers the calls at nights? On weekends? On holidays?

    - The priority-setting scheme: in this day and age, you should be able to set your own priorities, but old-style vendors still insist they know best. Note that the priority of a support issue determines the response time, but not the resolution time. In addition, it has a very loose relationship with the priority attached to any underlying bug (politely called product defect in contracts).

    - The response time, that is the time it takes to "get through" to a human being capable of starting the troubleshooting process, either by phone or electronically . Modern support-tracking tools give the customer an immediate confirmation of electronic requests. This is very important, but does not count towards the response time since nothing of substance is accomplished through this acknowledgement . The response times are usually stated as targets (the vendor tries to meet them) rather than commitments (if the vendor doesn't meet them there is a penalty of some sort ). Is the response time for emergencies good enough for you? Buying up (to a higher level of support, that is) may get you a better (shorter) response time.

    As discussed earlier, it's not worth negotiating for better response times so stick with what's offered and get your jollies somewhere else.

    - Resolution time commitments. Although vendors typically have response time targets, they usually do not have targets for resolution time. Resolution time is what really matters if you think about it, since you want your problems to be resolved as quickly as possible. The reality is that some problems may never be solved at all, and some may take days to work through. I would personally be wary of vendors that give absolute time commitments for resolution since it's simply impossible to guarantee such a thing with software.

    However, you can work on mitigating strategies, including an escalation path to the vendor's executives in case of a serious problem. Automatic escalations based on the age of the case are not bad, but you should try to get a list of individuals that you can call if issues are not resolved to your satisfaction.

    - Access to a senior-level group. When you select a higher level of support you can sometimes get access to a dedicated support engineer or a group of such individuals. The benefit is that you get to talk to people who are more knowledgeable than the average support rep. If the group is small enough they get to know your particular environment, so the diagnostic process is faster. All great in theory. In practice, such high-level support groups may be quite "virtual," so don't fight too hard to get that special access unless you can validate, perhaps from the references, that there will be a tangible benefit to you.

    - Proactive support. Standard support contracts are reactive: you call, they respond. If you want proactive technical account management through which you get regular briefings, case reviews, and proactive information on new releases, you typically have to pay for it. Proactive support is often bundled with dedicated support engineers , although it doesn't need to be. If you choose this option, be sure to specify the deliverables: are the briefings scheduled? How often do they occur? Are onsite visits included? Who pays for travel?

    - ASP maintenance windows . If you are using an ASP, what is the scheduled downtime? Can it be tuned to better match your needs and your customers' needs?

  • What implementation services are included? This is a key provision if the vendor is handling the implementation. We will discuss implementation- related choices in Chapter 8.

  • References . Some standard contracts give the vendor the right to use your name as a reference by default (for instance, they may list your name on their web site). It may be wise to delay that listing until you are happily in production.

  • Dispute resolution . Your lawyer will be able to help you review whether the dispute resolution terms are acceptable. The vendors' standard contracts often limit greatly what you can do if push comes to shove.

Some vendors do not modify their terms and conditions at all, and even the ones that do may not be open to changes for smaller contracts. Whether or not you want or can change the terms of the standard contract, make sure you understand exactly what is covered in the contract. You will have to live with the terms for a long time.



Just Enough CRM
Just Enough CRM (Just Enough Series)
ISBN: 0131010174
EAN: 2147483647
Year: 2003
Pages: 143

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net