Proof of Concept Request template

Use this proof of concept request form to propose a bounded evaluation before committing to a rollout. It asks for a testable hypothesis, baseline, success threshold, representative scenario and decision owner. When a baseline is missing or external dependencies exist, the relevant follow-up stays visible so the evaluation can be reviewed with its unknowns intact.

Use this template Start free — no card

13 questions · Free plan: 500 responses/month · fully customizable

Editable split-screen artwork
Animated question transitions
2 built-in logic rules

Interactive — fill it in like a respondent would.Open full width

What’s inside

The questions this template ships with — rename, reorder, or delete any of them in the builder.

01Your nameShort text

02Reply emailEmail

03Organization and evaluation nameShort text

04Business problem and testable hypothesisLong text

05Is a current baseline available?Multiple choice

06Who will measure the baseline before testing, and how?Long text

07Baseline value or pending measurement, success threshold and unitsLong text

08Representative scenario and test stepsLong text

09Does the test depend on external systems or approvals?Multiple choice

10Required systems or approvals and dependency ownerLong text

11Proposed test window and participant rolesShort text

12Constraints and conditions for stopping the testLong text

13Decision owner, evidence to review and go/no-go meetingLong text

When to use this template

Qualifying an evaluation request before a solutions team allocates time
Agreeing what evidence a buyer and technical team need from a trial
Separating a measurable proof of concept from a general product demonstration

Tips to get more from it

Include units and a repeatable scenario with every threshold.
Keep a missing baseline marked pending; do not substitute an estimate without labeling it.
Use approved sample or synthetic data and arrange environment access through your normal process.

Write criteria that can produce a decision

A useful hypothesis identifies a problem and an observable change. Faster processing is too broad to evaluate by itself. Processing 50 representative requests in under two hours gives the team a workload, metric and threshold to discuss. Record the current measurement alongside the target so reviewers can decide whether the expected improvement matters.

If the baseline is unavailable, name who will measure it and how before the test starts. Define the steps, sample characteristics and conditions that should stay consistent between the baseline and the evaluation. A small synthetic test may establish feasibility without proving production throughput; record that limitation in the review rather than presenting the result as a guaranteed rollout outcome.

Bound the test and plan the exit

Specify the proposed window, participant roles, required systems and dependencies. Required access, security review or another team's availability may prevent a start on the requested date. An unknown dependency should stay visible with an owner to investigate it. The form records requirements and does not provide access approval or provision a test environment.

Agree on stop conditions and the evidence the decision owner will review. If a prerequisite fails or the test exceeds its time budget, decide whether to stop, revise the scope or request more time. At the go/no-go meeting, compare results against the criteria and record any untested assumptions. A demonstration can show a feature; this evaluation needs a repeatable test and a documented decision.

Example response and next steps

Illustrative example, not a real customer submission.

A fictional operations team wants to evaluate request triage before rolling out a new workflow.

Business problem and testable hypothesis: Manual triage delays the daily queue. The proposed workflow should reduce time spent on a fixed sample without losing required categories.
Is a current baseline available?: Yes
Baseline value or pending measurement, success threshold and units: Four hours for 50 synthetic requests today. Target: under two hours for the same sample, with all required categories recorded.
Decision owner, evidence to review and go/no-go meeting: Operations lead Arun reviews elapsed time and category checks at Friday's evaluation meeting.

How to use the response

The Yes answer skips the baseline measurement plan. Confirm that timing starts and ends at the same steps in both runs, and retain the category checks alongside the time result. A pass on this sample supports a next-stage decision; it does not establish production capacity.

Before publishing your version

Test both baseline choices and all dependency choices. Replace sample instructions with your permitted evaluation data policy and identify who reviews proposed access and dates.

Questions people ask

How is a POC request different from a demo request?

A demo shows product capabilities. A proof of concept proposes a defined scenario, measurable criteria and an evidence-based decision. This form collects that evaluation brief rather than scheduling a presentation.

Can I submit without a baseline?

Yes. Select Not yet and describe who will measure it and how. Keep the value pending in the metric field until it is measured; the request can be reviewed without pretending the evidence already exists.