How to Choose Structural Monitoring Software: 30 Questions

Four classes of structural monitoring software, 30 vendor questions in 8 groups (each with a "good answer looks like this" note), scoring weights, red flags and an RFP template to copy into the specification.

Inclify Team Aug 21, 2026 updated Aug 30, 2026 25 min read
Direct answer

Structural monitoring software is not chosen by the feature list in a brochure, but by answers to data questions: where it comes from, what the software does with it, when and who it alerts, who can see it, and what remains after the contract ends. The checklist below of 30 questions in 8 groups structures the conversation with any supplier, from a data logger manufacturer to an online platform, and can be pasted directly into the scope of works.

In short

  • There are four classes of solutions on the market: data logger plus Excel, software from the data logger or sensor manufacturer, general platforms and system suppliers, and an independent online platform. Each has a different cost model and a different pain point.
  • The most expensive selection mistakes are not about the license price. They are about dependence on one hardware manufacturer, alarms without a procedure, and no data export when the contract ends.
  • Each of the 30 questions includes a sentence saying "a good answer looks like this" so you compare offers, not slides.
  • You also get a proposed scoring weight system (to adapt), a list of red flags and a 16-point RFP template.
  • At the end, we answer the same 30 questions for Inclify, including where the answer is "we do not have it".

Why software decides more than sensors

A vibrating wire sensor can operate for 20 years or more. A data logger can run for many years. But software decides whether, in year 4 of operation, anyone will see that the tilt of a pier no longer returns to zero overnight, and whether, in year 6, the data from year 1 still exist in a format that can be opened. Hardware measures. Software answers the question "is something happening?" and keeps the evidence that the question was asked in time.

That is why this post treats software selection as a long-term data contract, not a license purchase. For broader context, what to measure, with what and why, see the complete guide to structural monitoring. Here we deal only with the layer between the sensor and the person.

A structural monitoring platform is software that receives readings from sensors and data loggers, stores them with history, converts them into engineering quantities, compares them with thresholds, notifies people and makes the data available for analysis, reports and export.

Vendor lock-in in monitoring is a situation in which changing the software requires replacing sensors or data loggers, or the other way around, because the protocol, data format or license is closed to one manufacturer.

If you are afraid you will buy a pig in a poke, that fear has four specific symptoms that can be checked before signing: the supplier cannot show a documented way to import data from a third-party logger; data export is "on request, through support"; calibration coefficients and channel configuration live only in its tool; and the question "what happens after the contract ends?" is met with silence. The rest of this post is a way to check these four things in writing before someone else checks them for you years later.

Four solution classes: what you pay for, what you get, where it hurts

The classification below compares approaches, not products. Each class has use cases where it is the best choice. Product names are given only for orientation, and hard features are based on public manufacturer documentation (footnotes under the table, links in the "Sources and further reading" section).

Class What you pay for What you get Where it hurts For whom
1. Data logger + Excel hardware (data logger, modem, power supply) and people's time for reading and processing raw files, full control over calculations, no subscription fee manual or semi-automatic reading, no real-time alarm, knowledge in one spreadsheet and one person, difficult proof in a dispute short-term measurements, a single asset, research work
2. Manufacturer software for data loggers / sensors (e.g. Geokon Agent [1], Campbell Scientific LoggerNet [2]) mainly hardware; software downloaded from the manufacturer website or licensed per workstation logger configuration, data collection, conversion to engineering units, basic charts and alerts designed for the manufacturer's own hardware; installation on a Windows computer; mixing brands and online teamwork require another layer homogeneous logger networks, teams with their own measurement department
3. General platforms and system suppliers (e.g. Vista Data Vision [3], Proqio [4], Worldsensing CMT [5], Sixense Beyond Monitoring / Geoscope [6]) license (tokens, subscription) or a package with a measurement system and service broad support for data sources, mature products with deployments in many markets, often a choice between cloud and local installation license model, hosting and deployment scope vary in each offer; some platforms are most tightly integrated with their own group hardware; Polish interface and support must be checked large projects, international companies, organizations with a corporate standard
4. Independent online platform not tied to the sensor manufacturer (Inclify) platform subscription; optional turnkey system with installation data from any logger via HTTP/JSON, alarms with a procedure, vibration analysis, chain inclinometers, engineering reports, Polish-language support online service (customer-side installation by agreement, not standard); no file import; no trend threshold; newer brand than global players asset owners and contractors in Poland with mixed hardware, tenders requiring Polish language and an alarm procedure

