30-Day IoT Pilot Plan: 10 Assets, 3 KPIs, Go or No-Go

Short answer

A 30-day IoT pilot tests one question on a small scale: does live data from 10 real assets change a decision your team makes? Fix three KPIs before day one: data availability, alert precision and one operational result. Run four weekly stages, connect, tune, run, measure, then hold a go or no-go meeting on day 30.

Key takeaways

A pilot answers one business question with 10 real assets, not a vendor demo, and ends with a written go, extend or no-go decision on day 30.
Write the baseline, the three KPI formulas and their targets before day one, so the result cannot be bent later.
Change alert rules only in week 2, then freeze them, so week 3 shows how the rules behave without anyone watching.
The three KPIs are data availability, alert precision and one operational result tied to money or risk.
Any built-in ENTEK IoT solution can be piloted this way, with your own compatible devices, hardware bought through the ENTEK marketplace or an RFQ, or the hardware-included option.

01Why 30 days and only 10 assets

A pilot is not a demo. A demo shows what a platform can do; a pilot shows what it does with your assets, your sites and your people. Skipping that step is a known risk. In a 2017 Cisco survey of 1,845 IT and business decision-makers, 60 percent of IoT initiatives stalled at the proof of concept stage, and only 26 percent of companies had an initiative they considered a complete success. Microsoft’s 2019 IoT Signals report found that about 30 percent of projects fail at proof of concept, often because the cost is high or the business benefit is unclear. A short pilot with a fixed end date answers the second problem directly. Ten assets are enough to see patterns across shifts and sites, and few enough that one person can check every alert by hand. Thirty days cover four working weeks, which includes several cycles of deliveries, refills or trips.

Steps

Set the baseline, KPIs and targets before day one
Week 1: connect the 10 assets
Week 2: tune alert rules and recipients, then freeze them
Week 3: run hands off and log every alert
Week 4: measure the three KPIs and decide on day 30

02The week-by-week plan

Before day one, write down three things: the ten assets, the person who owns the pilot, and today’s baseline for each KPI, taken from logbooks, dip readings or timesheets. Without a baseline, day 30 has nothing to compare against. Week 1 is connection. Install or plug in each device, register it, and confirm that every asset reports and shows in the right place on the map. Week 2 is tuning. Set the alert rules, choose who receives each one, and adjust hold times and cooldowns when a rule fires too often. This is the only week in which rules change. Week 3 runs hands off. Nobody edits a rule; the team logs every alert as real or false and notes what action followed. Week 4 is measurement. Calculate the three KPIs, compare them with the baseline and the targets, and send a one-page summary to the decision makers before the meeting on day 30. The first table below lists the output of each week.

03The three KPIs and how to calculate them

Keep the list to three, and write each formula before the pilot starts. The first KPI is data availability: the share of expected hours in which each asset actually reported. It tells you whether the hardware, the wiring and the cellular coverage work on your sites. The second is alert precision: the share of alerts that turned out to be real events after someone checked. Low precision teaches people to ignore messages, and that ends a rollout faster than cost does. The third is one operational result tied to money or risk, chosen per solution: stops with complete photo proof for cargo locks, running hours that match timesheets for machines, or unexplained fuel drops confirmed by a manual dip for tanks. A worked example: 10 assets over 30 days give 7,200 expected asset hours. If the assets reported in 6,912 of those hours, availability is 96 percent. If 40 alerts fired and 30 were real, precision is 75 percent.

04The go or no-go meeting on day 30

Hold the decision meeting on day 30, not later, and invite the people who will pay for the rollout and the people who will use it. Each KPI has a target written before day one, so the meeting compares numbers with targets instead of opinions. In the Cisco survey, collaboration between IT and the business side was the top success factor, cited by 54 percent of respondents, so both sides should sign the result. There are three outcomes. Go means all three KPIs met their targets and the team already acts on alerts without reminders. Extend means one KPI missed for a reason you can fix, such as a badly mounted sensor or a weak coverage spot, so you run two more weeks on that point only. No-go means the operational result did not move, or most alerts were still false after tuning. A clear no-go has value too: 64 percent of Cisco’s respondents said lessons from stalled or failed projects helped speed up later IoT investment.

05Running the pilot on ENTEK IoT

Any built-in ENTEK IoT solution can be piloted this way: Smart Lock for cargo, Fuel Tank for diesel tanks, Fleet for vehicles, Construction for machines, and Generator for genset online or offline status and the site map. Adding a device takes three fields: a name, the IMEI and the device type, picked from 1,500+ compatible tracker and sensor models. Alert rules cover min value, max value, open too long, no signal for a set time and exit from a drawn zone, with hold time and cooldown for the tuning week. Rules are checked every 30 seconds, and messages arrive by email, SMS or WhatsApp within about a minute. The Monitoring page shows 7-day uptime and stale devices, which feeds the availability KPI. For hardware, you can use compatible devices you already own, buy through the ENTEK marketplace or an RFQ at entek.ai, or ask about the hardware-included option, where the device, software and SIM come in one monthly fee on a 24-month contract.

