Customer contracts: MSAs, SOWs and pilot agreements

1. The core idea#

For a deeptech startup, the first customer contract is rarely a straightforward sale. It is a pilot: a large company, utility, hospital, defence agency or factory agrees to test your technology on its site, its data or its process, usually for a few months, often for little or no money. Done well, a pilot is the bridge to revenue, the best evidence investors see at seed, and a source of real-world data. Done badly, it is months of unpaid engineering that ends in a polite "interesting, let's stay in touch", or in the customer owning improvements to your own technology.

The contract decides which. Most of the leverage sits in a few choices:

1. Define success before you start. Written, measurable criteria agreed by the person who can buy, with a decision date.
2. Charge something. A paid pilot, even at a modest price, puts the project in the customer's budget and forces someone senior to approve it.
3. Agree the next step in advance. Pricing and terms for the commercial contract if the pilot succeeds.
4. Protect your IP. You own your technology and improvements to it. The customer owns its own data and gets a licence to use the results.
5. Cap your risk. Limit liability to a sensible amount and exclude indirect losses.

Once the relationship is commercial, the usual structure is a master services agreement (MSA) or master supply agreement setting the legal terms once, plus a statement of work (SOW) or order form for each project or purchase. Getting your own MSA template ready before the first big customer saves you from negotiating on the customer's 60-page paper from scratch.

Who this is for: founders negotiating their first pilot, proof of concept, evaluation or supply agreement with a corporate, government or institutional customer; anyone being sent a customer's standard terms.

Pairs with: 4.15 (joint development agreements, when the pilot turns into codevelopment), 4.13 (data protection and DPAs), 4.10 (the contractor side of the same structure) and 4.16 (export controls).

2. What the evidence says#

Most pilots don't convert, and the open-ended ones convert least. Good public data is thin, and most of it comes from software. But the pattern is consistent:

• Menlo Ventures' 2025 enterprise survey reported that about 47% of AI deals reached production, against about 25% for traditional software. In other words, even in a hot category, half or more of trials stall.
• In manufacturing and industry, "pilot purgatory", where companies run many trials and scale few, has been a recurring theme in McKinsey's and the World Economic Forum's work on industrial technology adoption.
• Practitioner experience is that paid pilots with written success criteria convert far better than free, open-ended ones. Jason Lemkin of SaaStr reports paid-pilot-toannual conversion of roughly 60–90% among companies he works with. That is a selected sample, but the direction matches what most enterprise sellers report.

The common reasons pilots stall have little to do with the technology: no named economic buyer, no budget line, success criteria nobody wrote down, and procurement, security and legal review starting only after the pilot "succeeds".

Payment changes behaviour. A pilot with a fee goes through the customer's purchasing process, which means a budget owner signs off, and the customer's team is measured on getting value from it. Many sellers find that even a nominal fee changes engagement noticeably. A common compromise is a pilot fee credited against the first year of the commercial contract if the customer converts.

Liability terms follow market norms. In B2B technology contracts, the usual starting point is:

• a cap on each party's total liability, commonly the fees paid or payable in the previous 12 months (for a pilot, often a fixed sum or the pilot fee);
• exclusion of indirect and consequential losses such as lost profits;
• higher caps or no cap for a few items: breach of confidentiality, data protection breaches, IP infringement indemnities, and wilful misconduct;
• no limit, by law, on liability for death or personal injury caused by negligence, or for fraud. In the UK that comes from the Unfair Contract Terms Act 1977; similar rules apply elsewhere.

Large customers often start with unlimited liability for the supplier. For a startup this is unacceptable, and it is normal to push back.

Deeptech pilots carry extra risks software pilots don't: physical installation on customer sites (health and safety, insurance, damage to equipment), regulated environments (hospitals, grids, aviation), hardware that stays on site after the pilot, and data generated

by your device inside the customer's operation. Each needs a clause.

3. The method#

Step 1: Agree the pilot plan before the contract#