Footnotes to the table (public sources, accessed 22.08.2026; links in the "Sources and further reading" section):

  • [1] Geokon - Agent Software product page (8800-GNA) and Agent Software manual.
  • [2] Campbell Scientific - LoggerNet product page and Konect Global Data Services page.
  • [3] Vista Data Vision (Bentley) - VDV help: License Overview, Server Side, Data Source, API; VDV and iTwin IoT product pages on bentley.com.
  • [4] Proqio - "About us" page; Encardio - monitoring offer description.
  • [5] Worldsensing - CMT Cloud and CMT Edge product pages.
  • [6] Sixense - "Monitoring software platform" page (Beyond Monitoring, Geoscope).

Class 1: data logger and spreadsheet

This is not a bad class. It is the class that stops being enough the moment someone needs to receive an SMS at night. The entry cost is the lowest, while the operating cost sits in labor hours and in the risk of a "blind period" between readings. If you want to calculate it, see what makes up monitoring cost and how to calculate TCO.

Class 2: hardware manufacturer software

Geokon describes Agent as software for hardware configuration, sensor monitoring, data collection and corrections; it automatically converts raw readings into engineering units, displays them as text or charts, exports them to several formats, and signals limit exceedance with visual and audible alerts (Geokon documentation: Agent Software). The program is available for download from the manufacturer website and runs on Windows with GeoNet networks and LC2 loggers. Campbell Scientific describes LoggerNet as logger support software - programming, communication and data retrieval between loggers and a Windows 10/11 computer; Konect Global Data Services is this manufacturer's cloud application for collecting and displaying data from IP-connected loggers, marked on the manufacturer website as "limited availability" (Campbell Scientific documentation: LoggerNet, KonectGDS).

These are tools close to the hardware and very good at their job. The question to ask is: what do we do when another brand's data logger appears at the asset, or an in-place chain inclinometer from another supplier, or when the duty engineer must see all assets in a browser. If the answer is "we add a platform", then you are choosing that platform, and that is what you should ask about.

Class 3: general platforms and system suppliers

This is where the greatest variety lies. Vista Data Vision (Bentley) uses token licensing: project elements are assigned token values, and a project can have a token limit (VDV help: License Overview); public prices are not available. It runs as a local installation on Windows Server or as a hosted version (VDV help: Server Side). Data enters through integrations with manufacturers' APIs, file import from FTP/SFTP or a network drive, and direct connection to Campbell loggers; the public VDV API is for reading only, and we did not find a public endpoint for writing measurements in the documentation (VDV help: Data Source, API). The vistadatavision.com domain now redirects to the iTwin IoT page, which Bentley presents as a more advanced platform; we did not find a public end-of-support date for VDV, so ask about the development and migration plan before deciding. Details in the fair comparison of Vista Data Vision and Inclify.

Proqio presents itself as a data platform for infrastructure, a company in the Encardio group with headquarters in Spain, available in the cloud or on-premises (Proqio "About us" page; Encardio). Worldsensing CMT comes in Edge version (data remains on the gateway, access per gateway) and Cloud version (all networks, devices and data in one platform), with export via FTP/FTPS, Modbus TCP, API and MQTT (Worldsensing documentation: CMT Cloud, CMT Edge). Sixense Beyond Monitoring is this group's proprietary software for managing, visualizing and reporting monitoring data, successor to Geoscope developed since 1997, offered as a cloud service with an on-premises version for sensitive assets (Sixense page: Monitoring software platform). Common denominator: maturity and scale. Common question: how neutral is the platform toward hardware outside its own group, and what does the cost model look like as the number of channels grows.

Class 4: independent online platform

We include Inclify in this class deliberately and with the caveats described in the table. The point of this class is simple: the software is purchased separately from the sensors, so it can be changed without replacing hardware, and vice versa. What that means in practice for connecting existing devices is described in the post how to connect existing data loggers to an online platform. The conclusion for you from this classification is one: before comparing prices, establish which class each offer belongs to, because then you are comparing the cost of the same thing.

30 questions for the supplier: data, sensors, alarms, dynamics

How to use: ask each question in writing, request the answer in writing, and ask the supplier to show what it claims on a live panel. The scoring later in this article assumes a 0-2 scale per question.

Group 1. Data acquisition and ingest

1. Through which paths does data enter the platform and is this interface documented? Good answer: an open, described interface (for example HTTP/JSON) with a sample data contract that can feed a data logger or hub from any manufacturer.

