A proof-of-concept agreement: what to fix before you start

A proof-of-concept agreement needs seven short clauses written before any work starts. The ones that decide whether the pilot ever ends are what is in it, how success is measured, who supplies what, the decision date, and what happens if the answer is yes. Without them your engineers may keep working for free. A single page that both sides sign is enough.

Why do pilots turn into free work?

Because the pilot starts when it is convenient and ends when someone decides. The buyer sees no cost in a longer test, and you do not want to be the one who calls time. Each new request seems small. The scope grows by one process, one report, one more department.

Our post on why RPA pilots stall looks at what goes wrong inside the pilot. This one sits earlier: the paper you agree before the first line of work.

The seven things to fix

Put these on one page. Wording below is a starting point, not legal advice; ask your own adviser to look at the final version.

1. Purpose. One sentence on the question the pilot answers. "To test whether the tool can read and post vendor invoices from the existing email inbox into the accounts system."
2. Scope. What is in, and a short list of what is out. "One mailbox, one invoice format, one accounts entity. Not included: other formats, other entities, training."
3. Success measure. A number, how it is measured and who measures it. "At least 90 of 100 test invoices posted correctly, checked by the accounts manager against the originals." The 90 is only an example. Choose a number you have actually tested, not an aspiration.
4. Inputs from the buyer. The access, data and people you need, with dates. "Sample of 100 invoices and a test login by [date]. A named person available for one hour twice a week."
5. Dates. Start, end and a decision meeting date. "The pilot ends on [date]. The buyer will tell us at a meeting on [date] whether to proceed."
6. What happens after. If the measure is met, the buyer will take the next step described: a priced proposal, a signed order by a date or a conversation about it. If it is not met, the pilot closes and both sides keep their own materials.
7. Housekeeping. Confidentiality, who owns anything built, how data will be handled and deleted, and who pays for what. A lawyer should draft this part.

Number 6 is the clause buyers most often resist. A buyer who will not write what they will do on success has told you something about the deal.

How do you word a clause the buyer can accept?

Short, fair and plainly written clauses are easier to get signed. Offer a mirror for each of your asks:

• You commit to a start date and an end date; they commit to a decision date.
• You commit to a number you can reach; they commit to supplying the data you need to reach it.
• You offer a fixed amount of your time; they agree that extra work will be quoted separately.

If the buyer's procurement team has a standard pilot template, read it for the same seven points and add the missing ones as a schedule. When the buyer's terms differ from your norm, decide in advance who in your firm may approve the change; that is what a deal desk is for.

For example: a logistics firm and a cloud migration pilot

Imagine an invented cloud services firm in Bengaluru that offers a free pilot to a Chennai logistics company: move its dispatch application to a cloud test environment and show that it runs. The agreement is an email that says "a two-week pilot". The buyer's IT head sends the application three weeks late. Then the operations manager asks for two more reports to be moved. Then the owner asks to see it run with last month's data. Ten weeks in, the firm has spent more engineer time than on some paid projects, and the buyer is "still evaluating".

One page would have helped. It would name one application and three listed reports. Success would be the application running on a copy of last month's data, with dispatch screens loading within a time the buyer names. The buyer would supply the code and a database copy by a date, and a late delivery would move the end date by the same number of days. The decision meeting would sit on a fixed date.

When the operations manager asked for extra reports, the firm could then point to the page and offer a small, priced add-on. The buyer may still say no, and the firm may lose the goodwill of a free favour, but the choice is now clear to both.

When should you refuse the pilot or charge for it?

Refuse, or charge, when:

• the buyer will not name a decision maker or a decision date;
• the pilot needs more than a few days of your skilled people;
• the buyer wants to use the output for their own purposes without a purchase, such as copying your design for an in-house team;
• you are one of several vendors running the same free pilot with no shortlist rule;
• the success measure is a feeling.

A paid pilot is not a punishment. It tells you the buyer values the answer. Credit the fee against the first order if you want to keep it friendly.

What if the pilot succeeds but nothing is signed?

Ask for the meeting you wrote into clause five, and bring a short proposal for the next phase. If the buyer goes quiet, point to the page and ask what has changed since it was signed. Keep a note of the answer. Sometimes the budget moved or the champion left, and a proposal that fits the new reality is the right move. If the buyer simply wants more free work, say that the pilot has ended and offer a paid step.

Write the page before the next pilot starts

Take the pilot you are about to offer and write the seven points on a single page. If the buyer cannot agree to number 6, ask why before any work begins. Other work for automation firms, IT services and cloud providers is under technology, and when you want help with the terms and the proposal that follows, tell us what you need.