How to Define PoC Success Before Installing Any Equipment

Why criteria must be set before the equipment arrives

Most monitoring and analytics pilots fail less because the technology is weak and more because the buyer and vendor never agreed what "working" means — and the conversation typically starts only after equipment has been installed, or after a polished demo that ran on the vendor's data rather than your site. Once hardware is in place, the pressure to justify the investment colours how results are read, and each side interprets the same outcome in its own favour. Vague criteria are a standing invitation to retroactively redefine success.

Define success before installation as a written contract of expectations. If you cannot state, in one sentence, the measurable operational change the system must produce and the threshold that makes it a pass, you are not running a proof of concept — you are funding a demonstration on your budget. A written criterion protects both parties: it gives the buyer a defensible right to stop, and it gives the vendor the exact conditions under which it earns the production order.

Separate "can it work" from "does it help"

A common mistake is collapsing two different questions. Technical feasibility asks whether the system detects events with acceptable accuracy on your cameras, data and network. Operational value asks whether operators change their actions in response and whether a real process improves — faster response to an incident, fewer manual rounds, earlier detection of a condition. These are different tests with different criteria, and mixing them produces deployment decisions built on the wrong evidence.

Before procurement, write down which question the engagement must answer. If the technology is already proven in comparable environments, a full feasibility proof of concept may be unnecessary — a bounded pilot on a live workflow may suffice. If the main uncertainty is real-world accuracy at your site — lighting, weather, occlusion, shift and traffic patterns — run the feasibility test on your own cameras, not on vendor-supplied footage.

• A feasibility PoC answers: can the model perform the task on your data and conditions.
• A pilot answers: do real operators use the system and does a business outcome change.
• The pilot usually follows selection and measures adoption and value; the PoC precedes selection.

The anatomy of a usable success criterion

A usable criterion is not "improve efficiency". It has five parts: the metric, its units, the baseline measured before installation, the pass threshold, and the evidence source. Example: "cut the time from event detection to a logged corrective action from the current four-hour average to two and a half hours, a 30% reduction, measured daily from the operator journal over four weeks." A formula like that leaves no room for negotiation after the trial closes.

Separate detection metrics from operational metrics. Detection metrics are the false-positive rate (alerts for events that never happened) and the false-negative rate (missed events) in your conditions. Vendors often quote accuracy from controlled test settings, so ask for figures from sites with similar lighting, camera angles, occlusion and shift schedules. False positives create alert fatigue and erode trust; false negatives leave risk undetected. Aggregate accuracy alone should never justify a go decision.

• Metric and units: event, time, rate or share, with a defined counting method.
• Baseline: the current value recorded before installation using the same method.
• Pass threshold: the minimum measurable improvement that makes the test a pass.
• Evidence source: the log, report or clip that verifies the result after the trial.

What to lock down in the pre-installation session

Before any equipment is ordered, hold a working session that ends in a signed document covering: the single operational decision the system must improve and its owner; the measurement method for the baseline; the zones, cameras and devices in scope and what is deliberately excluded; false-alert caps per shift and minimum detection thresholds; data governance — where video is processed, retention periods, access roles and restrictions on using recordings for model training; and the measurement period plus the decision date.

Where possible, run the proof of concept on cameras you already operate through open standards such as ONVIF or RTSP — this cuts cost and speeds the start. If new hardware is required, define in advance which result and which threshold trigger the equipment purchase, so the trial does not become an unconditional order. Visit the live site before installing: mounting positions, fields of view, lighting, blind spots and real traffic flow all change what the system can do. A pilot designed without a site review tests assumptions, not your environment.

A decision gate with three doors — and honest limits

Agree before launch on a decision gate with three outcomes. Advance to deployment when all pre-agreed metrics are met and no security, integration or compliance flags remain open. Conditional extension when metrics are partially met and the cause is identifiable and fixable within scope — for instance, not enough night-shift data. Stop when the cause is systemic: poor data quality, a mismatched architecture or an unsurmountable regulatory constraint. Name in advance who evaluates results and who has the authority to stop the trial.

Honest limits matter as much as metrics. A documented stop is a useful outcome: it prevents a larger investment built on an assumption. Do not let the trial extend indefinitely — without a fixed decision date it becomes free professional services for the vendor. Remember that a proof of concept proves the machine can work; it does not prove market demand, repeatability on other sites, or that operators will keep using the system once leadership attention fades. Those are checked in a subsequent bounded pilot and in a production contract with measurable service levels.