2. What happens when a device stops transmitting? Good answer: missing data is a separate state (NO_DATA) with a notification, not a chart that simply ends.

3. How often do readings reach the panel and what is the delay between measurement and view? Good answer: the interval given numerically (for example every 15 minutes by default, or more often for static measurements), dynamic events handled separately, delay measured in minutes, and data completeness calculated from actual readings.

4. Do you store raw device data or only converted values? Good answer: both layers - raw values and frames with timestamp and device ID are available for review, and the conversions can be reproduced.

Group 2. Sensors and data loggers

5. Which sensor types do you support, and is the list limited to one manufacturer? Good answer: a list of types (vibrating wire, MEMS, inclinometers including chain inclinometers, piezometers, strain gauges, temperature...) independent of brand; a new type is a channel configuration, not a software project.

6. How are calibration coefficients entered and who may change them? Good answer: explicit formulas per channel, change history with before and after values, permission restricted by role.

7. Does the platform know how far the sensor has drifted from the reference reading, and show it without manual analysis? Good answer: "calibration debt" is a report from the data (deviation from the reference, drift), not an entry in someone's calendar.

8. Is temperature compensation for vibrating wire sensors calculated in the platform and visible? Good answer: the formula and coefficients are explicit, and the result before and after compensation can be compared on one chart.

Group 3. Alarms and procedure

9. How many threshold levels do you support and at what level (channel, group, project)? Good answer: at least two levels (warning and alarm) set per channel, with hysteresis, plus a separate missing data state.

10. Who receives the notification and how? Good answer: SMS and email to a list of authorized people, with the ability to change the list without the supplier's involvement.

11. Does the alarm have a procedure: acknowledgment, information on who took over, silencing with a deadline? Good answer: yes, with a record of who and when - without that, an alarm is just a color on a chart.

12. How are thresholds tuned after the baseline period? Good answer: the platform shows a threshold proposal based on the data and keeps change history; a person makes the decision. The method is described in the post how to set warning and alarm thresholds.

Group 4. Dynamics and inclinometers

13. Do you support vibration events and what analysis do I get in the panel? Good answer: time history, FFT spectrum, third-octave bands and filters in the same panel as static measurements, without a separate program.

14. How does the dynamic alarm work? Good answer: an event threshold (for example an envelope in bands), with the event record saved so it can later be opened and shown.

15. Is the displacement profile of a chain inclinometer calculated automatically? Good answer: profile calculated from the anchor, separate A and B axes, with the maximum displacement visible on the profile, without a spreadsheet next to it.

16. How do you show tilt against temperature? Good answer: a multi-axis chart where the daily "breathing" of the structure can be distinguished from the permanent trend at a glance.

These 16 questions determine whether the system will see what it is supposed to see at all. The next 14 determine whether you will see it, prove it, and take it with you.

30 questions for the supplier: reports, audit, hosting, cost

Group 5. Reports and analytics

17. Which engineering reports does the platform generate from the data without manual processing? Good answer: at least data completeness (data SLA), calibration state, temperature compensation and risk assessment in a defined horizon (for example 7/30 days).

18. What exactly does the "AI" in your platform do, and what does it not do? Good answer: statistical anomaly detection and commentary on the data; the supplier states clearly that AI does not replace design thresholds or the engineer, and can say exactly what goes into the model.

19. Can I compare periods, combine channels and export the result? Good answer: trends, time comparisons and data export available from the panel for an authorized user, in an open format.

Group 6. Roles, audit, evidentiary value

20. Which roles are available and can I give limited access to external parties (investor, supervision, expert)? Good answer: a read-only account for external parties, with a clearly described scope of what they can see.

21. Does every change to a threshold, calibration or channel configuration leave a trace? Good answer: yes - who changed what, when, with before and after values; ideally also the ability to restore the previous value.

22. Will the communication log show what came in, when and from which device? Good answer: yes, with raw frames and filtering by device and time. Why this matters in a dispute - see monitoring data as evidence.

23. How do you handle timestamps and time zones? Good answer: data time is unambiguous (for example UTC), while the view is local time; daylight saving changes do not create gaps or duplicates.

Group 7. Hosting, GDPR, SLA, export and exit from the contract

24. Where is the data hosted, who administers the infrastructure and do you sign a data processing agreement? Good answer: location and entity specified in the contract, data in the European Union, a personal data processing agreement compliant with Article 28 GDPR (personal data in the platform is mainly user accounts and phone numbers for SMS).

