How to Scope a Proof of Concept with a Customer

A proof of concept (POC) is a short, focused piece of work that answers one question: will this approach work for this customer, well enough to be worth doing properly? A good POC ends with a clear decision. A bad one drifts for months, tries to do everything, and proves nothing.

POC vs prototype vs pilot

	Proof of concept	Prototype	Pilot
Question it answers	Can this work, on their real data?	What should it look like and feel like?	Does it work in daily use, at small scale?
Users	The project team	A few users giving feedback	A real team doing real work
Data	Real but limited	Often sample or mock data	Real, live data
Typical length	2 to 6 weeks	Days to weeks	1 to 3 months
Ends with	A go or no-go decision	A design people agree on	A decision to roll out

The one-page POC plan

Write it before building anything, and get the sponsor to agree:

1. The question: “Can we classify incoming support tickets into the right queue automatically?”
2. The success measure and target: “At least 85% correct on 500 recent tickets, labelled by their team.”
3. The baseline: how it works today, such as “agents route tickets by hand, about 2 minutes each”.
4. In scope: one data source, one region, one team, English tickets only.
5. Out of scope: written down just as clearly, such as other languages or automatic replies.
6. What we need from you: data access, a labelled sample, a contact who answers questions within a day.
7. Timeline and review date: when results are presented and who decides.
8. Next step if it succeeds: usually a pilot, with an estimate of effort.

Choosing a success measure

• Tie it to the business goal: time saved, errors avoided, revenue affected.
• Make it measurable on real data in the POC timeframe.
• Agree how it is measured: who labels the test set, which period of data.
• Record the baseline first, so improvement can be shown.

Keeping scope under control

New ideas appear constantly during a POC. Keep a “later” list, share it in weekly updates, and only change the scope when the sponsor agrees to change the plan or the date. Saying “yes, and it goes on the list for the pilot” keeps goodwill without losing focus.

Presenting results

Show the measured result against the target and the baseline, what worked, what did not, the risks for a full rollout, and a recommendation. Be honest about partial results; a clear “not yet, because” builds more trust than an oversold success.

Common mistakes

1. No success number, so the result is a matter of opinion.
2. Demo data instead of real data, so the POC proves nothing about production.
3. Scope creep, until the POC becomes an unplanned project.
4. No decision meeting, so the POC never ends.

Key takeaway

A proof of concept answers one question on real data, with a success number, a baseline, tight limits and a review date. Write a one-page plan, keep a “later” list for new ideas, and end with an honest decision. Next: connecting systems with API integration.