We are seeing a growing trend among our software developer clients. They are entrepreneurial business of all sizes. They’re run by smart people who know only too well that the value in what they offer is often not found in "out of the box" software or stand-alone products. They realise customers are busy people who value software that serves niche needs and is efficient, reliable, up-to-date and easily maintained.
These software developers and their customers are realising that the best way to provide this is to keep the software developer in the loop.
This is usually done by the developer providing the customer with access to a server where the software is hosted, monitored and continually improved. The customer pays monthly or quarterly in advance via e-commerce or direct debits. The developer retains and maintains the software. Often, the developer will tweak the product to create a bespoke version for each customer according to needs. When a customer no longer wants the service it gives notice, payments cease, and the developer retains its ownership of the software.
This is the world of software as a service, where the hot property is the developer as creator, service provider, customiser and updater. If you prefer, alternative labels might be web services, e-commerce websites, or cloud computing.
In the software as a service arrangement we've described, the customer is not purchasing software, let alone a fixed version of it. Instead the customer is paying a fee to access constantly upgraded web-resident software, and importantly in a web software world, to also have the ongoing support of the developer’s know-how, one-on-one live assistance, and even tweaks and insights useful for a customer's specific operational or business needs.
It's a relationship combining a fee for service, software licensing and software maintenance.
As lawyers, our insight is that we can legally document the arrangement in a practical, workflow-orientated, short form agreement. It's about contracts that help IT clients manage projects and their revenue-earning offerings and customer relationships. At Dilanchian we've recently become very experienced in doing so, having drafted a series of online services agreements for software developer clients. Some have been as short as two pages.
Our clients' software has ranged from online marketing services for the hospitality sector through to online product ingredients calibration services.
What do we cover in those contracts? Here’s a sample Q&A of the first conversation that takes place when software as a service clients call with needs similar to those above.
Question: My customers want to use my software, sometimes some want more. They want customisation, extra features, a path for future potential upgrades, or website hosting. What should I do? Can I have all that in one contract? Is it better to do separate contracts or contact variations for separate services?
Answer: The beauty of the agreement we can craft is that we can draft it in a format that is re-useable by you, suitable for most situations, and easily changed to suit variable customer needs. To do this we'll work with you to define the practical variables your customers desire. We can position those into a cover page table schedule or in an attachment to what will be your in-house template contract. The schedule or attachments will be physically separate from the purely legal terms and conditions. It will help shorten the terms and conditions. Your customers will "get it" quicker, and the terms and conditions will have to rarely change in response to specific customer negotiations. What required is standardisation and a clear business operations process on your part. The result is your customers get a contract they can understand and which suits their reality and you get enforceable in-house standard contracts you can manage.
Question: Under those contracts I want to be able to terminate the services immediately for breaches (eg non-payment), but I want customers to pay a fine if they terminate early. Also, I want to limit my liability.
Answer: You need to be wary of including unfair contract provisions in your agreement. There are laws governing what can or can’t be included in a standard form agreement. You might be caught by these provisions for example, if you provide your services to a sole trader, who acquires the services predominantly for personal or domestic consumption. There are also laws concerning unconscionable conduct in business transactions. These laws are risk to be managed by working out termination provisions that are workable. Same goes for liability provisions. These are important and legally complex considerations best addressed after working out the practical things each side is to do or not do in the legal relationship and what each pays for that. In short legal treatment should follow practical needs, ideally not the reverse.
Question: I'm worn down by all the back and forth with customers before they've paid me anything. How can I clearly put what I do and provide and what they get and pay for and cut out profit-reducing contract negotiation time?
Answer: The key is to identify with brevity the key features of your software and service offerings and to then tell them the cost. Your customers will buy what they understand, need and can't do for themselves. The format and content of the contract we draft can help customers make their buying decision.
We can go into detail later but you'll see as we work through this job that you'll probably need to do more than what we can do for you, but we'll alert you about many of those non-legal topics. You are possibly no different to many of our software as a service clients. You need at least three things in place.
You must correctly market your offering, eg on a dedicated webpage.
You must prepare a proposal to pitch your offering (eg a webpage or PDF brochure to state software features or key specifications, available for communicating via email to customers).
You must settle and apply a standard workflow for your offering (and prepare an operations manual if necessary).
For items 1, 2 and 3 and the in-house standard template contract, we have to begin by defining your software, service offering, go to market readiness, price and deal points. It's an iterative process. Would you like to begin now?
Of course, no in-house standard template agreement ever reaches a point of perfection. Just as software and services change over time, so do laws, industry practices and business processes. A practical, workflow-orientated, short form agreement as we've described is often the best design to meet this need for future adaptation and flexibility.