25. What availability and support SLA do you guarantee? Good answer: numbers in the contract - availability, response time, service windows - not "we do what we can".

26. How do I export data during the contract, and how do I receive everything after it ends? Good answer: export from the panel as needed; a contractual clause on delivering the full history in an open format and a transition period after termination.

27. What is the retention period for measurement data and raw frames? Good answer: measurements are not automatically deleted, at least for the duration of the contract plus the evidentiary period agreed with your legal team; raw frame retention is given numerically and written into the contract.

Group 8. Total cost and cooperation model

28. What exactly is included in the platform price and what is charged separately? Good answer: a clear list - number of channels or projects, users, SMS, support, configuration, deployment, possible export fees.

29. Which cooperation models do you offer: turnkey, only the platform for my sensors, pilot? Good answer: all three, with a clear division of responsibility for sensors, connectivity and software.

30. How long does implementation take and what do you need from me? Good answer: a schedule in days or weeks with a list of dependencies (site access, power, connectivity, calibration data).

After this list, you have something no presentation can give you: the same set of questions asked of every supplier, with written answers that can be placed side by side.

Offer evaluation criteria: proposed weights

This is a proposal, not a standard. The weights depend on the asset: on an excavation in a city center, the "dynamics and inclinometers" group matters more, on a warehouse hall less. A public buyer will translate this into its own non-price criteria in line with public procurement rules and internal regulations - the weights below are a starting point for such a discussion, not a ready-made template.

Question group Questions Proposed weight Notes
1. Ingest and data acquisition 1-4 15 % determines independence from hardware
2. Sensors and data loggers 5-8 10 % more if you already have sensors from several brands
3. Alarms and procedure 9-12 15 % without a procedure, the alarm does not work
4. Dynamics and inclinometers 13-16 10 % depending on the asset: 0-20 %
5. Reports and analytics 17-19 10 % saves engineer time
6. Roles, audit, evidentiary value 20-23 10 % more if there is dispute risk
7. Hosting, GDPR, SLA, exit 24-27 15 % what hurts only after years
8. Total cost and model 28-30 15 % total cost, not license price

Scoring: 0 - absent or "we do not know"; 1 - partial or "planned"; 2 - present, shown on a live panel or in documentation. Group score = sum of points / maximum × weight. Illustratively: group 3 with a score of 6 out of 8 points gives 6/8 × 15 % = 11.25 %. The sum of the groups is the offer score on a 0-100 % scale. We count "planned" functions as 1, never as 2 - that is the one rule we do not recommend softening, because "planned" will not send an SMS at night.

Red flags

  • "We support all sensors" - without a list of types and without showing a channel from a third-party logger.
  • No written answer to question 26 (export after the contract ends).
  • An alarm is just a color on a chart: there is no acknowledgment, no visible takeover, no way to silence it with a deadline.
  • Missing data is not a state - the chart simply ends.
  • A demo on slides or in a recording instead of on a live panel with data.
  • Raw data "is with us", but it is not in the panel.
  • "AI will detect the threat" without a method description and without a sentence about the engineer's role.
  • License price without variants for the number of channels, users and SMS messages.
  • "Cloud" hosting without stating where and who administers it.
  • Support only in a language your duty engineer does not speak.
  • A contract in which you are not the owner of the measurement data.

Each of these flags can be explained on its own; two or three at once are a sign that the offer should not be explained, but set aside.

How Inclify answers these 30 questions

Briefly and without embellishment, group by group. Where we do not have it, we say that we do not have it.

Ingest (1-4). We accept data from existing loggers and hubs via HTTP/JSON (contract compliant with SHMmonitor 1.1): the device sends frames with a UTC timestamp, channel ID and raw values, and the platform converts them using project equations. The same channel can also send the history from the existing system, with original timestamps. Loggers in our systems normally send readings every 15 minutes by default, or more often; the platform accepts any interval and calculates completeness against the actual data cadence. Missing data is a NO_DATA state with a notification (configurable time window). Raw values from the logger are stored alongside converted values, and request/response frames are stored in the communication log for the configured period (default 7 days). What we do not have: CSV/XLSX file import, a manual series entry form, or other protocols as a platform function.

