Your licence agreement is signed, the first invoice is paid, and then the email arrives: the customer's procurement team wants to see the support terms before go-live. This is the moment the support agreement (sometimes called a service level agreement, or the SLA) becomes the document that matters. It is usually short and looks procedural, and it gets far less attention than the licence itself. Yet it is the document the parties actually reach for when the software misbehaves mid-morning on a Tuesday and someone's payroll has stopped.
A support agreement sits beside, not instead of, the licence or subscription agreement. The customer never owns the software, so the support agreement governs what happens after the sale: the level of service the customer can expect, how quickly problems get looked at, what counts as a problem at all, and what happens when the vendor misses a target. Because it is a service contract it also attracts statutory rules under the Australian Consumer Law (the ACL), which is Schedule 2 of the Competition and Consumer Act 2010 (Cth), that drafting cannot simply contract out of, plus privacy obligations that bite wherever support staff touch customer data. This article walks through the clauses that do the work, the drafting choice behind each, and the traps that turn an SLA into a dispute.
The clauses that do the work
Most support agreements, whether the software is installed on the customer's own servers or hosted on the developer's infrastructure, resolve into the same handful of clauses. They are set out below roughly in the order a dispute would reach for them, which is also the order in which they should be drafted.
What support covers, and what it does not
The scope clause is the most important sentence in the document, and the most fought over. It needs to distinguish technical support (the software produces errors, crashes or behaves incorrectly) from product support (users need help working out how to make a feature do what they want). It then needs a working definition of what counts as a defect or incident, and a list of what is excluded: training, customisation, third-party hardware or network faults, data migration, and support for versions of the software the customer has modified.
- Technical support: the software is not performing as it should, so the developer diagnoses and fixes the fault.
- Product support: the software is performing, but the user needs assistance to use it; decide whether this is included or billable.
- Exclusions: training, customisation, integrations the developer did not build, and changes required by new legislation are the usual carve-outs.
The case law shows what happens when this clause is left vague. In Baan Australia Pty Ltd v George Weston Foods Ltd [2000] NSWSC 504, George Weston Foods terminated a software licence and support agreement and then tried to have a series of implied terms read into it, so that it could recover for losses the express words did not cover. Bergin J held that none of the terms could be implied, applying the well-known test from BP Refinery (Westernport) Pty Ltd v Shire of Hastings (1977) 180 CLR 266: a term is implied into a formal written contract only where it is necessary to give the contract business efficacy, is so obvious it goes without saying, and does not contradict the express terms. The customer's fallback was a misleading-conduct claim about what the sales team had said before the contract was signed. The lesson for both sides is that the scope of support should be written down expressly, because a court will not invent it later.
Severity levels, response times and the clock
Most agreements classify issues by severity, usually from critical (the system is down or data is at risk) down to minor (a cosmetic glitch or a question). Each severity carries a response time and a resolution time. The drafting choice that matters most is the distinction between response and resolution: a response time is usually a promise to acknowledge the ticket and start work, not to fix it, and the two are routinely confused in negotiation.
- Severity definitions: tie each level to a concrete event, such as "the software is unavailable to all users", rather than to adjectives like "significant".
- Clock rules: state when the clock starts (a properly logged ticket during support hours) and when it stops (awaiting information from the customer).
- Best endeavours versus fixed times: customers push for fixed hours, developers for "best endeavours"; fixed times are only safe where the developer actually has the staffing to meet them.
Support hours matter as much as the numbers. A 24/7 promise for a small development team is a liability, not a selling point. The agreement should state the hours during which support is provided, and set the severity clock to match.
Uptime guarantees and service credits
For hosted software, the centrepiece is the uptime guarantee: the percentage of time the service will be available, usually measured monthly, with scheduled maintenance windows excluded from the calculation. The remedy for missing the target is typically a service credit, a discount on the next invoice calculated against the shortfall.
- Measurement: state the period (usually calendar month), what counts as uptime, and what is carved out (scheduled maintenance, customer-caused outages, force majeure).
- Credits formula: for example, 1 per cent of the monthly fee for every 0.5 per cent of uptime missed.
- Cap and exclusivity: credits are usually capped at a percentage of the monthly fee and expressed as the customer's sole remedy for an uptime miss, which is the variant the developer should insist on.
The trap runs in both directions. Uncapped credits can wipe out the revenue from a whole contract on one bad month, while a "sole remedy" clause that also excludes the customer's right to terminate for repeated failures may be struck down as unfair (see below).
Updates, upgrades and testing
Support and software releases are closely connected, and the agreement needs to say who does what with each new version. Decide whether updates are pushed automatically or installed by the customer, whether they occur in defined maintenance windows, and who tests them. In a hosted environment the developer controls the environment, so the agreement should commit it to testing updates in a staging environment before production, and to being responsible for defects in its own releases.
- Version support: state how long each version remains supported, and that end-of-life versions fall outside support; this is a common and legitimate exclusion.
- Upgrade rights: whether support entitles the customer to new versions, or whether major upgrades are paid separately.
- Integration risk: updates can break the customer's integrations; agree in advance whether the developer tests those, or whether they are the customer's responsibility.
Access to customer systems and data
Where the software is installed on the customer's infrastructure, the developer needs a right to access it remotely, and that right needs limits. The agreement should require reasonable notice and consent before access, bind the developer's employees and contractors to confidentiality, and state who is responsible for security testing and for backups.
Where access touches personal information, the Privacy Act 1988 (Cth) enters the picture. Australian Privacy Principle 11 requires an APP entity to take reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure. A support provider handling customer data, for example through tickets or remote access, needs to satisfy the same standard in practice, and the agreement should allocate who does what. If a data breach occurs, the notifiable data breaches scheme in Part IIIC of the Privacy Act can require notification to affected individuals and the Office of the Australian Information Commissioner; the agreement should state which party investigates a breach and which party bears the notification obligations, because the customer will usually be the APP entity that has to answer for it.
- Access terms: notice, consent, scope of what the developer may touch, and deletion of copies after support ends.
- Security obligations: align the developer's obligations with APP 11, including in subcontractor arrangements.
- Backups and recovery: state who takes backups, how often, and who is liable if they fail.
Where support meets the Australian Consumer Law
The ACL's consumer guarantees apply to support services supplied to a consumer. A customer is a consumer in relation to services under s 3 of the ACL where the price paid does not exceed $100,000, or where the services are of a kind ordinarily acquired for personal, domestic or household use. For those customers, s 60 of the ACL guarantees that services will be rendered with due care and skill, s 61 guarantees reasonable fitness for the purpose made known, and s 62 guarantees supply within a reasonable time. Section 64 makes it void to contract out of these guarantees.
The carve-out that matters for business software is s 64A. Where services are not of a kind ordinarily acquired for personal, domestic or household use, a contract can validly limit liability for failure to comply with those guarantees to re-supplying the services, or paying the cost of having them supplied again. That is the legitimate clause for a developer selling to businesses: it does not exclude the guarantees, it caps the remedy at the value of the service.
- Consumer versus business customers: know which of your customers are consumers, because the guarantees and the non-exclusion rule apply to them in full.
- The re-supply limitation: include the s 64A limitation for business customers rather than trying to exclude the guarantees altogether.
- Pre-contractual representations: s 18 of the ACL prohibits misleading or deceptive conduct in trade or commerce, and it applies to sales pitches, demonstrations and statements about what the software will do. An entire agreement clause helps, but it did not stop the representations case in Baan, so the sales process should be as carefully drafted as the contract.
There is a further overlay for standard form contracts. Under s 23 of the ACL, a term of a standard form consumer contract or small business contract is void if it is unfair, and since the 2023 reforms, proposing or relying on an unfair term can attract pecuniary penalties. A small business contract is one where a party has fewer than 100 employees or turnover under $10 million, which covers most Australian software customers. One-sided clauses, such as unlimited unilateral variation, credits as the sole remedy even for repeated failures, or the right to suspend support without cause, need to survive a fairness assessment.
Price, payment and fair use
Support is usually priced one of two ways: as an annual fee calculated as a percentage of the licence fee, or bundled into a subscription. The Baan contract is a realistic illustration of the first model: on a licence fee of about $6.1 million, the annual maintenance fee was $610,100, or roughly 10 per cent. For hosted software the agreement should also state who pays the hosting costs and what happens to data usage.
- Fee structure: state the fee, what it includes, and any indexation, so the price cannot become a dispute point later.
- Fair use: for hosted software, either set hard data limits or include a fair use policy with overage charges, so a handful of heavy users cannot blow out the hosting bill.
- Payment terms: when fees fall due, whether support is suspended for non-payment, and whether the customer's data is withheld in that event.
Term, renewal and termination
Support agreements usually run for an initial term and then roll over automatically unless either party gives notice. The drafting choice that causes the most downstream trouble is the length of the notice period and what happens on exit.
- Renewal: state the term, the notice period required to stop auto-renewal, and whether the fee can be varied on renewal.
- Termination: cover termination for breach with a cure period, and whether the customer can terminate for convenience.
- Exit: on termination the customer loses access to support; the agreement should say what happens to the customer's data, particularly in a hosted environment.
Optional clauses worth adding
A handful of clauses are situational, and each earns its place when a particular trigger is present:
- Source code escrow: include where the software is mission-critical and the customer worries about the developer's insolvency; the escrow agent releases the code to the customer on defined events such as liquidation or receivership.
- Transition and exit assistance: include where the customer could realistically switch vendors; it obliges the developer to help extract data and migrate.
- Disaster recovery and business continuity: include for hosted, mission-critical software, with recovery time and recovery point objectives.
- Use of subcontractors: include where the developer scales support with third parties, and extend confidentiality and security obligations to them.
- Liquidated damages for missed targets: include where the customer wants a stronger remedy than credits, drafted as a genuine pre-estimate of loss so it is not void as a penalty.
How an Artificer Legal lawyer would review your support agreement
A lawyer reviewing a support agreement would start with the scope definition and the severity table, because those are the clauses every later argument turns on, and check that they are measurable rather than aspirational. Next would come the pairing of uptime credits with the liability cap, to make sure the customer's remedies are real and the developer's exposure is bounded. Then the ACL layers: the s 64A re-supply limitation for business customers, the fairness of terms under s 23 for standard form contracts, and the accuracy of anything the sales team is saying under s 18. Finally, the privacy and data clauses, including who investigates and who notifies in the event of a breach, and the exit terms.
The clauses we would push back on are the ones that routinely cause grief: uncapped or automatic credits, "best endeavours" response times that cannot be measured, one-sided variation rights, and blanket exclusions that cover the customer's actual use of the software. The variants we would insist on are a written escalation procedure with named contacts, a clear clock for response and resolution, the s 64A limitation in proper form, and an exit clause that does not strand the customer's data. If you are on the customer side, the order of negotiation is the same: scope first, then credits and caps, then termination and data rights.
Draft the scope definition first
Every part of a support agreement hangs off the answer to one question: what does support actually cover? Baan shows the cost of leaving that question unanswered, with a customer forced to argue implied terms into a written contract after the relationship had already broken down, and the court declining to invent them. If the scope of support, the severity levels and the exclusions are written down in measurable terms, the credits, caps and prices can be argued about in good faith. If they are not, every other clause in the document is drafting around a hole.
To summarise: a support agreement governs the service after the sale, and its working parts are the scope definition, the severity and clock rules, uptime credits, update and testing responsibilities, access to systems and data, the ACL guarantees and their business carve-out, pricing, and the term and exit terms. The statutory layers cannot be ignored, particularly the consumer guarantees, the unfair terms regime and the privacy obligations, but a well-drafted scope clause keeps most of them from ever becoming someone's problem.