SmartGovIOT for municipalities

Municipal asset, energy and IoT management.

SmartGovIOT connects information about municipal assets, technology, consumption and operational events. It provides management with a basis for decisions and helps staff track what needs to be addressed, who is responsible and how the work is progressing.

Describe your requirements View solutions

Illustrative visualisation of a municipal office and public space with subtle symbols of measurement and technology management.

Start with one specific area and gradually expand the solution according to the municipality's needs, priorities and budget.

SmartGovIOT is in development. For each solution, we distinguish between available features, pilot testing and further development.

See the status. Assign responsibility. Measure the outcome.

What SmartGovIOT brings to a municipality

Managing a municipality requires more than knowing which buildings and devices you own. It is important to understand their current condition, know which problems remain unresolved and have the information needed for the next steps. Knowing who is responsible for a particular matter and what has already been done is equally important.

We are developing SmartGovIOT so that information about assets, measurements, documentation and operational tasks does not remain isolated. Connecting it is intended to help management make decisions and staff carry out their daily work—from identifying a problem to recording the result.

Visibility

Information about an asset and the context you need to make a decision.

Documentation, measurements, faults and service records are most useful when it is clear which site or device they belong to. SmartGovIOT brings them together in a shared operational view. For a building, you can therefore find not only basic data, but also follow its technical equipment, open tasks, available measurements and activity history.

Management needs an overall view of what requires attention. An asset manager needs supporting information about sites, and a technician needs the information required for a particular intervention. The data displayed therefore reflects the user's work responsibilities and permissions.

Illustrative example: When preparing a repair to a cultural centre, the asset manager opens the building record. They find the available documentation, previous fault reports and completed interventions. This provides a basis for assessing whether the issue is new or a recurring deficiency.

Responsibility

It is clear what needs to be done, who is handling it and what should happen next.

A reported fault, service request or approaching inspection deadline should not remain only in a phone call or a personal note. In shared records, each task can have a description, priority, deadline, responsible person and resolution status. Related documents and records remain assigned to the activity they concern.

Staff have an overview of their assigned tasks, and management can follow progress without repeatedly asking several people for status updates. When work is handed over to another colleague, the findings, completed actions and remaining work are retained.

Illustrative example: A staff member reports a heating fault in a municipal building. The request is assigned to a responsible person, who adds their findings and the next steps. After the repair, they record the work performed and the result. The entire process can then be reviewed, rather than just the fact that the fault was closed.

Measurable outcomes

Information for comparison, planning and verification of measures taken.

The current status alone does not show how operations are changing over time. A history of measurements, faults, inspections and completed activities makes it possible to compare periods, recognise recurring problems and prepare further steps based on available data.

For energy, this may involve consumption trends and checking unusual deviations. For maintenance, it may involve recurring faults, meeting deadlines or progress in resolving requests. This information helps identify which sites need attention and where a repair, renewal or operational change deserves closer assessment.

Illustrative example: After a heating repair, subsequent consumption trends are compared with the previous period. The evaluation takes account of data availability and quality, as well as changes in weather or building use. The municipality gains information for assessing the outcome instead of relying only on an assumed saving.

Three benefits, one shared approach

Visibility helps identify what needs attention. Assigned responsibility gives the issue a specific owner and a next step. History and available data make it possible to evaluate the result and apply the experience to future work.

The specific capabilities depend on the features involved, available data and the agreed scope of the solution. We state their current status for each area.

Solutions for day-to-day municipal operations

From a specific problem to a shared overview

Every municipality has different priorities. In some, the first step is organising building documentation; in others, monitoring water consumption, recording lighting faults or obtaining data from remote locations. We are therefore developing SmartGovIOT as a modular platform whose scope follows a specific need, rather than a requirement to introduce every area at once.

Individual solutions connect information with the site, device or location it concerns. Management gains a basis for decisions, and staff gain the context needed to handle daily tasks. You can start with selected sites or one operational area and add further capabilities according to experience, priorities and budget.