Write a one- or two-page pilot plan with the customer's project owner and, ideally, the budget holder. It becomes a schedule to the agreement.

• Objective: the business problem in their words ("reduce unplanned downtime on line 3").
• Success criteria: 2–4 measurable tests with thresholds ("detects 80% of bearing faults at least 48 hours before failure, with fewer than 2 false alarms a week").
• Scope and duration: sites, units, data, a fixed end date. Most deeptech pilots run 2–6 months.
• Responsibilities on both sides: what you supply; what they supply (site access, data, staff time, utilities). Pilots fail more often on missing customer inputs than on technology.
• Decision: who decides, by when, and what happens next if the criteria are met.

Step 2: Choose the contract form#

Step 3: Negotiate the clauses that matter#

Step 4: Prepare for procurement in parallel#

Ask on day one what the customer's buying process needs: supplier registration, tax and bank forms, insurance certificates, security questionnaire, DPA (4.13), ESG or modern slavery statements, sometimes audited accounts. Start these during the pilot, not after.

Step 5: Run the decision meeting#

Two weeks before the end date, send the results against each criterion and book the decision meeting. Either convert to the commercial SOW or end with a written "no" and the reasons. A clear no is worth more than an indefinite extension.

Worked example#

GridSense, a UK startup making sensors that predict transformer failures, is offered a pilot by a regional electricity network operator.

• The customer's first draft: a free 12-month pilot, all IP "arising" assigned to the operator, unlimited liability, exclusivity in the UK for three years.
• GridSense's response: a pilot plan with three success criteria over six months on 40 transformers; a £45,000 fee credited against year one; GridSense owns its sensors, algorithms and improvements, while the operator owns its network data and gets a

perpetual internal licence to the pilot results; liability capped at £250,000, with a higher cap for data breaches; no exclusivity; pre-agreed pricing of £600 per transformer per year for 12 months after the pilot.

