How to Run a PoC: 5 Steps, Evaluation Criteria, a Scorecard, and Not Losing the Deal (2026)

Editorial note: This article is written by the editorial team at Terasu, a digital sales room (DSR) product. The guidance on how to run a PoC, set evaluation criteria, and estimate cost is intentionally tool-agnostic; the later sections show how a DSR can be used so that sellers (vendor reps) don't let a PoC turn into a lost deal. Cost figures and statistics are benchmarks — always confirm individual quotes and legal questions with your own advisors.

"We've been told to run a PoC, but we have no idea where to start." — this is a shared pain for both the buyer evaluating a SaaS or IT tool and the seller (vendor rep) proposing it.

A proof of concept (PoC), when designed correctly, is a powerful way to judge "should we roll this out in production?" at low risk. Yet in many organizations, teams run the PoC with vague evaluation criteria and end up with a fuzzy "it seemed pretty good," or they get stuck repeating the validation forever and never move to production — a state known as "PoC hell."

This article organizes how to run a PoC into five steps, and covers what competing articles tend to leave vague: concrete evaluation criteria, a ready-to-use PoC scorecard, and how sellers keep a PoC from becoming a lost deal — all from both the buyer's and seller's perspective.

What Is a PoC? Meaning and Purpose First

A PoC is a small-scale effort to verify whether a new technology, product, or idea "can actually deliver results" before a full rollout. Let's start with the meaning of the term and how it differs from adjacent concepts that are easy to confuse. For a broader look at the definition and how PoCs are used across industries, see what a PoC is.

The Meaning of PoC

PoC stands for Proof of Concept. It refers to the process of testing the hypothesis "does this idea or technology actually work in our environment?" using real data in conditions close to real operations.

The purpose of a PoC is neither to over-build the product nor to make adoption a foregone conclusion. Its essence is to gather the evidence needed to decide: proceed to production (Go), change direction (Pivot), or stop (Stop). Lose sight of that purpose, and the PoC itself becomes the goal — validation for validation's sake.

PoC vs. PoV, PoB, MVP, Prototype, and Trial

PoC is easily confused with similar terms. Distinguishing what each one validates keeps your conversations with internal stakeholders and vendors aligned.

When evaluating a SaaS or IT tool, using the vendor's free trial or paid evaluation edition to validate against your own data is effectively a PoC. The dividing line between a successful and a failed rollout is whether you stop at "we signed up for the trial" or set evaluation criteria and run it as a proper PoC.

Why a PoC Is Necessary — and When It Fits or Doesn't

A PoC is necessary because the cost of a failed production rollout is high. If you discover only after a company-wide rollout that "the field won't use it" or "it can't integrate with existing systems," the entire investment and timeline are wasted. A PoC is insurance that lets you experience — and avoid — that failure "small and early."

That said, not every adoption needs a PoC. Distinguish the cases where it fits from where it doesn't.

If "running a PoC" becomes an end in itself and you impose one even where the decision is obvious, you only slow the rollout. Use a PoC where uncertainty is high and the investment is large — that's the guiding principle.

The 5 Steps to Run a PoC — Overview

A PoC proceeds through the following five steps. Most competing articles omit each step's rough duration, but since it matters for planning, we include it here.

Duration varies widely with scope and how fast your organization makes decisions. An AI-related PoC often takes 3–6 months overall, while a trial-style SaaS PoC frequently wraps up in 2–4 weeks. What matters is deciding "when we will make the call" (a timebox) before you begin. A PoC with no deadline is the entrance to the PoC hell we'll cover later.

STEP 1: Define the Goal and Hypothesis

The first step is to make "what are we running this PoC for?" concrete enough to state in one or two sentences. If this is vague, everything downstream drifts.

When defining the goal, articulate these three as a set:

• The question to validate (What): e.g., "Can we automate first-response replies to inquiries with AI while maintaining response quality?"
• Why validate it (Why): e.g., "First responses cost 200 hours a month, so there's large room to cut."
• The validation hypothesis (Hypothesis): e.g., "About 70% of routine inquiries can be auto-answered by AI, at quality on par with the current process."

The key is to write the hypothesis in a verifiable form. "Can AI make the work more efficient?" is too vague to judge pass or fail later. Make it a hypothesis that includes numbers and scope, such as "automate 70% of routine inquiries."

Let's see the difference between a vague goal and a verifiable one with concrete examples.

Each item on the right includes "target, number, and period," so you can judge pass or fail after execution. Once you've written the goal, ask yourself, "Can I answer this with a Yes/No when it's over?" If not, it isn't concrete enough yet.