Sensors (5-8). The team selects and installs more than 40 sensor types (vibrating wire, inclinometers including chain inclinometers, strain gauges, MEMS, piezometers, temperature, inductive, piezoelectric, resistive); the platform itself accepts data from any channel, and device type is a description, not a limitation. Calibration coefficients and temperature compensation are defined as project equations (explicit formulas), and every change is recorded in the audit log with before and after values. The calibration debt report shows deviation from the reference reading and drift over 7 and 30 days; the temperature compensation report compares the correlation with temperature before and after compensation. What we do not have: dedicated "gain coefficient / temperature coefficient" fields per sensor or a calibration schedule calendar - we calculate calibration debt from data.

Alarms (9-12). WARNING and ALARM thresholds per channel, with hysteresis; OK / WARNING / ALARM / NO_DATA states; SMS, email and in-app notifications to users according to their preferences; acknowledgment with a record of who took over and when; silencing always with a deadline (indefinite silencing is not possible); threshold proposals from measurement history to be applied with one action - the engineer makes the decision. What we do not have: trend or rate-of-change thresholds, a minimum duration for an exceedance, escalation to additional people after no acknowledgment, or push notifications in the mobile app.

Dynamics and inclinometers (13-16). Vibration events with time history, FFT spectrum and 21 third-octave bands in the 1-100 Hz range; profile with 4th-order Butterworth filters (requires sampling above 224 Hz); the dynamic alarm compares RMS/MAX in each third-octave band with a reference envelope (warning and alarm level with hysteresis), and the event history is saved and can be opened in the panel. Chain inclinometers: profile calculated from the anchor in A and B axes and resultant, based on configured segment lengths; after the first valid frame the platform automatically creates a dashboard with a vertical profile and trend; the maximum depth can be read from the profile. The multi-axis chart overlays tilt with temperature. What we do not have: support for manual inclinometer probe readings.

Reports and analytics (17-19). Five data-derived reports: calibration debt, temperature compensation, 7/30-day risk assessment, alarm tuning, data SLA (completeness, gaps, freshness). AI analysis: the database calculates statistics and anomalies (z-score against the baseline window), and the language model receives only the calculated results and writes a Polish-language commentary, findings and recommendations - an engineering assistant, not an oracle; the model provider is configured per deployment, and without an API key the report is fully deterministic. Dashboards with 26 widget types, trends, time comparisons; CSV export of data tables, chart image, XLSX for dynamic signals. What we do not have: a PDF report.

Roles and audit (20-23). Three permission levels: super administrator, customer administrator and read-only user; each customer's data is isolated. The audit log records changes to project, device, user and dashboard configuration with before and after values, and alarm events (creation, change, acknowledgment, silencing) have their own history. The communication log with raw frames (what, when, from which device) can be viewed and downloaded by the administrator. Time in the database is always UTC, while the view uses the user or project time zone. What we do not have: per-project roles (a read-only user sees the projects of their customer) or automatic restoration of configuration to the state before the change - the previous value is entered manually based on the log.

Hosting, GDPR, SLA, exit (24-27). The platform is an online service; technically it runs as a set of containers, so we discuss installation in the customer's infrastructure individually - this is not a standard offer. The hosting location, the administering entity, SLA parameters and the data processing agreement (Article 28 GDPR) are provided in writing in the offer and written into the contract; we do not publish these values on the blog because they depend on the deployment. Measurements are stored in a time-series database without automatic deletion (older data are compressed), and the communication log is kept for the configured period. CSV export is available from the panel for the full contract period; the mode for delivering the full history after the end of the contract must be written into the contract.

Cost and model (28-30). Pricing is provided on request, with a clear scope in the offer. Three models: turnkey monitoring (sensor selection, installation, platform), just the platform for existing sensors, pilot on one asset. Connection of existing devices - a few days; full deployment with installation - from several to several dozen weeks. What we do not have: BIM integration or a mobile app.

More about the platform itself: /platform and /platform/monitoring. If you still have a question after this list that we did not answer here, that is exactly the kind of question you should send us in writing.

RFP template (to copy into the scope of works)

