Call Now
Calls answered 24/7 · Free 15-minute consultation · (623) 239-2682 Free 15-minute consultation · (623) 239-2682
← Back to Blog
Contracts

Your First Enterprise Customer Wants a Pilot. What Should the Pilot Agreement Say?

Nadine Deeb, Esq.By · Published · 8 min read

Updated October 2026

A narrow cream paper ticket with a perforated edge and a single copper line, in front of a thick stack of cream pages bound with copper cord, on a deep navy surface.

A prospective customer says it will try your product before it signs anything. Access starts next week, their team is excited, and nobody has asked who owns what comes out of it, whose data goes in, or what happens on the last day.

That is a pilot. It is a real commercial relationship with a short fuse: you are giving a customer access to a product, often with their data and their people involved, for a limited evaluation before deciding whether to enter a broader commercial arrangement. This post is a checklist of what a pilot agreement usually needs to say, written for founders who will be asked to sign one or to write one.

The short answer

A pilot agreement, put in writing before access starts, usually has to answer seven questions.

  1. What is being tested, for whom, and for how long?
  2. What counts as success, and who decides?
  3. Who owns the product, the customer's data, the outputs and the feedback?
  4. What stays confidential?
  5. What does each side promise, and what is the product not promised to do?
  6. How does the pilot end?
  7. What happens next if it works?

The label matters less than those answers. Pilot, trial, beta, proof of concept and design partner are labels for arrangements that can overlap but may differ in purpose, product maturity and commercial terms. Some pilots sit under an existing master agreement as a short order form, and others stand alone. Either way, the answers should be recorded in signed pilot terms or an order form that clearly identifies any governing master agreement, rather than left unresolved in scheduling emails.

Start with what the pilot is

Before drafting anything, settle four facts, because each one changes the document.

  • Is the pilot paid or unpaid?
  • Will it touch the customer's live data, or only sample data?
  • Is it meant to turn into a subscription if it works?
  • Which of the customer's teams will use it, and who at the customer is allowed to bind the company?

A free two-week test on sample data and a paid multi-month deployment against live production data are different documents, even if both are called a pilot.

Scope, term and an end date

  • Name what is in. List the features, environments and users the pilot covers.
  • Name what is out. List custom features, extra integrations and extra locations that are not included, so the pilot does not quietly become unpaid product development.
  • Set a start date and an end date. Access with no end date can drift into ongoing or production use beyond the intended evaluation, without clear agreement on its duration or terms.
  • Say what support is included. A pilot customer who expects a production service level and a founder who expects to answer questions when time allows will both be unhappy by week three.

What counts as success, and who decides

Write the criteria down before the pilot starts, in terms that can be measured: time saved on a task, an error rate, a number of workflows completed. "It works" is not a criterion.

Name the person at the customer who decides whether the pilot succeeded, and whether that person controls the budget. A pilot can succeed on the product and still stall in procurement, a security review or a legal review that nobody scheduled. Ask at the start what the path from "yes" to a signed agreement looks like, and how long each step usually takes. The answer often changes how long the pilot should be.

Who owns what

Four categories to address are the product, customer data, outputs and feedback.

  • Your product. State that the customer receives access for evaluation and no ownership. Say who owns improvements, fixes and customizations made during the pilot. If a customer's template says the customer owns work product from the engagement, read that clause closely before you sign.
  • Their data. Limit your right to use the customer's data to running the pilot and measuring its results, for the length of the pilot. If personal information is involved, the data-protection terms that would sit in a full agreement may need to be in place before the data flows. See our guides to enterprise SaaS contracts, MSAs and DPAs and to subprocessor obligations when you use AI vendors.
  • Outputs. Say what ownership and use rights each side has in what the product produces for the customer during the pilot, and whether you may use it to measure performance. For an AI product, also say whether the customer's data or outputs may be used to train or improve models. See data licensing and AI contract terms and what to put in an AI product's customer contract.
  • Feedback. Customers give feedback during a pilot. Say whether you may use it to improve the product, and whether that permission continues after the pilot ends. Check whether the document says the customer grants you the right to "use" feedback or says that you "own" it, because those are different promises.

Confidentiality: your roadmap and their data

A pilot puts your unreleased product, your roadmap and your methods in front of the customer's people, and puts the customer's confidential information in front of yours. A mutual confidentiality term that covers the pilot belongs in the document. It should also limit who at the customer may have access, and address reverse engineering and the publication of benchmarks. For the common ways a confidentiality term fails, see NDA mistakes that make them unenforceable.

This is also potentially a trade-secret question. Reasonable secrecy measures are one part of the statutory definitions, not the whole test. The federal definition of a trade secret asks whether the owner "has taken reasonable measures to keep such information secret."1 Arizona's and California's definitions ask whether the information is "the subject of efforts that are reasonable under the circumstances to maintain its secrecy."23 Texas's definition asks whether the owner "has taken reasonable measures under the circumstances to keep the information secret."4

