A paid trial project for a new customer: scope, price and the decision at the end

A new customer is interested but unsure. The project is large, you have not worked together before, and neither side knows whether the collaboration will go well. Many suppliers answer with a discount or a free proof of concept. Both tend to disappoint: the discount lowers the price of the whole project without lowering the risk, and unpaid work gets low priority on the customer's side. A small paid trial is often a better answer.

What a paid trial is

A paid trial is a short, separately priced piece of work with its own deliverable. It is not a sample and not the first slice of a project that is already promised. Its job is to let both sides test the working relationship and a key assumption on a small budget.

Typical examples are a working prototype of the one screen that worries the customer, an integration with one system to prove the data can be read, or a written analysis with a tested estimate for the full build. The customer ends the trial with something useful whatever happens next.

Why charge for it

Payment changes behaviour. A customer who pays for the trial sends the access, answers questions and attends the review. A supplier who is paid plans the work properly instead of squeezing it between other jobs. The price also tells you something: a customer who refuses to pay a modest amount for a defined result may not pay the full invoice either.

Charging does not have to be large. The aim is a sum that is easy to approve without a long internal process, yet high enough to be taken seriously. If you work with a fixed-price estimate for a small software job, a trial is a natural place to use it.

Choose one question

Before you write the scope, finish this sentence: "At the end of the trial we will know whether ..." Good examples:

• the data in the customer's current system can be used without manual cleaning;
• the key workflow can be done in three clicks by a real user;
• the full project fits the customer's budget and deadline.

If you have several questions, you have a project, not a trial. Pick the one whose answer would change the customer's decision the most.

Write a scope you can finish

A trial fits in two to six weeks. Put the following on one page:

1. The question from the previous step.
2. The deliverable: what exactly the customer receives, in which form and where.
3. What the customer provides: access, sample data, a named contact who answers within two working days.
4. What is not included: for example design polish, production hosting, extra integrations or training.
5. The dates: start, a mid-point check and the review meeting.

The "not included" list matters most. If the customer expects the trial to turn into a finished product, the trial will fail even when the work is good. Our article on a short not-doing list for scope control shows how to write one.

Price it simply

Quote a fixed price for the trial, based on the days you expect and a small reserve. State what the price covers and what happens if the customer asks for more: extra work is quoted separately in writing. If you are unsure how to arrive at a figure, start from your real hourly rate rather than from what feels acceptable.

Agree the payment terms in the same document. For business customers in the UK, the government explains your rights on late commercial payments and interest, which is worth reading before you set the due date. Many suppliers invoice a trial in full at the start, or half at the start and half at the review. Choose what you would be comfortable with if the customer stopped after the first week.

Decide the decision in advance

This is the part most trials skip. Before work begins, write down:

• What result leads to the next phase. For example: "If the prototype handles the three test cases from the customer's real data, we proceed to a quote for phase one."
• What result ends the work. For example: "If more than a fifth of records cannot be read, we stop and the customer keeps the analysis."
• What is in between. Say plainly that a partial result may mean a second, shorter trial or a changed scope.
• Who decides on the customer's side, and by which date.

When the criteria exist before the work, the review meeting is a comparison, not a negotiation. Neither side has to argue about whether the trial "went well".

Handle customer data with care

A trial often needs real data, and real data may include personal information about the customer's staff or clients. Ask for the smallest sample that answers the question, agree where it is stored and when it is deleted, and note this in the scope. The ICO provides advice for small organisations on handling personal data, which is a useful starting point.

Run the decision meeting

Book the review at the start, 30 to 45 minutes, with the person who can say yes. Bring the deliverable, a short list of what you found, and one recommendation. Then walk through the criteria you agreed:

1. What was the question, and what is the answer?
2. Which criteria were met, which were not?
3. What do you recommend: proceed, adjust or stop?
4. If proceeding, what is the scope, price and start date of the next phase?

Send a written summary the same day. If the answer is "stop", say thank you, hand over the deliverable and leave the door open. A clean ending is a good result; it saved the customer from a larger mistake, and they remember who helped.

What to do this week

1. Pick one hesitating customer or lead and write the one question a trial would answer.
2. Draft a one-page scope with the deliverable, the customer's inputs and the "not included" list.
3. Set a fixed price and payment terms you would accept if the work stopped early.
4. Write the proceed and stop criteria, and propose a review date.
5. Send the page to the customer as an offer, not as a negotiation starting point.

Sources

• GOV.UK, Late commercial payments: interest and debt recovery: the rights of businesses when customers pay late.
• ICO, Advice for small organisations: guidance on handling personal data.