The points below are phrased so that they can be pasted into the scope of works or request for quotation. Fill in the fields marked "[enter ...]" with your own values.

  1. The bidder shall present a documented interface for accepting data from loggers and hubs (for example HTTP/JSON) together with a sample data contract.
  2. The platform supports the following sensor types: [enter list]; the bidder shall confirm support for each type and indicate whether additional work is required.
  3. The static reading interval shall be no longer than [enter, for example 15] minutes; dynamic events shall be recorded and analyzed separately (time history, spectrum, third-octave bands).
  4. The platform shall signal missing data from a device as a separate state with a notification.
  5. Thresholds of at least two levels (warning, alarm) shall be defined per channel; SMS and email notifications shall be sent to persons indicated by the client.
  6. Alarm procedure: acknowledgment of the alarm with identification of the person, silencing with a deadline, event history.
  7. For chain inclinometers, the platform shall determine the displacement profile from the anchor with axis separation.
  8. Data reports: data completeness, calibration state, temperature compensation, risk assessment over a [enter, for example 7/30] day horizon.
  9. User roles and permissions with the ability to grant read-only access to entities indicated by the client.
  10. Storage of raw device values and the communication log with device ID and time for a period of [enter].
  11. Data hosted in the European Union; the bidder shall indicate the entity administering the infrastructure and shall conclude a personal data processing agreement compliant with Article 28 GDPR.
  12. SLA: availability [enter], support response time [enter], support in Polish.
  13. Data export from the panel for the full contract period; after its end, delivery of the full history in an open format within [enter] days and data retention for [enter period].
  14. The client is the owner of the measurement data.
  15. The offer shall include a clear price scope (channels, users, SMS, support, implementation) and an implementation schedule with a list of dependencies on the client's side.
  16. The bidder shall conduct a presentation in a live environment with data and enable a pilot on one asset before full deployment.

If only one thing from this post makes it into the scope of works, let it be points 13 and 14: data ownership and the method of delivery. They decide whether, in five years, you are still choosing, or only renewing.

FAQ

How does manufacturer software differ from a monitoring platform?

Manufacturer software (for example Geokon Agent, Campbell LoggerNet) is mainly used for logger configuration, data collection and conversion, usually on a computer and within that manufacturer's hardware ecosystem. A monitoring platform works online, connects hardware from different brands, adds an alarm procedure, roles, reports and evidentiary value. Both layers can coexist: the logger collects, the platform analyzes and alarms.

How do I spot vendor lock-in in a structural monitoring system?

By four signals: no documented way to bring in data from a third-party logger, export only "through support", configuration and calibration coefficients available only in the supplier's tool, and no contractual clause on delivering the data after the cooperation ends. If changing software means replacing sensors, that is lock-in.

Do I have to replace sensors to change software?

No, if the existing loggers or hubs can send data in a documented format or the new platform has an interface that accepts it, for example HTTP/JSON. Vibrating wire sensors and inclinometers work for years - replacing the software layer without replacing hardware is the cheapest path to alarms with a procedure and online data. Connecting existing devices usually takes a few days.

How should software requirements be written into the scope of works?

Describe behaviors, not feature names: "the platform shall signal missing data as a separate state with a notification" instead of "the system shall have a NO_DATA module". Add requirements for the data interface, alarm procedure, roles, hosting, SLA, export and data ownership. The 16-point template above serves that purpose. Request a presentation on a live panel and a pilot.

Is cloud hosting allowed for structural monitoring data?

In most applications, yes, provided the contract specifies the data location (preferably in the European Union), the entity administering the infrastructure, SLA parameters, retention and the method of data delivery. Personal data in such a platform are mainly user accounts and phone numbers for notifications, and they require a processing agreement compliant with Article 28 GDPR. If internal regulations require installation at the client site, ask about this explicitly at the inquiry stage.

How do I test the platform before signing the contract?

Pilot on one asset, preferably in parallel with the current system: connect existing sensors, set thresholds, trigger a test alarm and see who received the SMS and when, what the acknowledgment looks like, whether missing data was reported and whether the data can be exported. A few weeks of pilot tells you more than any presentation; how to choose the asset is described in the post how to choose an asset for a monitoring pilot.

This post is for informational purposes and does not constitute legal advice; consult your own legal department on contract clauses and GDPR requirements.

Sources and further reading

What next

You already have the list of 30 questions. The simplest supplier test is to send it and ask for a written response - you sign nothing, install nothing, and after a week you have offers that can be placed side by side. Do the same with us: send us this list - we will reply in writing, point by point, including where the answer is "we do not have it". We respond within 24 hours. The best time is now - before the next tender or before renewing the current contract, when you are still choosing, not only accepting. If you prefer to start by seeing the panel - Inclify platform description.

Keep reading

Related articles

All articles

Monitoring a structure? Book a demo

We will show the platform using an asset similar to yours and discuss where the measurement programme should start. No obligation.

Book a demo Explore the platform