• The landing point: a £30,000 fee credited on conversion, a £500,000 cap (the operator's insurance requirement), first-refusal rights for the operator on a UK distribution partnership instead of exclusivity, and everything else as GridSense proposed.
• Six months later: two of the three criteria are met clearly and the third narrowly missed. The decision meeting agrees a 300-transformer rollout at the pre-agreed price with a revised third criterion. GridSense's seed deck shows a signed commercial contract, not a pilot.

4. Customer types and country notes#

Large corporates. They will send their own terms. Read them for five things before anything else: IP ownership, liability, payment terms (60–120 days is common; push for 30– 45, or milestone payments), termination, and audit rights. Their legal teams expect startups to push back on these, and usually have fallback positions they are allowed to agree.

Hospitals and health systems. Expect a data protection review, ethics or clinical governance approval for anything involving patients, and often a separate research agreement if data is used to develop your product. Regulatory status matters: an unapproved device can usually be used only under a clinical investigation or a research protocol, not sold as a product.

Utilities, grids and critical infrastructure. Expect strict security, safety and site-access rules, cyber requirements for any connected device, and long procurement cycles. Pilots often run through innovation programmes with their own standard terms, which are usually more startup-friendly than the main procurement terms.

Governments and defence.

• India. Central government buying runs largely through the Government e- Marketplace (GeM), which has a Startup Runway section. DPIIT-recognised startups can be exempted from prior-turnover and prior-experience requirements and from earnest money deposits in many public tenders, subject to quality and technical standards. Defence innovation runs through iDEX, with its own contract templates.
• US. SBIR and STTR awards (Phase I and II) are a common route into federal agencies, followed by Phase III or other transaction agreements (OTAs) for production. Federal contracts bring FAR and DFARS clauses, including rules on rights in technical data and

software. Know whether you are delivering with limited, restricted or governmentpurpose rights, and mark your deliverables properly.

• UK. The Procurement Act 2023, in force since 24 February 2025, replaced the old rules and is meant to make it easier for SMEs to bid. Innovation routes include the Small Business Research Initiative (SBRI) and defence programmes run by DASA.

Country contract-law points.

• India. Liquidated damages clauses are enforced only up to reasonable compensation (Contract Act s.74). Stamp duty applies to many agreements and varies by state; unstamped agreements may not be admissible as evidence until duty and penalty are paid. Arbitration clauses should name the seat (for example Mumbai, or Singapore under SIAC rules for cross-border deals).
• US. Hardware sales fall under the Uniform Commercial Code (UCC). Disclaimers of implied warranties of merchantability must be conspicuous, typically in capitals. Choose a governing law (New York or Delaware are common) and a forum.
• UK. Liability exclusions in standard terms must pass the reasonableness test of the Unfair Contract Terms Act 1977. English law governs many international contracts and is well understood.

Tax and invoicing. For cross-border pilots, check withholding tax on fees for technical services (India withholds on many payments to foreign companies, often reduced by a tax treaty), and GST or VAT on imported services. Get it right in the price before you sign.

5. Scripts, mistakes, related playbooks, sources#

Scripts

Asking for a paid pilot:

• "We'd like this to be a proper evaluation with a decision at the end, so we propose a [x]-month pilot at [fee], credited in full against the first year if you go ahead. That gets it into your budget process now, so if it works there's no delay while we find funding."

Setting success criteria with the champion:

"If you had to show your boss in [month] that this was worth doing, what three numbers would convince them? Let's write those down, with thresholds, and agree that if we hit them, we move to [rollout scope] at [price]."

Pushing back on an IP grab:

"We're happy for you to own your data and anything your team invents. What we can't do is assign improvements to our core technology, because we sell the same platform to others and our investors need us to own it. We'll give you a perpetual licence to use everything we deliver, and we'll commit to supporting it."

Pushing back on unlimited liability:

"As a company of [size], unlimited liability isn't something we or our insurers can accept. We'd propose a cap of [amount], with a higher cap of [amount] for data protection and confidentiality breaches, and the usual exclusions for death, injury and fraud. That's in line with what we've agreed with [type of customer]."

When a pilot drifts:

"We're [x] weeks from the end date. Here are the results against each criterion. Can we book 30 minutes with [decision-maker] on [date] to decide whether to roll out, adjust, or stop?"

Common mistakes#

1. Free, open-ended pilots with no end date or criteria.
2. No economic buyer: the champion likes it but has no budget.
3. Signing the customer's IP clause unread, assigning improvements to your own technology.
4. Unlimited liability or uncapped indemnities.
5. No conversion terms, so a successful pilot starts a new negotiation from zero.
6. Starting procurement after the pilot, which adds months.

7. Exclusivity given away for nothing.

8. Ignoring site and safety obligations for hardware installed on customer premises.
9. No DPA when the pilot involves personal data.
10. Extending pilots indefinitely instead of getting a written yes or no.

Related playbooks#

• 4.10 Contractor and consultant agreements
• 4.12 Trademarks and brand protection
• 4.13 Data protection: India's DPDP Act, GDPR and privacy policies
• 4.15 Joint development agreements and who owns co-developed IP
• 4.16 Export controls: ITAR, EAR, SCOMET
• 4.20 Litigation and IP dispute basics

Sources#

• Menlo Ventures, 2025: The State of Generative AI in the Enterprise (production conversion figures, as summarised by Rework).
• Jason Lemkin, SaaStr, "What is the typical conversion from paid pilot to annual contract?".
• UK Unfair Contract Terms Act 1977 ss.2, 3, 11; Procurement Act 2023 (in force 24 February 2025).
• India Indian Contract Act 1872 s.74; Indian Stamp Act 1899 and state stamp acts; General Financial Rules 2017 and DPIIT/DoE procurement relaxations for startups; GeM Startup Runway.
• US Uniform Commercial Code §2-316; Federal Acquisition Regulation and DFARS 252.227 (rights in technical data and software); SBIR/STTR programme rules.