Pilot solution

Asset and operations management

A shared overview of municipal buildings, spaces, equipment, documentation, faults, maintenance and statutory inspections.

Explore the solution

Available according to scope

Energy and metering

Monitoring electricity, gas, water and heat consumption, cost trends, deviations and information for energy-related decisions.

Explore the solution

Available according to scope

IoT and environmental monitoring

Remote measurement of levels, temperature, humidity, rainfall, environmental quality and technical states using supported sensors and LoRaWAN.

Explore the solution

Pilot solution

Public lighting

Records of lighting points, distribution boards, technical condition, faults, service interventions, consumption and planned renewal.

Explore the solution

In development

Security and events

A planned overview of technical alarms and operational events linked to a location, responsibility and the resolution process. No processing of camera footage.

Explore the solution

In development

Transport and technical infrastructure

Planned records of roads and related technical assets, their condition, faults, maintenance, documentation and geographical context.

Explore the solution

Individual areas do not need to remain separate

The same municipal building may have documentation, metering points, planned maintenance and an unresolved fault. SmartGovIOT aims to connect this information gradually so that important context from other areas is not lost when a task is being addressed.

You do not need to select every feature or prepare a detailed technical specification at the outset. It is enough to identify the problem, the sites concerned and the result you expect. We will use this to assess a suitable first step.

View all solutions

Availability labels apply to a specific scope, not automatically to every capability described. We provide details for each solution and clarify them before implementation is agreed.

Getting started with SmartGovIOT

Start with a specific need. We will design the scope of the solution around it.

You do not need a detailed technical specification or a decision on which features you will need at the outset. It is more important to identify what currently makes work difficult, which sites or areas the problem affects and what should change.

This may be a lack of visibility over documentation, recurring faults, tracking inspection deadlines, unclear consumption trends or the need to obtain data from a remote location. The first step need not cover the entire municipality. One site, a group of metering points or a particular workflow can be a meaningful starting point.

We therefore begin the working relationship with a request and its assessment. Only then do we propose a suitable scope, the information required and the next steps.

1. Describe your requirements

Tell us what you need to address and how you handle it today.

Use the form or email to briefly describe the problem you want to solve, the sites or operational areas it concerns and the outcome you expect. It also helps to know whether you already use records, meters, sensors or a technical system that the new solution should build on.

You do not need a complete asset list or all the technical documentation for the first contact. Simply describe the current situation in your own words. You can also add a priority, an approximate scope or a desired deadline if you have one.

Example of an initial request:

‘We manage a school, a cultural centre and a sports complex. Our documentation is kept in several places, and we track inspection deadlines in spreadsheets. We would like to start with shared records of equipment and deadlines at the school.’

This description helps determine what to focus on during the initial assessment. Do not send passwords, access credentials or sensitive technical information in your first message.

2. We analyse the request

We assess the need, the available information and the suitability of the solution.

We look at what the proposed solution should improve and what information is already available. We distinguish whether the first step is organising existing data, completing records, introducing measurement or connecting to a supported system.

The assessment also identifies missing information. For measurement, the meter type and data availability may need to be checked. For asset management, it may be a basic site list, documentation or the way tasks are assigned.

If anything in the initial request is unclear, we will ask for specific additional information. The aim is to establish whether SmartGovIOT fits your need and what must be checked before proposing next steps—not automatically recommend the broadest possible deployment.

3. We propose the next steps

We recommend an initial scope with practical value for the municipality.

Based on the request and available information, we prepare a proposal for the next steps. This may involve records for a selected site, monitoring a particular type of consumption, connecting a supported sensor or pilot testing a workflow.

The proposal distinguishes what available features can address, what requires pilot testing and what is not yet ready for routine use. We also identify the municipality's required involvement, additional information needed and questions that may affect the scope or price.

