- The three-party structure your terms have to manage
- The privacy policy: a statutory floor, not a template
- Website terms of use: binding everyone, not just members
- Optional clauses to include when they are triggered
- How an Artificer Legal practitioner will work through your stack
- Who is on the hook when a job goes wrong
You have built the matching engine, the profiles and the bidding interface. The last thing standing between you and launch is the document stack, and it is the part most marketplace founders are tempted to shortcut. A reverse auction marketplace brings together customers who post jobs and service providers who bid against each other to win them. The operator's job is to introduce the two sides, take a fee for the introduction, and stay out of the underlying transaction. Three documents make that position safe: marketplace terms and conditions, a website terms of use, and a privacy policy.
The terms and conditions bind everyone who registers an account, whether they post jobs or bid on them. The website terms of use bind every visitor, registered or not. The privacy policy is different in kind: it is not just good practice but a statutory requirement where the Privacy Act 1988 (Cth) covers your business. None of these documents makes you a party to the jobs arranged through your platform. Their whole purpose is to make sure nobody thinks you are.
The three-party structure your terms have to manage
Every reverse auction marketplace runs on the same three-way relationship. A customer posts a task with the details of the job. Service providers build profiles on the platform showing their qualifications and experience. Providers bid on the job, often driving the price down, and the customer picks a provider from the bids. The marketplace operator does none of the work. It connects the people who do.
The legal risk sits in that gap between what the operator does and what users assume it does. If a job goes badly, the customer's first instinct is to blame the platform that sold them the introduction. Your documents must make the operator's role explicit, and the public-facing copy on the site has to say the same thing as the contracts. A terms page that calls you an "introducer" while the homepage promises "we guarantee every job" is a contradiction a court or a regulator will read against you.
The marketplace terms and conditions, clause by clause
The operator's role: introducer, not party
The most important clause in the entire stack states plainly that the operator is not a party to any transaction between a customer and a provider. It should say the operator only provides an introductory and matching service, that the customer and provider contract directly with each other, and that disputes about the quality of work are theirs to resolve.
Three drafting minimums make this clause hold up. First, define the operator's service as introduction only, with no obligation to perform, supervise or guarantee any job. Second, state that the customer's contract for the work is with the provider alone. Third, make the clause consistent with the website copy, the payment flow and anything else users can see, because conduct contradicts documents.
The variant users will push back on is the platform that quietly promises more than it delivers. The trap runs the other way too: if the operator starts holding money, vetting providers as "approved" or advertising a satisfaction guarantee, the introducer characterisation starts to break down, and with it the protection the clause was supposed to buy.
How payment flows
Payment is where marketplace operators get into trouble, and there are three models to choose from. The customer can pay the provider directly outside the platform, with the operator charging the provider a listing or subscription fee. The operator can route payments through a third-party processor such as Stripe or PayPal. Or the operator can act as a limited payment agent, collecting money from the customer and remitting it to the provider.
Each model shifts risk differently. If you take card details yourself, the Payment Card Industry Data Security Standard (PCI DSS) applies to any entity that stores, processes or transmits cardholder data, and using a compliant third-party processor materially shrinks your compliance scope. Routing through a processor keeps card data out of your hands, which is why most new marketplaces start there.
The payment-agent model is the one to approach carefully. Collecting and holding money on behalf of providers raises questions about how those funds must be safeguarded and whether the arrangement touches regulated financial services. If you are drawn to holding funds, escrow or milestone release, get advice on the model before you build the feature, not after.
What the operator gets paid
The fee clause sets out what the operator charges and when the fee is earned. The drafting choice that matters most is defining the trigger. Is the fee earned when the customer accepts a bid, when the job is marked complete, or when payment clears? Ambiguity here produces the most common dispute a young marketplace faces: the provider who did the work, the customer who never marked it complete, and the operator trying to collect a commission on an arrangement it cannot verify.
Fee clauses also need to survive scrutiny under the Australian Consumer Law (Cth). A term of a standard form consumer or small business contract is void if it is unfair, and penalties now attach to proposing one. Your terms and conditions are standard form contracts in practice, so unilateral fee increases, fees that swallow a provider's entire payment, or deductions that punish a user for complaining are the kinds of terms that get struck out.
Who is liable for the work
The liability clause allocates responsibility when something goes wrong on a job. It should say the platform is provided as is, that the operator does not warrant the quality, safety or legality of any provider's work, and that the provider indemnifies the operator against claims arising from the services the provider performs.
What this clause cannot do is contract the operator out of everything. Terms that purport to exclude the consumer guarantees in the Australian Consumer Law are void, and misleading or deceptive conduct cannot be excused by a contract. The drafting trap is the blanket "we accept no liability whatsoever" clause that a court simply severs, leaving the operator with a false sense of protection. The clause that works carves out the operator's own conduct and the statutory rights users cannot give up, and limits what remains.
Resolving disputes between buyer and provider
Because the operator is not a party to the work, the terms need to say what happens when the customer and provider fall out. The default position should be that the users manage the dispute between themselves, with the operator offering a fair complaints process and stepping in only where the terms give it a role, such as releasing or withholding held funds.
Be careful with dispute clauses aimed at consumers. A clause forcing a consumer to arbitrate in a distant location, or giving the operator the unilateral right to choose the forum, is the kind of term that is vulnerable under the unfair contract terms regime. The safer shape is a simple escalation: the parties attempt to resolve the dispute directly, the platform facilitates communication, and nothing stops either side from taking the matter to a court or tribunal.
Rules of the road for users
The conduct clauses list what users may not do: post illegal or defamatory content, misrepresent their qualifications, solicit jobs off-platform to dodge fees, or scrape data from the site. These clauses are the operator's contractual remedy, and they matter most where the behaviour is not otherwise easy to stop.
Email scraping is a good example. Collecting email addresses from profiles to run your own marketing can land you in breach of the Spam Act 2003 (Cth), which prohibits sending unsolicited commercial electronic messages without consent and requires every commercial message to carry a functional unsubscribe facility. The terms of use give the operator the right to suspend or remove users who harvest data, and they signal that the platform polices its own community.
The privacy policy: a statutory floor, not a template
A marketplace collects personal information from day one: names, email addresses, phone numbers, locations and profile details. Under the Privacy Act 1988 (Cth), "personal information" is information about an identified individual, or one who is reasonably identifiable, and the Australian Privacy Principles (APPs) regulate how that information is collected, used, stored and disclosed.
Australian Privacy Principle 1 requires every APP entity to have a clearly expressed and up-to-date privacy policy, and to make it available free of charge. The policy must state the kinds of personal information collected, how it is collected and held, the purposes of collection, how individuals can access and correct their information, and how they can complain. Breaches of the requirement to maintain a policy can attract an infringement notice from the Office of the Australian Information Commissioner, and a serious interference with privacy can draw a civil penalty of up to $50 million for a body corporate, three times the benefit obtained, or 30 per cent of adjusted turnover.
The threshold question for a small marketplace is whether the Act covers it at all. The small business exemption still exists: a business with annual turnover of $3 million or less is generally not an APP entity. But the exemption has carve-outs that catch marketplace operators more often than they expect. A business that discloses personal information about individuals for a benefit, service or advantage is treated as trading in personal information and loses the exemption. A marketplace that passes providers' details to customers, and customers' details to providers, as its core service needs to check whether it sits inside that carve-out rather than assume the exemption protects it. Health services, credit reporting and Commonwealth contracts have their own carve-outs, and a business related to a larger entity is covered too.
Website terms of use: binding everyone, not just members
The website terms of use cover the ground the marketplace terms cannot reach, because they apply to everyone who visits the site, whether or not they register. They set out permitted and prohibited use of the platform itself: no unauthorised access, no scraping, no interfering with other users, and no use of the site for illegal activity.
They are also where the operator deals with its own intellectual property in the site content and branding, and where it points visitors to the terms and conditions and privacy policy that do apply once they register. The practical point is coverage. A visitor who never creates an account cannot be bound by the marketplace terms, but the terms of use bind them from the moment they land on the page, provided the site gives them reasonable notice of the terms.
Optional clauses to include when they are triggered
The core clauses above cover every launch. These further clauses earn their place once the platform grows into the features they protect:
- Escrow and milestone release: worth drafting once the operator holds or withholds funds, so release is tied to a defined event rather than operator discretion.
- Identity and qualification verification: include when jobs are high value or high risk, and state the operator's right to verify providers and remove those who fail.
- Insurance requirements for providers: common in trade services, where the operator requires providers to carry public liability cover and produce evidence on request.
- Reviews and ratings licensing: give the operator a licence to display, aggregate and reuse user-generated reviews, and require users to warrant their reviews are honest.
- Off-platform solicitation restriction: stop providers from taking repeat work off the platform to avoid the fee, which is the quiet killer of marketplace revenue.
How an Artificer Legal practitioner will work through your stack
Drafting these documents from a template is where marketplace founders usually go wrong, because the risk is not in any single clause but in how the clauses interact with the payment model and the way the platform actually behaves. An Artificer Legal practitioner will start by mapping your payment flow, because it decides whether you are an introducer, a payment agent or something that looks like a party to the transaction. From there we review the operator's role clause, the fee and completion definitions, and the liability allocation, and we audit the whole stack against the unfair contract terms regime, because a term that is void is worse than a term that was never there.
We also work out whether the Privacy Act covers your business, including the trading in personal information analysis that most small operators miss, and we draft the privacy policy to the content requirements of APP 1 rather than to a generic template. The documents are then aligned so the website copy, the terms of use and the terms and conditions tell the same story.
Who is on the hook when a job goes wrong
The clause that decides your exposure is the operator's role clause, but only if the rest of the operation matches it. A customer whose roof leak was made worse by a provider will test your documents against what you actually did: whether you took their money, whether you vouched for the provider, whether your marketing promised more than an introduction. The drafting that holds up is the drafting that matches the reality of how your platform runs. If the two diverge, no clause saves you.
In short, a reverse auction marketplace needs terms and conditions that fix the operator's role as introducer, define the fee trigger and allocate liability without falling foul of the unfair contract terms regime; a website terms of use that binds every visitor and prohibits scraping and abuse; and a privacy policy that meets the Australian Privacy Principles if the Act covers you, which for many marketplaces it does. Sort those three documents out before you onboard your first provider, and the platform's legal risk stays where it belongs: with the users who do the work.