A common failure here is setting "adopting the product" as the PoC's goal. Start a PoC on the premise of adoption, and you'll cherry-pick favorable data, conclude "success," and break in production. Keep the goal firmly on "deciding whether to adopt." Even from the seller's (vendor rep's) side, whether you can build this goal definition together with the buyer is what determines whether you can lead the rest of the PoC.

STEP 2: Set the Evaluation Criteria (Pass/Fail Line)

Setting the evaluation criteria is what most determines whether a PoC succeeds or fails. Many guides stop at "decide your success criteria in advance," but what actually troubles practitioners is "so, concretely, what do we measure, and at what level?" This is where we fill that gap.

Design the evaluation criteria from the following five perspectives. For each perspective, decide the "metric," the "pass line," and "how you measure it" as a set before the PoC begins — that's the iron rule.

You don't need to score full marks on every perspective. Separate "must-have conditions you can't drop (Must)" from "nice-to-have conditions (Want)," and fail the PoC if even one Must is missed — this keeps decisions from wobbling. For example, "integrates with the existing CRM" is a Must, while "the reporting features are advanced" is a Want.

Numeric pass lines are most accurate when you measure the baseline (current value) before deciding them. To claim "cut workload by 30%," you first need to measure the current workload. A target with no baseline can't even be judged as achieved or not.

The most important thing is not to conveniently change the criteria afterward. Lowering the pass line when the PoC results are poor is a classic anti-pattern that robs the validation of meaning. Agree on the criteria with all stakeholders before starting (the buyer's decision-maker and field users, the seller's rep) and keep a record.

If you're unsure how to set the pass-line level, the following can guide you. For ① problem-solving/impact, set "the minimum line that clearly beats the status quo" (staying at status quo means there's no point investing). For ② technical feasibility, there are many non-negotiable Must conditions, so judge on a binary "can/can't." For ③ operational fit, since field opinion is subjective, quantify it as "the percentage who said they'd keep using it." For ④ cost-effectiveness, viewing it by payback period (how many months to recoup the investment) makes it easy to compare side-by-side with other investment proposals. For ⑤ adoptability, always include it in the criteria, because underestimating early stumbling blocks (learning cost, support) leads to it going unused in production.

STEP 3: Build the Team (Buyer and Seller Roles)

A PoC is a technical validation and, at the same time, an organizational consensus-building process. Start without deciding "who evaluates and who makes the Go/Stop call," and even a good result leaves the decision hanging.

A PoC team has roles on both the buyer's and the seller's side. In a SaaS-adoption PoC, it only works when the two mesh.

The one that's most often overlooked is the buyer "involving the decision-maker early." If the person with decision authority hasn't agreed to the PoC's goal and criteria, even a good result stalls at "I wasn't told" or "there's no budget." The absence of that executive/decision-maker is one of the main causes of the PoC hell we'll cover below.

From the seller's viewpoint, whether you have a touchpoint with the decision-maker — not just the PoC owner — and whether you've secured the evaluation axes directly drives win probability. How to navigate multi-department decisions in enterprise deals is covered concretely in our enterprise SaaS DSR case study.

STEP 4: Execute the PoC (Scope, Duration, Data Collection)

Once the team and criteria are set, it's time to execute. Success in the execution phase hinges on whether you can narrow the scope.

• Narrow the scope to a minimum: Not all features or all departments — narrow to "the one operation and one team with the most expected impact." Get greedy, and validation drags on and the evaluation blurs.
• Validate in an environment/data close to production: Not ideal sample data, but actual operational data and actual users. "Success" in a too-clean environment won't reproduce in production.
• Keep measuring the data you need for evaluation: Record the metrics you set in STEP 2 throughout execution. Visualizing progress along the way — rather than reviewing only after it's over — makes the decision smoother.
• Respect the timebox: Don't keep extending with "maybe we can improve it a bit more." Move to the decision once, at the set time.

For data collection, the trick is to gather both "quantitative" and "qualitative" data. Quantitative data (workload, accuracy, processing time) is the basis for the pass/fail call; qualitative data (field voices, where people stumbled, requests) explains why the numbers came out as they did and tells you the improvement points after production rollout. With only quantitative data you can't tell "why it failed," and with only qualitative data you can't prove "whether it actually worked."

Concretely, keeping records in the following form makes the decision phase smoother:

• Baseline: The current values before validation begins (the numbers already measured in STEP 2)
• Measured values during validation: Record the trend per metric, ideally daily or weekly
• Field feedback: Note where people stumbled, what was good, and requests as they arise
• Unexpected events: Trouble or discoveries not in the plan (key clues to production risk)