The proposal should also include a clear objective for the first step. For example, creating verified equipment records for one site, making the history of selected measurements available or recording a fault from reporting to closure. It will then be clear what should be evaluated after introduction.

4. A consultation follows where needed

We address questions that are best discussed together.

We propose a consultation when it will help clarify technical, operational or organisational requirements. It follows the initial assessment so that we already know which questions need to be resolved and who should be involved in the discussion.

For asset records, the site manager's perspective may be important. For energy, it may be that of the person working with meter readings and invoices. For tasks and maintenance, it may be the staff who assign or carry out requests.

Together, we clarify the way of working, the availability of information and responsibilities. Where conditions need to be checked on site, we agree on the scope of a site visit or technical verification. For a simpler request, additional information by email may be sufficient.

5. Pilot or implementation

We start with the agreed scope and verify its practical usability.

Before starting, we prepare a specific plan and quotation. We agree on which sites, data or workflows are included in the solution, what cooperation will be required and how the outcome will be verified. Implementation takes place only after the scope and conditions have been approved.

A pilot tests a specific question within a limited scope. It may check data availability and quality, the suitability of records or the practical process of resolving tasks. It is not an automatic deployment of every platform feature.

After the agreed testing, we evaluate what works, what needs adjustment and whether continuing makes sense. Further expansion depends on the municipality's experience, priorities and resources. Even a smaller scope can remain a standalone solution if it serves its purpose.

A clear starting point and approach to pricing

The initial assessment of the basic scope and suitability of the solution is free of charge. More detailed analysis, site visits, preparation of information, integrations or deployment itself are handled according to the scope subsequently agreed.

Pricing is prepared according to what the solution should include: the number and type of sites, metering points, devices, required integrations and related services. The municipality receives a proposal tied to its need, rather than a generic package with no explanation of its contents.

You do not need to know which features to choose. Simply tell us what you need to improve.

Describe your requirements

Alternative contact: email contact

Illustrative municipal office in a public space

Pilot project in Kalná nad Hronom

Growing from the real needs of municipal government

SmartGovIOT is being developed in Kalná nad Hronom in response to practical questions about asset management and day-to-day municipal operations. How can information about a building be linked to its technical equipment? Where can the related documentation be found? How can consumption be tracked, a fault recorded and the history of its resolution retained?

Kalná nad Hronom is a reference environment in which we are gradually processing and testing these connections. The project is in development. We develop individual areas according to the information available and opportunities for practical testing, not as a one-off deployment of every feature.

From existing information to usable records

It is important not merely to collect data, but to understand what it describes and how it is related.

Building lists, technical documentation, historical meter readings or equipment records can provide a useful foundation. On their own, however, they do not represent a complete and currently verified picture of operations.

When preparing a solution, we therefore distinguish the source of data, how up to date it is and its link to a particular site or device. A historical document may provide context but need not reflect today's condition. A working register can show which information is already available and what needs to be added or checked on site.

This is intended to gradually create records that can support maintenance, measurement, planning and the handover of responsibilities. The aim is not merely to transfer the original spreadsheets into a new application, but to preserve relationships and identify what is not yet known.

We test the way of working, not just the technology

A feature matters when it helps handle a specific work situation.

During pilot testing, we focus on data quality and availability, an understandable display and how individual activities follow on from one another. We examine how a site, measurement, event, documentation and responsibility can be connected without creating further separate records.

Practical questions also matter: Can a staff member find the correct site and the document they need? Is it clear where a measurement comes from and when it was obtained? Does a recorded fault have a next step? Can the work carried out be traced after an intervention?

These questions determine what a particular test should demonstrate. The experience gained informs changes to the system and helps refine the scope worth developing further.

Gradual connections rather than one-off digitisation

Asset management, energy, remote measurement and operational event records do not have to start at the same time. One area may have usable information, while another first requires equipment checks, additional documentation or an agreed way of working.