The 30-day pilot, week by week
Stage	Days	Goal	Main tasks	Output
Before start	Day 0	Baseline	Pick the 10 assets, name a pilot owner, record current KPI values, write the targets	A signed one-page pilot brief
Week 1	Days 1 to 7	Connect	Install devices, register name, IMEI and type, confirm each asset reports and sits in the right place	10 assets reporting on the map
Week 2	Days 8 to 14	Tune	Set alert rules and recipients, adjust hold time and cooldown, fix mounting or coverage problems	Final rule set, frozen on day 14
Week 3	Days 15 to 21	Run hands off	No rule changes; log each alert as real or false and record the action taken	An alert log with outcomes
Week 4	Days 22 to 30	Measure and decide	Calculate the three KPIs, compare with baseline and targets, hold the meeting on day 30	A written go, extend or no-go decision

The three KPIs: formula and worked example (10 assets, 30 days, 720 hours each)
KPI	Formula	Worked example	Example target you might set
Data availability	Hours with at least one report ÷ (assets × pilot hours) × 100	6,912 ÷ 7,200 × 100 = 96%	95% or more on every site
Alert precision	Alerts confirmed as real ÷ all alerts fired × 100	30 ÷ 40 × 100 = 75%	70% or more in week 3, with no rule changes
Operational result (cargo locks example)	Stops with complete photo proof ÷ all stops × 100	54 ÷ 60 × 100 = 90%	Better than the baseline by a margin agreed on day 0

Go or no-go checklist for the day 30 meeting
Check	Go if	No-go if
Data availability	Target met on every site	Still below target after fixes in week 2
Alert precision	Target met in week 3 without rule changes	Most alerts still false after tuning
Operational result	Moved against the baseline by the agreed margin	No change from the baseline
Team behaviour	Recipients act on alerts without reminders	Alerts ignored or forwarded with no action
Spot checks	Manual dips, timesheets or photos match the platform	Spot checks disagree with the platform
Next phase	An owner and a budget are named for the rollout	No owner or no budget

How often IoT projects stall at proof of concept

Initiatives that stall at proof of concept (Cisco 2017)60 %

Projects that fail at proof of concept (Microsoft 2019)30 %

Companies with a fully successful initiative (Cisco 2017)26 %

Cisco survey of 1,845 decision-makers (May 2017) and Microsoft IoT Signals (July 2019). The two surveys used different samples and questions.

Figures and sources

Share of IoT initiatives that stall at the proof of concept stage: 60% (Source: Cisco, survey of IoT decision-makers (May 2017), as of 2026-10-19)
Share of companies with an IoT initiative they considered a complete success: 26% (Source: Cisco, survey of IoT decision-makers (May 2017), as of 2026-10-19)
Completed IoT projects not considered a success: about one in three (Source: Cisco, survey of IoT decision-makers (May 2017), as of 2026-10-19)
Respondents citing collaboration between IT and the business side as the top success factor: 54% (Source: Cisco, survey of IoT decision-makers (May 2017), as of 2026-10-19)
Respondents who said lessons from stalled or failed projects helped speed up their IoT investment: 64% (Source: Cisco, survey of IoT decision-makers (May 2017), as of 2026-10-19)
Number of IT and business decision-makers surveyed (US, UK and India): 1,845 (Source: Cisco, survey of IoT decision-makers (May 2017), as of 2026-10-19)
Share of IoT projects that fail in the proof of concept stage, often because implementation is expensive or the benefit is unclear: 30% (Source: Microsoft, IoT Signals research report (July 2019), as of 2026-10-19)
IoT decision-makers who say there are not enough skilled workers available: 47% (Source: Microsoft, IoT Signals research report (July 2019), as of 2026-10-19)

Questions

How many devices do I need for an IoT pilot?

Ten assets are usually enough. That number shows patterns across shifts and sites, and one person can still check every alert by hand. Pick assets that represent your real conditions, including at least one hard site with weak coverage or heavy use.

Can the pilot be shorter than 30 days?

You can, but you lose a stage. Two weeks are enough to connect and tune, not to run the rules hands off and measure the result. Thirty days give one clean week where nobody changes a rule, and that week is the honest test.

What if most of the alerts are false?

Fix it in week 2: raise or lower the threshold, add a hold time so short spikes do not fire, and set a cooldown so one event does not send many messages. If alerts are still mostly false in week 3, extend the pilot on that point or record a no-go.

Do I have to buy the hardware for a pilot?

Not always. You can connect compatible devices you already own, buy hardware through the ENTEK marketplace or an RFQ at entek.ai, or ask ENTEK about the hardware-included option, which combines device, software and SIM in one monthly fee on a 24-month contract.

Which ENTEK IoT solutions can I pilot?

Any built-in solution: Smart Lock, Fuel Tank, Fleet, Construction, and Generator for online or offline status and the site map. Other needs, such as energy sub-metering or cold rooms, are delivered as a project, so the pilot scope is agreed with ENTEK first.

Who should attend the day 30 decision meeting?

The pilot owner, the person who will pay for the rollout, and at least one person who received the alerts every day. In Cisco’s 2017 survey, collaboration between IT and the business side was the top success factor, cited by 54 percent.

A 30-Day IoT Pilot: 10 Assets, 3 KPIs, One Go or No-Go