IoT Proof of Concept: A Pilot That Ends in a Decision

The sensors are in, the dashboard is live, and everyone is keen for the first week. Three months later it is still "in trial", and nobody can say whether it worked, because nobody defined what working meant. The budget request for scaling up never gets written, and the floor team quietly stops opening the dashboard.

A good IoT proof of concept (POC) is not a technology demo. It is a small experiment designed to answer one business question and to end with a decision: go, adjust, or stop. This article covers how to design one, from choosing the problem to writing up the decision.

Why an IoT proof of concept often ends without a decision

• The question is vague, such as "let's see what IoT can do".
• Success criteria are set after the data arrives, so any result can be read any way.
• There is no baseline. Without numbers from before, improvement cannot be proven.
• Nobody in operations owns it. Only IT or the vendor cares about the outcome.
• There is no end date, and nobody prepares the next step.
• The test site is too special. The vendor looks after it daily, so results do not reflect normal conditions.

POC, pilot, and rollout answer different questions

Stage	Question it answers	Typical scale
Proof of concept	Can we get the data reliably, and does it answer the problem?	One machine or a few points
Pilot	Does the team use it day to day, and do business results show?	One line or area
Rollout	How do we scale it at a sensible cost and support level?	Many lines or sites

Many plants merge the POC and the pilot, which is fine as long as both questions are written down and answered separately.

Start with one problem whose cost is already visible

Choose a problem that already costs money and shows up in some record: downtime on one critical machine, excess kVArh charges on the bill, a cold room that keeps drifting above its limit, or a compressor that runs all night. Write it as a one-sentence hypothesis:

"If we monitor current and temperature on the line 2 transfer pump motor with alarms, maintenance can act on early symptoms before the pump stops, so unplanned downtime on that line falls."

Avoid two traps: a problem so rare it may not occur during the POC, and one whose fix needs major changes far beyond it. Cost components such as measuring points, installation, and subscriptions are covered in our article on the cost of IoT in a plant.

Set success criteria before any sensor goes in

Good criteria cover three layers: technical, adoption, and business. The table is only an example; adjust the numbers to your problem.

Layer	Example criterion	How to measure
Technical	At least 98% of scheduled data arrives; under 2% difference from a reference instrument	Platform data history, reference readings
Adoption	Every critical alarm is acknowledged within 30 minutes	Alarm log and acknowledgements
Business	Unplanned pump downtime falls compared with the previous three months	Maintenance records

Add a decision rule the sponsor signs off before the start, for example: move to a pilot if all three layers are met; adjust and rerun if the technical layer passes but adoption does not; stop if the data cannot be collected reliably at this site. If there are no records to serve as a baseline, treat the first one or two weeks as observation before the team acts on alarms.

How long a POC should run

Fix the end date at the start, and let the problem's cycle set the duration rather than a round number. The POC must capture several occurrences of what you want to detect, plus normal variation such as shift changes, holidays, and product changes.

A problem that shows up weekly can be proven in a few weeks. An event that happens once every few months is hard to prove in a POC; pick a more frequent indicator, or use historical data as the baseline. Do not count the first days, while devices are new and the team is adjusting. Extensions are fine if the reason is written down and there is a new question to answer.

Who needs to be involved

Role	Responsibility in the POC
Sponsor (plant or operations manager)	Approves the criteria, makes the final call, prepares the budget for the next step
Process owner (production or maintenance lead)	Defines the problem and makes sure alarms are acted on
Operators and technicians	Use the system daily and give feedback
IT and OT	Network, security, and PLC access
Technology partner	Devices, platform, installation, and the results report

One person on the plant side must be accountable. Involve operators from day one; they decide whether alarms are acted on, as our article on operator training and IoT adoption explains.

After the POC: three possible decisions

• Go. Build the pilot or rollout plan from the POC's numbers: points, cost per point, installation time, and who maintains it. This is also when the architecture is settled, including whether to build your own IoT system or use a platform.
• Adjust and rerun. If the data is reliable but the team does not use it, the fix is usually alarm thresholds, screens, or training, not the hardware.
• Stop. The data is unreliable, or the problem turns out smaller than expected. That result still has value, because it prevents a large investment in the wrong direction.

Close the POC with a one or two page report covering the question, criteria, results against targets, decision, cost, and next step. That report goes to the budget meeting.

Things to watch

• Pick a representative site, not the easiest or the most troubled one.
• Make sure the data can leave through export or an API, so POC results are not locked in one system.
• Bring IT in early for network and security approval; late approval often delays a POC by weeks.
• Keep POC and rollout costs apart. Cost per point in a trial is not necessarily the cost at scale.

Frequently asked questions

How is a POC different from a vendor demo?

A demo shows features with sample data. A POC uses your own machines, data, and problem, with success criteria you set.

How many measuring points should a POC have?

Just enough to answer the question, often one machine or a few points. Too many points turn the POC into a small rollout that is hard to evaluate.

Does an IoT POC have to cost money?

Not always. The INCLUDE Community plan is free with no time limit for 3 devices and 2 users, enough to test one point. Check data retention, though: comparing several weeks needs a plan that keeps data longer.

What if only some criteria are met?

The decision rule agreed at the start covers it. Otherwise the sponsor decides from the data by a clear deadline, instead of extending the POC indefinitely.

IoT proof of concept with INCLUDE

Through our industrial digital transformation consulting, the INCLUDE team maps your operations, ranks opportunities by how quickly they pay back against their cost, and tests the top one at a single point before scaling. The outcome is a phased roadmap with measurable targets per phase, ready for management.

On the technical side, POC data can come from IncludeBox sensors, Modbus RTU devices through IncludeGateways, or your own devices over MQTT and HTTP. Alarms can go to email or Telegram depending on the plan. Prices for every plan, including device quotas and data retention, are published on the pricing page.