Crafting a Better HR Technology Contract

Quotes highlighted below. Originally published in HR Magazine

A strong agreement with tech providers should cover contingencies and limit risks.

By Dave Zielinski
July 1, 2016

Illustration by Michael Sloan for HR Magazine

Experience has taught Joe Almodovar the value of being assertive when negotiating service contracts with HR technology vendors. As senior director of global human resource information systems (HRIS) and payroll at A.T. Kearney management consultants in Chicago, Almodovar once negotiated an agreement with a payroll services provider that promised 99.9 percent accuracy on employee paychecks. But Almodovar was concerned that the terms didn’t include any redress should the vendor fall short of that goal. “There was no discussion upfront about penalties,” Almodovar says, “so I had to press for how we’d be compensated should they not meet that important standard.”

Eventually, the two sides agreed that the vendor would waive its monthly payroll processing fee if it didn’t hit the accuracy target. A clause spelling out the terms of the penalty was included in an amendment to the agreement. 

In an ideal world, there would be no need for contracts between HR and its IT providers because each party could be counted on to meet the other side’s expectations. But agreements are written to govern the imperfect world in which we live and work. To that end, here are steps HR professionals can take to reduce risks to their organizations and secure recompense if the vendor’s promises aren’t realized.

Be Clear and Precise

HRIS leaders should take a proactive negotiating stance to ensure that tech providers are held accountable for performance after a new system is purchased. Although many vendors maintain that the boilerplate contracts they use can’t be modified because those contracts have been meticulously constructed by attorneys, experts say there is usually leeway to insert addendums and other language.

One of the biggest areas of contention can be service-level agreements (SLAs), which detail how vendors will manage client accounts after the technology is deployed. Negotiating a good SLA with software-as-a-service vendors is particularly important, given the challenge of identifying the root cause of performance breakdowns in more-complicated cloud environments.

Problems typically arise from the use of ambiguous language and because agreements lack adequate teeth, says Roy Altman, manager of HR analytics and application architecture at Memorial Sloan-Kettering Cancer Center in New York City. To avoid conflicts, concepts such as “downtime” should be precisely defined so both sides understand what “allowable days of unplanned downtime” and similar phrases mean, he says. Other examples of vague wording include “problem response time,” “SLA penalty formulas” and references to a system performing “substantially.” Consult with an attorney to help clarify the meaning in such instances.

Set Expectations

A vendor’s failure to meet requirements spelled out in the agreement should result in actions that compensate the client for its losses. These penalties should be clearly stated. “Any organization should be very clear with its vendor that the expectation is that it must meet all of the agreement’s requirements, not just some of them,” says Michael Rochelle, chief strategy officer for the Brandon Hall Group in Delray Beach, Fla.

If a cloud provider doesn’t meet its obligation to ensure an agreed-upon 99.5 percent of monthly system “uptime,” for example, it should give financial credits or other monetary recompense to the HR client, according to Altman. Uptime is the time a system is operational and available and is a measure of reliability. Credits are typically applied as a percentage discount against future monthly service fees.

“The damage to you in terms of system downtime can be greater than the credits you receive for the problem if you don’t negotiate a good deal in the SLA,” Altman says.

Assess Security

Given that cloud vendors will have control over your sensitive HR data, it’s crucial that contracts address how information will be protected in storage and in transit. HR should also verify that a provider has adequate insurance in the event one of its employees causes a data breach.

“No vendor will guarantee they’ll keep your data safe because 100 percent guarantees aren’t possible,” Altman says. “But most will agree to comply with industry standards for data security, which you should verify.”

Data migration protocols should be carefully considered upfront and should never be an afterthought in contracts with cloud vendors. Specify how long it will take to move content to a provider as well as which tasks are the vendor’s responsibility vs. the client’s.

Iron Out Implementation

Whether they are addressed in the contract or not, system implementation issues need to be ironed out in the negotiating stage. The stakes for HR during this period are high, given that the seamlessness, or lack thereof, of the system implementation has a big impact on user adoption, which is a key measure of a new technology’s success.

“Vendors typically are in control of how long an implementation takes, and I think there should be clauses that hold them to time and budget agreements, as well as to the content that is being implemented,” says Jeremy Ames, president of Hive Tech HR, a technology consulting group in Boston.  

Anticipate Staffing Changes

Having the right vendor personnel assigned to your account is key to a successful relationship. But the customer doesn’t always have the ability to choose the staff assigned to its project. It’s not unusual for senior personnel to shepherd the start of a system implementation, for example, only to delegate the rest of it to less-experienced junior staff as the process unfolds. That’s why some HRIS leaders insist on a contractual clause that gives them the right to preapprove vendor staff assigned to their projects.

“We named key vendor personnel in one of our contracts and ensured they would be on the project for the duration, as well as be onsite at certain times,” Altman says. “They couldn’t be swapped out without our written approval.”

Use language tied to roles rather than naming specific individuals, Ames suggests. For example, you might require “senior implementation consultants” on all technology projects.

Have an Exit Plan

Make sure to consider what your “tipping point” is for exiting a contract, whether it is one major issue—such as a data breach that is the fault of the vendor—or a series of small problems that aren’t resolved, Rochelle says. Examples of the latter might include repeated failure to meet system uptime or response time requirements over a specified period.

You’ll also want to make sure you know in advance what will happen to your data when the agreement is terminated.

“Data extraction from cloud systems isn’t always cut and dried,” Ames says. “Vendors will sometimes give your data back in unfriendly file formats, with long delays or even extra fees if the terms on data retrieval aren’t clearly spelled out in the contract.”

Also, make sure you understand what happens in the event that the vendor goes out of business or gets acquired by another company.

Putting the details in writing at the outset of the relationship with a technology provider—and not just thinking about it when the end is in sight—could save you some sleepless nights.  

Dave Zielinski is a freelance writer and editor based in Minneapolis.