A gradual approach makes it possible to focus on a specific objective and evaluate the outcome before further expansion. For example, first assigning a metering point correctly to a building, then checking the available data, and only afterwards preparing comparisons or alerts.

For other municipalities, it is primarily this approach that should be transferable: start from your own needs, verify the information, agree on an achievable scope and gradually build on what has worked. Not every municipality needs the same equipment, integrations or workflows.

We state only what we can substantiate

For each area, we distinguish between recorded information, pilot testing and planned development.

We describe areas actually recorded or in use according to the substantiated scope. Pilot solutions are labelled as testing under limited conditions. We do not present planned capabilities as completed deployments.

The presence of technology in a municipality does not automatically mean it is connected to SmartGovIOT. Equally, working records do not mean that all data has been physically verified. We publish precise counts, outcomes and reference statements only after verification and approval for public use.

Describing Kalná nad Hronom as a reference environment does not, by itself, mean deployment of the entire platform, an official partnership or a formal commercial reference from the municipality. A separate page therefore explains the status of individual areas and the boundaries of what is being tested.

Trust and data protection

Only the data needed, kept under control

Managing municipal assets involves technical documentation, operational data, work tasks and information about the people responsible. Not all data serves the same purpose, and not every staff member needs the same access.

We design SmartGovIOT so that the information required, who will work with it and which activities the system should record are defined while preparing the solution. Data protection is therefore not separate from daily work. It is part of configuring user permissions, recording activities and connecting individual systems.

Controlled access

Every user should have access appropriate to their work.

Municipal management needs an overall view, an asset manager needs information about sites, and technical staff need information for their assigned tasks. The distinction is not only about what users can see. Which data they can edit, which activities they can perform and what they can approve also matters.

Permissions are therefore configured according to roles, assigned sites and the agreed way of working. Access to one operational area should not automatically mean access to every document or the ability to change settings across the entire system.

When responsibilities change or a staff member leaves, permissions need to be adjusted to reflect current responsibility. Preparing a deployment therefore also includes identifying the person who will approve the granting and changing of access.

Illustrative example: A technician needs documentation and intervention history for the equipment they are to inspect. Completing that task does not require changing colleagues' permissions or viewing unrelated documents for other sites.

Traceability

For an important change, it should be clear what happened and what to build on.

Operational records should also help when you return to an event after several weeks or another staff member takes it over. For significant changes and completed activities, it is therefore important to retain the time, related asset, result and, depending on the record, the person or system from which the information originated.

The history can explain when a fault was reported, to whom it was assigned, what findings were added and why it was closed. For consumption data, it also helps distinguish an automatic measurement, an imported meter reading and a manually added record.

Traceability is not about recording every staff activity for its own sake. The scope of the history should reflect operational needs and help with work handovers, investigating discrepancies and checking results.

Illustrative example: When a pump has a recurring fault, the asset manager needs to establish what changed during the last repair and what recommendation the technician recorded. They can then build on specific information, not merely the fact that the previous task was marked as complete.

Data minimisation

Collect what serves a clear purpose, not everything that is technically available.

Clearer operations do not automatically result from moving as much information as possible into a system. For every set of records or integration, it is necessary to identify which data is needed for the task and which would only increase the volume or sensitivity of the information processed.

Maintenance may require knowing the responsible person and their work contact details. There is no reason, however, to add personal information unrelated to the intervention. Similarly, a photograph of equipment should document its condition, not unnecessarily capture people, nearby documents or access credentials.

We apply the same principle when connecting technologies. If availability or fault status is sufficient for monitoring operations, the integration design should focus on that scope. Transferring additional content must have a separately defined purpose and conditions.

Illustrative example: Investigating a camera device outage may require information about its technical status and last communication. SmartGovIOT does not need to transmit or display camera footage for this purpose.

Security without unnecessary complexity

Clear rules that support work and maintain control.

