Short answer
Evaluate an IoT monitoring vendor on what happens when things go wrong, not on the feature list. Ask how data behaves during a connectivity outage, who owns the data, how devices are replaced, and what the contract covers after year one. Those answers separate a real platform from a reseller of devices with a dashboard.
Key takeaways
- The offline-buffering question is the single most revealing test: it separates a platform from a device that posts to the cloud.
- A unified platform is the wrong choice when one vertical dominates your requirement, a specialist will beat it there.
- Data ownership and export format matter more than any feature, because they determine whether you can ever leave.
- Ask for the failure rate and replacement process, not the specification sheet, installed reliability is what you buy.
- Under Saudi PDPL, ask specifically where personal data sits and how cross-border transfer is handled.
01Why the feature list is the wrong place to start
Every vendor in this market can show real-time tracking, geofencing, fuel level, alerts and reports. The feature lists converge because the underlying capabilities are broadly available, which means comparing them tells a buyer almost nothing about how the systems differ in practice.
What actually differs is behaviour under stress. Two platforms with identical feature lists will diverge sharply the first time a site loses connectivity for a day, a sensor drifts out of calibration, or a device fails in the field and needs replacing without losing its history.
So the useful evaluation is not a matrix of ticks. It is a small set of questions about failure, ownership and the second year of the contract, the parts a demo never covers, and the parts that determine whether the system is still in use eighteen months later.
02The one question most vendors answer badly
Ask what happens to the data when a device loses connectivity for an hour, or for a day. It sounds like an infrastructure detail. It is in fact the clearest available test of whether you are buying a system or a sensor with an internet connection.
A good answer explains three things: where readings are stored while the link is down, how they are kept in the correct order, and how they are synchronised when the connection returns. A weak answer is some version of "it reconnects automatically," which describes the radio and says nothing about the data.
The reason it matters is that connectivity at remote sites is not continuous, and the gaps are not random, they cluster exactly where coverage is worst, which is often where the assets most at risk are. A system that silently discards what it could not transmit will show a flat line across precisely the window an investigator wants to examine.
03Who owns the data, and can you leave with it?
Monitoring data accumulates value slowly. A month of readings is worth little; three years of readings is the baseline that makes anomaly detection possible at all. That asymmetry means the switching cost rises quietly over the life of the contract.
Ask two concrete questions. First, can you export the full history, not a summary report, the underlying readings, in a documented format, on demand, without a fee? Second, what happens to that history if the contract ends: is it delivered, retained, or deleted, and on what timetable?
A vendor who answers both plainly is not necessarily better on features. But they are offering a relationship you can exit, and that changes the risk of the decision more than most line items on a comparison sheet.
04What is the installed failure rate, and who replaces a device?
Specification sheets describe devices in laboratory conditions. What a buyer actually operates is a population of devices on real sites, and the number that matters is how many of them are still reporting a year later.
Ask for that figure and for the replacement process behind it: who diagnoses a suspected failure, how long a replacement takes to reach a remote site, whether the swap preserves the asset history, and who pays. A vendor with a large installed base will have these answers because they have had to build the process; one without will improvise.
This is where installed scale is legitimately informative. Many vendors publish client and device counts on their own sites. Treat any such figure as the vendor’s own published claim with a date attached, and ask what proportion of that base is in your specific application.
05When is a single unified platform the wrong choice?
A unified platform earns its keep when you genuinely operate several asset types and need them read against each other, a fuel drop interpreted alongside which vehicle was on site, or a container opening alongside where the truck was.
It is the wrong choice when one requirement dominates everything else. A buyer whose real problem is deep engine and controller diagnostics on a generator fleet will be better served by a generator specialist, whose product goes further into that one domain than any general platform reasonably can. The same is true for pure regulatory fleet telematics where compliance reporting is the whole requirement.
The honest test is to write down what you would lose by choosing the specialist. If the answer is "cross-asset context I would actually use," the unified platform is justified. If the answer is "nothing I have a use case for," it is not, and no amount of integration narrative changes that.
06How should the pilot be designed?
A pilot that only proves the devices report is a waste of a quarter. Reporting is the easy part; every vendor in a shortlist can achieve it. The pilot should be designed to test the things that are hard to reverse later.
Include at least one site with genuinely poor connectivity, because that is where the buffering answer gets verified rather than believed. Include at least one deliberate device failure or removal, to observe the replacement process end to end. And include an export of the accumulated data in the documented format, actually performed, not described.
Set the success criteria before starting and write them down. "Fewer false alerts" is not a criterion; "the dismissal rate on generator tanks falls below a stated level by week six" is. Vendors will meet the bar you set, so the bar has to describe the outcome you actually need.
07What to ask about data protection under Saudi PDPL
Saudi Arabia’s Personal Data Protection Law entered into force in September 2023, with full enforcement from September 2024, overseen by the Saudi Data and Artificial Intelligence Authority. Monitoring systems routinely touch personal data, driver identity, access records, location tied to an individual, so the question is not whether PDPL applies but how the vendor handles it.
Ask three things concretely. Where is personal data stored? How is transfer outside the Kingdom handled, given SDAIA’s regulation governing cross-border transfer? And what is the retention and deletion policy for identifiable records once their operational purpose has passed?
Be sceptical of a claimed certification presented as an answer. What you want is a description of the actual arrangement, locations, transfer mechanism, retention periods, because that is what you would have to defend, and a certificate on a slide is not a substitute for knowing where the data sits.
08Reading the specification sheet critically
Specifications are true and frequently irrelevant. A fuel sensor with a published maximum error of ±1%, such as the Eurosens Dominator RS, is describing laboratory conditions; the number you will live with is dominated by mounting position and calibration to the tank.
Ingress ratings are similarly precise and similarly easy to over-read. Under IEC 60529, IP67 means dust-tight and able to withstand temporary immersion, while a rating such as IP69K describes resistance to high-pressure, high-temperature washdown. Higher is not automatically better; it is better for a specific exposure, and the relevant question is which exposure your site actually presents.
The interface line is usually more decisive than the accuracy line. RS-485 is a differential multi-drop bus, so several sensors can share a run to a gateway and each returns an addressed digital value, which is a materially different failure profile from an analogue voltage any part of the loop can influence.
09What the second year of the contract actually costs
First-year pricing is usually the most competitive number a vendor will show, and it is the least representative of what the system costs to own. Hardware is a one-off; connectivity, platform subscription, support and replacements recur.
Ask for a three-year total that names each recurring line separately: per-device connectivity, per-asset platform fees, support tier, and expected replacement volume at the failure rate the vendor quoted. If any of those cannot be stated, that is itself an answer about how well the vendor understands its own economics.
Ask also what changes if you double the fleet. A price that scales linearly is honest; one that improves sharply at volume was inflated at the pilot size; one that worsens indicates a cost the vendor has not yet absorbed. None of these disqualifies a vendor, but a buyer should know which one they are signing.
10A short checklist you can take into the meeting
Ten questions cover most of the risk. What happens to data during an outage, and how is order preserved? Can we export the full raw history on demand, in a documented format? What is the twelve-month field failure rate, and who replaces a device? Does a replacement preserve asset history?
Then: where does personal data sit under PDPL, and how is cross-border transfer handled? What is the three-year total with each recurring line named? What changes at double the fleet size? Which of our asset types is your weakest, and who would you concede it to?
That last question is the most useful one in the list. A vendor who names a competitor honestly is telling you where their product genuinely ends, and that is information a feature matrix will never contain. A vendor who claims no weakness has told you something too.
11How to use references and site visits properly
A reference call arranged by the vendor will be with a satisfied customer, which is useful but limited. The question that gets past the curation is not whether they are happy; it is what surprised them after month three, and what they would specify differently if they started again.
A site visit is worth more than three calls. Ask to see a working deployment and pay attention to what is not in the demo: how many devices are visibly offline on the dashboard, whether the alert list has unread items going back weeks, and whether the operator navigates confidently or hunts for screens.
Ask also to speak to a customer who reduced their deployment or left. A vendor who can point to one and explain what went wrong is showing you a real failure mode; a vendor who claims no customer has ever scaled back is either very new or not being straight with you.
12What the contract should actually say
Three clauses carry most of the risk. The first is data: who owns the readings, in what format they can be exported, on what notice, and what happens to them at termination. If this is not written down, the default is whatever the vendor decides later.
The second is service levels expressed in outcomes rather than uptime. Platform availability is easy to promise and rarely the thing that fails; what matters is the time to replace a failed device at a remote site and whether the asset history survives the swap. Both should be stated with numbers.
The third is what happens on change. Devices get discontinued, firmware moves on, and integrations break when a third party updates an API. Ask who bears the cost of a forced hardware refresh, and over what notice period, because that question decides the real length of the commitment.
13Applying the method: ENTEK.AI as one worked example
Run the same questions at ENTEK.AI and the answers should be equally specific. The platform holds fuel tanks, vehicles and containers as assets in one system, which is what allows a fuel event to be read against what else was on site, the cross-asset context that justifies a unified platform at all. Generator monitoring is limited today: a genset shows as online or offline and appears on the site map, without run-state analysis or remote control.
Where it is not the strongest option, that should be said plainly. A buyer whose entire requirement is deep generator controller diagnostics, or regulatory fleet reporting alone, is better served by a specialist in that one domain, and this article would be dishonest to imply otherwise.
The point of the method is that it does not depend on which vendor you ask. Any vendor who answers the outage question, the export question and the second-year question concretely is worth shortlisting; any vendor who deflects all three is worth eliminating, including us.
| Question | Weak answer | Strong answer |
|---|---|---|
| Data during an outage | “It reconnects automatically” | Names where readings buffer, how order is preserved, how they resync |
| Data export | “You get reports” | Full raw history, documented format, on demand, no fee |
| Device failure | Quotes the datasheet MTBF | Gives a 12-month field failure rate and the replacement process |
| PDPL | Shows a certificate | States where personal data sits and how cross-border transfer works |
| Weakest area | “We cover everything” | Names the vertical they would concede, and to whom |
Figures and sources
- Saudi Personal Data Protection Law entered into force: September 2023 (Source: Clyde & Co, Saudi PDPL becomes enforceable, as of 2026-08-30)
- Saudi PDPL full enforcement commenced after the grace period: September 2024 (Source: Clyde & Co, Saudi PDPL becomes enforceable, as of 2026-08-30)
- Authority that oversees and enforces the Saudi PDPL: SDAIA (Saudi Data and Artificial Intelligence Authority) (Source: IAPP, Saudi PDPL amendments, enforcement and developments, as of 2026-08-30)
- Eurosens Dominator RS published maximum measurement error: ±1% (Source: Wialon sensor catalogue, Eurosens Dominator RS, as of 2026-08-30)
- Eurosens Dominator RS digital interfaces: RS-232, RS-485, K-Line (Source: Wialon sensor catalogue, Eurosens Dominator RS, as of 2026-08-30)
- IP67, first digit: protection against solid foreign objects: dust-tight (no ingress of dust) (Source: IEC 60529, Degrees of protection provided by enclosures (IP Code), as of 2026-08-30)
- IP67, second digit: protection against temporary immersion: immersion up to 1 m for 30 minutes (Source: IEC 60529, Degrees of protection provided by enclosures (IP Code), as of 2026-08-30)
- SOJI LIGO Pro published water-ingress standard: IP69K (Source: SOJI Electronics, LIGO Pro fuel level sensor, as of 2026-08-30)
- SOJI LIGO Pro published operating temperature range: −40 to +85 °C (Source: SOJI Electronics, LIGO Pro fuel level sensor, as of 2026-08-30)
- RS-485 signalling type, which is what allows multi-drop sensor wiring: differential, multi-drop balanced bus (TIA/EIA-485) (Source: TIA-485-A, Electrical Characteristics of Generators and Receivers for Balanced Digital Multipoint Systems, as of 2026-08-30)
- Standard governing the K-Line service interface on the Dominator: ISO 9141 (Source: Wialon sensor catalogue, Eurosens Dominator RS, as of 2026-08-30)
Questions
Should I always prefer one platform over several specialist tools?
No. A unified platform pays off only when you genuinely need one asset type read against another. If a single vertical dominates your requirement, deep generator diagnostics, or regulatory fleet reporting alone, a specialist will go further in that domain than a general platform reasonably can.
What is the single most useful question to ask?
What happens to the data when a device loses connectivity for an hour or a day. A strong answer describes local buffering, ordering and resynchronisation. A weak one describes the radio reconnecting, which says nothing about whether the readings survived.
How much weight should I give a vendor’s installed base figure?
Some, with two caveats. Treat it as the vendor’s own published claim with a date, not an audited figure, and ask what proportion of that base is in your specific application. A large base in a different use case tells you little about your own deployment.
What should the pilot prove?
The things that are hard to reverse later, not that devices report. Include a site with poor connectivity to verify buffering, a deliberate device failure to observe the replacement process, and an actual data export in the documented format. Write the success criteria down before starting.