Creating a demo storyboard

+ Use Template

+ Use Template

+ Use Template

Tactics

A POC has four parts:

1. Deciding whether to run one

2. Designing it

3. Running it

4. Closing it out

To make each part concrete, we follow one illustrative deal from the first request to the signed contract.

The example deal: A vendor sells an AI tool that helps sales reps build personalized content for their accounts. The buyer is a medical device company with 600 sales reps. Their VP of Sales Enablement saw a demo, liked it, and asked for a pilot. A competitor has already offered a pilot as well.

1 Decide whether the deal warrants a POC

A POC is a strategic trade-off, not a default. It takes time and resources from your team so the first question is whether this deal justifies that cost. To determine if the POC is worth doing, weigh these five inputs:

1. Deal size

2. The competitive set

3. Close timing

4. Multi-product potential

5. Resourcing the POC will take

The same inputs decide whether the POC is free or paid. A marquee enterprise logo will usually justify a free pilot. A $5,000 to $10,000 deal usually won't.

Here is how the example deal scores.

The example deal clears the bar. When most of your answers fall in the right-hand column, offer a lighter form of proof, such as a hands-on workshop, instead of a full POC.

Trade the POC for the access the deal needs

A POC is valuable to the buyer, which makes it your best opportunity to ask for what you, the seller, need from the buyer. Before agreeing to one, secure a conversation about what the full purchase will cost and a path to the person who will sign.

The most effective approach is to make the ask part of your own approval process, so it reads as a requirement you and the buyer meet together rather than a demand from the seller.

"If we want to be able to approve this free pilot over the next 90 days, I need this information to go to my boss to get approval."

In the example, the AE tells the VP of Sales Enablement that two things are needed to approve a free four-week pilot: a rough budget range, and a 30-minute call with the CRO, who will sign the contract. The VP of Sales Enablement sets up the call, and the CRO shares the one result that would make the purchase an easy decision for them: new reps producing account-specific content in their first month.

2 Design the POC

With the deal qualified and the CRO engaged, the next step is deciding what the POC will prove, to whom, and with what observable outcomes.

Decide what you are validating, and write it down

Every POC needs success criteria, executive buy-in, and a defined scope. Without them, the scope keeps growing and the pilot never reaches a conclusion.

For AI products, the scope comes down to one question. Are you validating the technology, or the business outcome?

The buyer in our example would love to know whether the tool raises win rates, but that could take a year to measure. For most products, the right scope is the set of results strongly correlated with the outcome, not the outcome itself. In four weeks, the vendor can prove whether reps can build personalized content, how quickly they can do it, whether it stays on brand, and whether reps want to keep using it.

The exception is outcome-based pricing. When you charge for an outcome, the outcome becomes part of what you are testing. If a vendor charges per resolved support ticket, the buyer should see tickets resolved during the pilot. That is why some AI-native vendors now run paid pilots lasting several months that convert into full contracts, and why some report signed revenue, pilot revenue, and opt-out revenue as separate categories.

Your pricing model is a useful guide to what the pilot needs to prove.

Once the scope is clear, write it on one page and get the buyer to agree to it before kickoff. Here is the scope for the example deal. Note that the CRO's priority from the access call is built into the success criteria.

Plan for every member of the committee

The VP of Sales Enablement asked for the pilot, but she is one of several people who have to agree. Each group in the committee validates something different, and a POC that satisfies only one of them leaves the rest of the decision unmade.

TestBox's data shows that win rates are lower when only one stakeholder accesses the POC. Successful deals are much more likely to have at least two engaged stakeholders, with roughly twice as many engaged sessions.

With that in mind, map the committee before kickoff, and confirm who from each group will take part. In the example, it looks like this.

Build an environment that matches the stage

Not every buyer needs a full POC. Hands-on proof comes in three forms:

Whatever the format, what the buyer hears and what they see must match. If the conversation is about their workflow and the screen shows a generic dashboard, the buyer has to imagine the connection, and most won't.

In the example, the SE loads the environment with the buyer's brand assets and a sample of their real accounts, so the first page a rep builds looks like their own work.

3 Run the POC

Once the environment is live, the risk shifts from what you built to how the buyer uses it.

Stay in control while they test

Buyers who test a product without guidance often assume it can do things it can't. When they hit that limit, they lose confidence and don't convert. This is the central weakness of a purely product-led approach.

"You have to have a level of control to make sure people are not making assumptions on what your products can and can't do."

The fix is to combine three practices: hands-on workshops, frequent check-ins with the champion, and direct outreach to the people using the product day to day.

The third practice often produces the most persuasive evidence of the whole POC. When James ran pilots at Showpad with field sales teams, he called the reps using the product, collected their comments, and assembled them into a quote deck for leadership. One rep told him that in the two weeks he'd had the product, he had made it home for dinner with his family, something he hadn't managed in months. A comment like that tells an executive more than a usage report can.

In the example, those practices become a four-week plan that every member of the committee can see from day one.

Watch usage and act early

You can't guide a POC you can't see. TestBox's analysis found that 28% of custom POCs are never opened. Among those that are, time spent is a clear signal. Buyers in won deals spent an average of 94 minutes testing, compared with 53 minutes in lost deals.

Check usage at least weekly, and act on what you find while there is still time to change the result. In the example, the week 1 review shows that only two of the eight reps in one region have logged in. The AE asks the VP of Sales Enablement about it and learns their manager was out that week. The SE runs a 20-minute session for that group the next morning.

Five metrics are worth tracking across demos and POCs: engagement rate, time spent, feature interaction, conversion from demo to the next sales call, and POC win rate.

Keep the AE and the SE working together

The common failure in a POC is the handoff, where the AE passes the deal to the solutions engineer or forward deployed engineer and steps back. The better approach is to run both roles in lockstep, with regular internal and external meetings, and to divide responsibilities by the outcomes each person drives for the customer rather than by job description.

The AE's role is changing as AI takes on more of the research, pipeline, and forecasting work. That leaves the AE free to focus on the buyer's internal approval process, such as the CRO update in week 3. The SE's job is to build a technical champion, not to finish a task and leave. Many technical buyers would rather talk to an engineer than to a sales rep, which makes the SE the natural owner of that relationship.

4 Close it out, and carry the proof past signature

The readout is where the POC turns into a decision. Present results against the success criteria the buyer agreed to at the start, show each stakeholder the evidence for the part they validate, and include what users said in their own words.

In the example, the readout shows that reps built on-brand pages in an average of 22 minutes, 15 of the 20 pilot reps used the tool every week, and all five new hires shipped account-specific content in their first month. It closes with three quotes from reps collected in week 2. The VP of Sales Enablement takes it to the CRO, who already knows what to look for because they defined it.

For the buyer, signature is the start of the journey. A well-run POC keeps paying off after the contract is signed. The buyer's team already knows the product, integration requirements are understood, key workflows have been tested, and training needs are defined. The same evidence becomes the foundation for the business case, covered in the champion chapter, and for the rollout plan.

If you take one thing from this section into your next deal, make it the scope one-pager. Writing down what you will validate, who will validate it, and what happens when the criteria are met prevents most of the mistakes in the next section.