Staff should understand the data they work with, what they can do and when a decision from another authorised person is required. Security rules should therefore be part of an understandable workflow, not an unclear obstacle to work around.

SmartGovIOT is not intended to replace every specialist municipal system or take over all of their functions. Connections are designed only to the extent needed, while preserving the original system's restrictions. Displaying a technical status, for example, does not automatically grant permission to control equipment or change its configuration.

Understandability also includes information about data quality. If a source stops communicating, the last known value should not be presented as a new measurement. Users need to recognise whether they are working with current data, a historical record or information that needs to be checked.

With planned AI assistance too, important decisions, approvals and active changes remain under the control of an authorised person. A proposed next step is not the same as permission to carry out an intervention.

Conditions tailored to the particular deployment

Before introducing a solution, we clarify the scope of data, user roles, systems involved and responsibilities. Conditions for operation, support, retention and handover of data are defined according to the particular service and agreed scope.

The municipality should therefore know which information enters the solution, what it is used for and who can work with it. A separate page explains these principles in more detail, including data sources, access and the boundaries of individual integrations.

Trust rests on understandable rules, a proportionate scope and the ability to verify important activities.

Trust and data protection

Who we are and how we work

Who is behind SmartGovIOT

KNH INVEST s. r. o. is responsible for the project and this website. Find verifiable company details, our approach and the limits of the reference environment.

About the project and operator

Evidence before promises

We distinguish documented information, pilot verification and planned development. A reference to a standard is not proof of a completed deployment.

Methodology and primary sources

Frequently asked questions

How much does SmartGovIOT cost?

Pricing depends on the number and nature of sites, metering points, devices, integrations and related services. The initial assessment of the basic need and suitability is free. Detailed analysis, data preparation and implementation are priced according to a scope agreed in advance.

Does a municipality have to introduce the whole system at once?

No. You can start with one building, a group of metering points or a single workflow. A pilot has a specific objective and a limited scope. Further expansion is assessed against the outcome, the municipality’s priorities and its budget.

Who owns the municipality’s data?

Data and files supplied by the municipality remain its data; ownership of the software is a separate matter. Before implementation, we agree the export scope, a readable handover format, permissions, and retention or deletion conditions. Personal-data rights and mandatory retention periods are considered separately.

How long does an initial deployment take?

There is no single timeframe for every project. It depends on data readiness, the number of sites, available integrations and any on-site verification. Following the initial assessment, we prepare a plan with specific steps and dates; the implementation date is confirmed in the agreement.

All questions and answers

Does your municipality have a specific need?

You do not need a completed technical specification. Let us start with what you need to improve.

You may need to organise documentation for municipal buildings, get an overview of inspection deadlines or track fault resolution more easily. You may want to better understand energy and water consumption, or obtain data from a location you currently check only in person.

Describe your situation to us. It may involve one site, a particular measurement, a selected workflow or broader connections between operational data. At the outset, it is important to understand what you currently lack and what outcome would be useful for your municipality.

What helps us with the initial assessment

Briefly state which sites or areas the request concerns, how you work with them today and what you would like to change. Information about existing records, meters or technical systems that the solution should build on is also useful.

You do not need to know feature names or design technical connections. If information is missing or you are unsure how up to date it is, say so. Identifying what first needs to be added or verified can itself form part of a suitable first step.

What happens next

We first analyse the request and assess where SmartGovIOT can help. If we need additional information, we will identify specific questions. We then propose the next steps and a consultation where needed.

Within the recommended scope, we distinguish available capabilities from features requiring pilot testing or further development. Implementation details and pricing are prepared according to the actual need and agreed scope.

The initial assessment of the basic scope and suitability of the solution is free of charge. You can start with one specific area; further expansion depends on the municipality's experience, priorities and budget.

Tell us what you need to address.

Describe your requirements

Prefer email? Write to email contact.

Do not send passwords, access credentials or sensitive technical documentation in your initial message. We will agree on the necessary information and how to provide it afterwards.