When problems arise during execution, sort them by "does this touch a Must condition, or a Want condition?" Must-related problems (e.g., can't integrate with the core system) decide whether production rollout is possible, so validate thoroughly; Want problems (e.g., the screen is a little hard to use) should just be logged as improvement requests, without stopping the validation. If you can't make this distinction, a trivial usability complaint stalls the whole validation and the decision gets deferred.

STEP 5: Decide the Result (Go/Pivot/Stop)

Finally, judge the collected data against your evaluation criteria. Rather than a binary "success/failure," thinking of the decision as three choices — Go/Pivot/Stop — makes the next action clear.

What's important in the decision is to clearly distinguish "Pivot" from "Stop." Repeating a vague "let's try once more" turns an intended Pivot into an endless PoC hell. If you pivot, always re-decide "what we'll change and against which criteria we'll judge next."

Summarize the decision into a concise report that pairs numbers with rationale, in a form the decision-maker can act on. Don't stop at "make the report and finish" — for a Go, record the next actions for production rollout; for a Stop, record the lessons learned. That's the trick to not wasting the investment.

At minimum, a decision report should include these four: ① the validation goal and hypothesis (what you set out to confirm), ② the measured value and pass/fail for each criterion, ③ the overall decision (Go/Pivot/Stop) and its rationale, and ④ next actions with owners and deadlines. For decision-makers especially, leading with "did it meet the Must conditions?" and "is payback in sight?" — rather than fine-grained logs — speeds the call. Conversely, a report missing these four leaves the decision-maker unable to decide, resulting in a "let me take this back," which is exactly how a deal stalls.

How to Build a PoC Scorecard (Template)

Running your evaluation criteria "by gut feel in the moment" leads stakeholders' subjective views to collide, and you can't reach agreement. It's effective to use a scorecard, assigning a score and weight per perspective and deciding by consensus.

Below is a PoC scorecard structure you can reuse as-is. Drop it into a spreadsheet and use it.

[PoC Scorecard]

■ Basic info
  - Product/technology under validation:
  - Validation goal (1–2 sentences):
  - Validation period: ____/__/__ – ____/__/__
  - Evaluators: Buyer PM / Field / IT / Decision-maker

■ Evaluation criteria (fixed before start — do not change)
  Perspective          | Type | Metric              | Pass line         | Weight
  ① Problem-solving     | Must | Workload reduction  | 30%+              | 30%
  ② Technical feasibility | Must | CRM integration/error rate | Integrates, <5% | 25%
  ③ Operational fit     | Want | Intent to keep using | 80% of field      | 20%
  ④ Cost-effectiveness  | Must | Payback period       | Within 12 months  | 15%
  ⑤ Adoptability        | Want | Time to learn        | 30-min training   | 10%

■ Decision (fill in after execution)
  Perspective          | Measured | Pass? | Score (0–5) | Weighted score
  ① Problem-solving     |          |       |             |
  ② Technical feasibility |        |       |             |
  ③ Operational fit     |          |       |             |
  ④ Cost-effectiveness  |          |       |             |
  ⑤ Adoptability        |          |       |             |
  ─────────────────────────────────────
  Total weighted score: ____ / 5.0

■ Overall decision (if even one Must fails, automatically Stop/Pivot)
  □ Go (to production)  □ Pivot (change direction)  □ Stop (halt)
  Rationale:
  Next action:

The crux of this sheet is the operating rule that if even one Must condition is missed, you do not automatically Go, no matter how high the weighted score. It's the safeguard that stops you from glossing over a case like "the total is high but it can't integrate with the core system" using a high score.

At the end of this article, we point you to a downloadable PoC scorecard built on this exact structure.

PoC Cost and Timeline Benchmarks

The cost of a PoC varies widely with the scale of validation, the complexity of the technology, and whether you outsource. These are benchmarks based on publicly cited figures, organized by scale.

Much of the cost is labor. If you're evaluating a SaaS tool, there are many cases where using the vendor's free trial or evaluation edition and running it yourself lets you conduct the PoC at almost no cost. A staged design of "first run the free trial in-house against your criteria" → "move to a paid full validation only if needed" is effective for keeping cost down.

For AI-related PoCs, even external forecasts show the bar to adoption is high. In 2024, the research firm Gartner predicted that "by the end of 2025, at least 30% of generative AI projects will be abandoned after the proof of concept" (source: Gartner, July 2024). It's a data point that underscores the importance of locking down your evaluation criteria and production-rollout rules before investing in a PoC.

Why PoCs Fail, and How to Fix It (Escaping PoC Hell)

PoC hell is the state of repeating PoCs without ever moving to production — stuck perpetually in the validation stage. The difficulty of turning a PoC into production results shows up in the data. As noted above, Gartner forecasts at least 30% of generative AI projects will be abandoned after PoC by the end of 2025 (source: Gartner, July 2024). Widening the lens to DX (digital transformation) overall, Japan's IPA (Information-technology Promotion Agency) reported in its "DX White Paper 2023" that only 58.0% of Japanese companies said they were "seeing results" from DX — meaning roughly 40% have not reached sufficient results (source: IPA "DX White Paper 2023," FY2022 survey). Neither figure represents a PoC-specific failure rate, but both underscore how hard it is to "turn what you tried into production results."

The causes of PoC failure lie less in the technology itself than in "flaws in design and operation." Here are the major failure patterns, organized by the causal chain of root cause, symptom, and fix.

The common prescription across all of these boils down to a single point: "before you begin, decide the evaluation criteria and the production-rollout decision rule." Most PoC hell happens because teams try to think about criteria and team structure only after they've started validating. Typical patterns of post-adoption failure and how to avoid them are also organized in detail in why DSR rollouts fail.

For Sellers: Keeping a PoC from Becoming a Lost Deal

So far the view has been mainly the buyer's (the evaluator's). But for the seller (vendor rep) proposing SaaS or IT, the PoC is the biggest crest of the deal. Run the PoC well and it leads straight to a win; get dragged into PoC hell and the deal goes cold and is lost.

