The recent Travel Tech Show in London offered a session called "How Not to Sue Your Tech Provider," a situation that presenter Nick Goodchild, associate solicitor for Travlaw Legal Services, said is becoming more common in the travel industry.
"It's still a relatively low volume," Goodchild said. "Actually going to court is complicated, and it tends to be reserved for when things have gone seriously wrong, but it is happening more."
Goodchild, who works on contract drafting and negotiations, said the key to staying out of the courtroom starts at the beginning of the relationship with a tech provider, "setting up a relationship for success rather than ending up in a dispute." Here are some of his high-level recommendations of what to consider when contracting with a tech provider.
Understanding Contract Types
Tech contracts fall into three broad categories, Goodchild said. A bespoke agreement is the most customized, covering development of software, a website or an integration specific to a client's needs. Licensing agreements grant permission to use pre-existing software that is installed on a client's own servers. Software-as-a-Service agreements are for cloud-hosted technology that does not need to be installed but generally requires a subscription fee for continued access.
Think of a bespoke agreement like having a new house built, a licensing agreement like buying a house and a SaaS agreement like renting a house.
Regardless of the contract type, Goodchild said it is important that it specifies what it is exactly that the software needs to do. What functionality is being provided, and where is that documented—as a document given to the client, for example, or a list on the company's website? Users also should determine up front compatibility with other software they are using and what the user interface will look like, he said.
Particularly in the case of bespoke agreements, clients should have an idea of what they will need in the future to ensure they have the functionality not only that they need now but what they will need in a few years.
"This is probably going to be a long-term deal, not something you want to renew every year or every couple of years," he said. "Planning for the future and what functionality you want to develop in the future is very important."
Bespoke agreements tend to take one of two approaches, Goodchild said. A waterfall approach is one in projects are organized in strict, fixed phases, with each phase complete in a linear order before the next one begins. Agile agreements are more flexible, with the client working with the developer at every step and evolving the planning as the project progresses.
With development agreements, Goodchild said it is important to have a clear process in how software will be tested and approved in various stages as well as a process for what happens if it does not work as expected.
Conducting Maintenance
Maintenance in SaaS agreements generally is included as part of the subscription price. This takes work off the client, though it also offers less flexibility of what will happen when changes occur. In licensing agreements, maintenance usually comes at an extra cost or falls to the responsibility of the user's IT team.
With maintenance agreements, Goodchild said it is first important to define critical faults versus non-critical faults. A non-critical fault might just be a small bug in the software or something not working as intended, while a critical fault is impeding functionality or stopping a business from working altogether. That way, a company can ensure that developers or maintenance providers can jump on critical faults much more quickly, he said.
This can tie in with service-level agreements, Goodchild said, which can determine timeframes for fixing different levels of faults. That might include agreements for service credits, such as a monetary value off the next bill or toward future work, if those timelines are not met.
Goodchild added that it is important to distinguish between modifications and updates, as tech providers might have their own specific definitions. Generally, a modification is an incremental change or upgrade to existing functionality, while an update would be a bigger change, such as adding a whole new tool to the software system. Modifications usually are included in pricing, while an update could come at an extra cost, so it's important to understand that up front, he said.
In the case where a user doesn't want to adopt an update, it's also important to understand whether and for how long tech providers will continue to support older versions, he added.
Consider IP Rights
Software is a valuable intellectual property, so intellectual property rights are an important part of any kind of tech contract, Goodchild said.
For SaaS and licensing agreements, it's more straightforward, as developers almost always will retain IP rights for their own software. In the case of bespoke agreements, when new software is being developed with significant input from the customer, they might have some rights, however. For example, they could negotiate exclusivity rights or royalties if the software is sold to third parties, he said.
It's also important to evaluate any third-party software that might be used as a plug-in and make sure that proper rights are in place—or that an indemnity is in place to protect the client in case the developer makes that error.
"We worked in a dispute where one of our clients had a bespoke system built, and a PDF generator was used in that without the proper rights, and that ended up in a £30,000 claim against the client," he said. "That should have been arranged in advance with the developer."
Preparing for Disputes
Even with a solid relationship in place, low-level disputes are not uncommon in tech deals, so users should have a dispute resolution clause in place. That will set up how such disputes will be handled, such as escalation plans to when disputes go from a management level to an executive level.
Going to court should be a last resort, but Goodchild said companies should keep records of anything that goes wrong in case it escalates to that level.
Agreements also should include an exit strategy, even if the company and tech party eventually part ways in an amicable manner, he said. In particular, companies should understand what data migration will be possible to a new provider and any costs associated with that.
"Is that data going to be in a compatible structure to import, and will the developer agree to assist in that migration?" Goodchild said. "Agreeing all these things in advance will set you up for when you come to that rather than having an awkward conversation with the tech provider."