Whether a particular set of steps meets those standards is a question for a lawyer on the facts. For a pilot, the practical point is that the steps you take, including what you put in writing before access begins, are the kind of facts a lawyer will ask about later. For more on how trade secrets differ from other protection, see trade secrets vs. patents.

What each side promises

A pilot product may be unfinished. If so, the agreement should explain that it may change, may contain defects, and is provided for evaluation rather than production use, and state which warranties, if any, apply.

  • Say what you do commit to. If the customer's security questionnaire asks about your practices, make sure your answers and the pilot paper do not contradict each other.
  • Read liability and indemnity as closely as you would in a full contract. A pilot with live data can carry real exposure. How a pilot's liability limits compare with those in the eventual agreement is a business and legal decision; see how much your liability cap should be.
  • Decide how an incident is handled. If the customer's data is in the pilot and something goes wrong at you or at one of your vendors, who is told, by whom and when? See who has to notify your customer when an AI vendor has a security incident.

How the pilot ends, and what happens next

  • Ending. Say that the pilot ends on its end date, that either side may end it earlier on written notice, that access stops, and that the customer's data is returned or deleted within an agreed period. Confidentiality should continue after the pilot.
  • What happens next. If the pilot is meant to lead to a paid agreement, say so and say which terms will apply. If it is not, say that nothing obliges either side to continue. Make clear whether either side is committed to a rollout and what further agreement or approval is required.
  • No exclusivity. Watch for exclusivity or non-compete language that would restrict who else you may sell to.
  • Publicity. Say whether either side may name the other or publish results. Absent written consent, the safer default is no.

If the customer sends its own paper

Large customers often send their own pilot or evaluation template. Read at least these provisions: ownership of work product and improvements, the feedback clause, whether confidentiality is mutual or runs only one way, liability and indemnity, use of the customer's data, exclusivity, termination, and who signs for the customer. For help deciding which terms matter in a customer's paper, see do you need a lawyer to review a SaaS contract, and for why early agreements matter later, see diligence-grade contracts.

If the pilot sits under an existing master agreement, an order form may do much of this work, provided the master agreement covers the relevant issues and the order form clearly states any pilot-specific terms. For how a master agreement and its attachments fit together, see MSA vs. SOW.

A checklist before access starts

  • The pilot is described as paid or unpaid, with sample or live data.
  • Start date, end date and the users and environments in scope are written down.
  • Out-of-scope items are listed.
  • Success criteria are measurable, and a named person decides.
  • Ownership of the product, improvements, outputs, the customer's data and feedback is addressed.
  • A mutual confidentiality term covers the pilot.
  • The product is accurately described as pre-release or production-ready, as applicable, with its permitted use and warranty position stated.
  • Liability and indemnity are read, not assumed.
  • Ending, data return or deletion, and the path to a paid agreement are stated.
  • Exclusivity and publicity are addressed.
  • Someone with authority has signed for each side.

What this post does not cover

It does not cover how a court would read a particular customer's pilot paper, privacy-law duties that attach to specific kinds of data, the procurement rules that govern government customers, or sector-specific rules for regulated industries. Each of those depends on facts and documents this post does not have. The only statutes cited are the four trade-secret definitions above.

How we can help

Accord & Shield Legal reviews and negotiates SaaS agreements, order forms and AI-related contract terms for technology companies in Arizona, California and Texas. To better understand the scope of your matter, you can book a free 15-minute initial consultation.

This article is general information, not legal advice. Reading it does not create an attorney-client relationship. How any of these points applies to your pilot depends on your agreements and your facts; consult an attorney about your situation.

Citations

  1. 18 U.S.C. § 1839(3)(A), https://www.govinfo.gov/content/pkg/USCODE-2023-title18/html/USCODE-2023-title18-partI-chap90-sec1839.htm ↩︎
  2. Ariz. Rev. Stat. § 44-401(4)(b), https://www.azleg.gov/ars/44/00401.htm ↩︎
  3. Cal. Civ. Code § 3426.1(d)(2), https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=3426.1 ↩︎
  4. Tex. Civ. Prac. & Rem. Code § 134A.002(6)(A), https://statutes.capitol.texas.gov/Docs/CP/htm/CP.134A.htm ↩︎

Book an Initial Consultation

Book a free 15-minute initial consultation to talk through a pilot you are about to start, or the pilot paper a customer has sent you. Bring a short, nonconfidential description of the situation and any real deadline.

Please do not send contracts, documents or confidential information until the firm has agreed in writing to represent you.

Book a free 15-minute consultation Call (623) 239-2682