There are four things a seller should manage in a PoC:

• Secure the evaluation axes: Support the buyer in building their criteria, and align on the perspectives (Must conditions) where your product is evaluated fairly. A PoC with vague criteria flows by without a decision.
• Have a touchpoint with the decision-maker: Not just the PoC owner — create a state where the person who makes the Go/No-go call has the criteria and progress shared with them. A PoC without the decision-maker won't move to production even if it succeeds.
• Visualize progress and next actions: Always make clear "which step we're at now, and who does what next." If the buyer's deliberation goes silent and unattended, the deal is lost.
• Detect a drop in temperature early: Catch signs that the buyer's responses have cooled (materials aren't being viewed, replies are slow) and act.

Managing these by individual intuition or chasing email and chat threads has its limits. This is where a digital sales room (DSR) that centralizes the PoC is effective.

In a digital sales room like Terasu, you create a dedicated "PoC Room" per customer and consolidate the materials, evaluation axes, schedule, and next actions needed for validation in one place. What's more, because you can track proposal materials and scorecards down to "who viewed which page, and when," the buyer's deliberation status (i.e., temperature) becomes visible. Whether the decision-maker is viewing materials, whether the field's interest continues — you can see the substance of a deliberation that was previously invisible, so you can prevent a loss to silence and make your next move.

Mapping PoC Room use onto the five PoC steps looks like this:

For example, if you invited the decision-maker but the materials have never been viewed, that's a danger sign that "the decision-maker hasn't entered the deliberation." Conversely, if a specific page (say, pricing or integration specs) is viewed repeatedly, you know that's the buyer's interest or concern, and can act ahead of it in the next meeting. Being able to grasp the PoC's temperature by "behavioral data" rather than "gut feel" is the biggest advantage of managing a PoC in a DSR.

Where to position the PoC in your sales process and how to move it forward is best designed together with B2B sales process design and how to visualize deal progress, which further lowers the risk of a loss. For the big picture of the DSR itself, see the complete guide to digital sales rooms.

What to Do After the PoC (Deciding and Running the Rollout)

The answer to "what should we do after the PoC?" is, for each of Go/Pivot/Stop, as shown in the STEP 5 decision table. What we want to emphasize here is that even with a Go, you don't roll out company-wide all at once.

Even when a PoC succeeds, production reveals loads, exceptions, and operational walls that weren't visible during validation. So inserting an MVP (minimal production operation) or a pilot in one department after the Go further lowers the risk when scaling up. Start small, confirm results, and expand — that's the standard playbook.

When you do proceed to company-wide rollout, an estimate of rollout duration by scale is essential. The rollout schedule by company size and tips for shortening the timeline are covered in detail in our comparison of DSR rollout timelines. And how a large deal with multiple departments moved the decision forward — from PoC to production rollout — is illustrated in our enterprise SaaS DSR case study (deal cycle cut by 40%).

Summary

How to run a PoC comes down to five steps: (1) define the goal and hypothesis, (2) set evaluation criteria, (3) build the team, (4) execute, and (5) decide. The single biggest factor separating success from failure is deciding, before you begin, the "pass line (evaluation criteria)" and the "production-rollout decision rule (Go/Pivot/Stop)."

• Make the criteria concrete with "perspective × metric × pass line × measurement method," and separate Must from Want
• Involve the decision-maker early, and respect the timebox
• Sellers secure the evaluation axes and visualize progress and temperature to prevent losses

Get these right, and you avoid both the PoC that ends in "it seemed pretty good" and the endless PoC hell. Start by using this article's PoC scorecard to articulate the pass line for your own validation.