Features that connect data with day-to-day municipal operations.

How to read feature availability

Available means that the feature can be included in a proposal after the specific conditions, supported sources and required scope have been verified.

Pilot solution indicates a feature or a broader combination of features that is being tested within a limited scope and adapted to a specific way of working.

In development means that the capability is not yet offered as a standard available part of the solution.

A single area may contain both an available foundation and a pilot extension. We therefore indicate which part each availability label applies to.

Asset, site and equipment records

Information organised around what the municipality actually manages.

The starting point is to identify a site, space or device unambiguously and preserve its links to other data. A building name alone is not enough when it contains several distribution boards, pumps or meters. Staff need to distinguish the particular item and know where it is located.

Within the agreed scope, technical data, documentation, measurements and related activities can be assigned to the record. The records can then provide a starting point for an inspection, repair or an update to the asset register.

When preparing data, confirmed information is distinguished from material that still needs to be checked. Adding a device to the register does not, by itself, confirm its technical fitness or that all its data is up to date.

Illustrative example: An asset manager opens the school building record, selects the plant room and a particular pump, and finds the available data and supporting material there instead of searching through all the school's documents.

Availability: Basic equipment and technical data records are available according to scope. Combined records of assets, spaces, documentation and operational relationships are a pilot solution.

Dashboards and map view

The information you need for your work comes first.

A dashboard is the initial working overview. It should help identify which events, deadlines or assets require attention and allow the user to continue to a specific record.

Management may need a summary of unresolved problems, an asset manager the status of assigned sites, and a technician their tasks. The goal is not to show everyone as much data as possible, but to present relevant information in an understandable order.

A map view adds context where location has practical significance—for example, for sites, metering points or lighting points. The accuracy and completeness of the display depend on verified input data.

Illustrative example: An asset manager sees sites with open requests and moves from a selected location to the problem description, assigned task and available documentation.

Availability: Pilot solution. The specific overviews, map layers and their content are defined for each deployment.

Measurements, consumption and long-term trends

The current value and a history that helps explain its significance.

Supported measurements are stored over time and assigned to a particular source, device or metering point. Users can view the available history and compare trends over a suitably chosen period.

The unit, time and source of a value matter. A one-off meter reading does not offer the same possibilities as regular measurement. Missing data also needs to be distinguished from a zero value, and the last message received from a confirmed current status.

Data prepared this way helps investigate deviations and evaluate measures taken. A chart alone, however, does not establish the cause of a change.

Illustrative example: A technician monitors the temperature trend in a plant room. They check when the change began, whether it recurs and whether the sensor is still sending data regularly.

Availability: Supported measurements, history and basic trends are available according to scope. Combined evaluation across several areas is being developed as a pilot.

Alarms, events and activity history

From an alert to information about what happened and how the situation was handled.

An event should be linked to a source, time and specific location or device. Staff can then distinguish whether it represents an exceeded threshold, missing data or another supported technical state.

Within the pilot scope, a basic alert may be followed by taking responsibility for the event, adding findings and recording the outcome. Acknowledging receipt of an alert is not the same as removing the cause of the problem.

The history should preserve the significant steps so that a later review can establish what was checked and whether further action is still needed.

Illustrative example: A sensor stops sending data. A staff member checks the device's availability, records the cause found and, after corrective action, verifies that measurement has resumed.

Availability: Basic alerts from supported sources are available according to scope. A shared event overview, prioritisation and the subsequent resolution process are a pilot solution.

Tasks, maintenance and statutory inspections

A deadline should be linked to a specific activity and outcome.

A fault, planned maintenance activity or inspection can have its own record with a description, priority, deadline, responsible person and link to a site or device. The necessary supporting information stays with the activity it concerns.

Planned activities are based on verified requirements and documentation. The system's role is to support work organisation and notify users of agreed deadlines, not to determine professional conclusions independently or replace the inspection itself.

After completion, the result is recorded and the relevant supporting material is attached. Marking a task as complete should not replace the report or certificate intended to substantiate the activity.

Illustrative example: An asset manager arranges a scheduled equipment inspection. They then attach the resulting report to the task and record any deficiencies requiring further action.

Availability: Pilot solution. Task types, deadlines and the way tasks are closed are configured according to the organisation's needs.

Responsibilities and workflows

For each request, it should be clear who is responsible for the next step.

Shared records help only if they do not remain a list of unassigned problems. Responsibility, current status and what should happen next therefore need to be defined for each task or event.

A workflow should reflect the actual organisation of work. A simple task need not pass through unnecessary approvals, whereas a more significant intervention may require a decision from an authorised person.

When a task is handed over to a colleague, the findings and supporting information gathered so far should be retained. It should also be clear when work is waiting for a document, a decision or another activity to be completed.

Illustrative example: During an inspection, a technician finds that a repair requires further assessment. They add their findings and pass the request to the designated person, who decides on the next steps. The work does not remain in an undefined state without explanation.

Availability: Pilot solution. Important decisions and approvals remain with authorised staff.

Documentation, reports and notifications

Supporting information at the right asset and summaries tailored to a specific need.

Within the agreed scope, documents, photographs, manuals and reports can be assigned to a site, device, task or event. Users can find not just a file, but also the context in which it was created and what it is for.

Reports should bring together the available information for a specific question: which tasks remain open, which inspections are approaching or how selected measurements are changing. Their content and frequency are determined by users' needs and the available features.

A notification should lead to information that can be acted on. The delivery method and subsequent process are verified for the particular deployment.

Illustrative example: An asset manager prepares a boiler-room inspection. They find available manuals and previous reports alongside the equipment records and check the working overview for open tasks related to the inspection.

Availability: Basic reporting and notifications are available according to scope. Shared documentation management and regular operational reports are a pilot solution.

Integrations and data provenance

A connection should preserve the meaning of data, not merely transfer a value.

SmartGovIOT can use data from supported meters, sensors, technical systems and authorised data sources. Each connection is assessed against the particular device, available interface and permitted scope.

It should be clear where data comes from and what purpose it is suitable for. A local measurement, manual record and billing value should not be treated as interchangeable merely because they describe the same site.

Integration does not mean taking over every function of the original system. Being able to obtain a technical status does not automatically confirm that the device can be controlled.

Illustrative example: A municipal building has both manual meter readings and supported ongoing measurement available. Their sources and time periods remain distinct so that they can be used for an appropriate comparison.

Availability: Individually verified integrations are available according to scope. Expansion of the catalogue and shared management of data provenance are being developed as a pilot.

User roles, permissions and audit

Access according to the work the user is expected to perform.

User permissions define both the information available and the activities permitted. Viewing a document, editing a record, assigning a task and approving an intervention are different requirements.

The deployment design therefore establishes who manages assets, who works with measurements and who decides on important changes. The history of significant activities should support retrospective checks and work handovers.

The pilot does not include access for external service personnel. When a supplier carries out an intervention, an authorised member of the organisation's staff handles communication and assigns the material handed over to the relevant records.

Illustrative example: A technician works with their assigned sites and tasks. A manager monitors their overall status and decides on the next steps within the scope of their permissions.

Availability: Basic access management is available according to scope. More detailed permissions and audit views are verified for the particular deployment.

AI assistance

Help with understanding data, not a substitute for responsible decision-making.

Planned AI assistance is intended to support information retrieval, summarising available material, preparing reports and explaining data in everyday language.

The aim is for users not to have to answer every question by manually searching individual records. It must nevertheless be possible to assess which information an output is based on and whether it is sufficient. Missing data or uncertainty should not be concealed behind a convincingly worded answer.

Before it is made available, accuracy, use of sources, respect for permissions and the process for checking outputs must be verified. Important decisions, approvals and active interventions remain under the control of an authorised person.

Illustrative example of planned use: A user asks for a summary of upcoming inspections at their sites. AI prepares a draft overview from the available records, which the staff member checks before using it further.

Availability: In development. AI assistance is not presented as autonomous management of a municipality or a guarantee of error-free conclusions.

How features work together in a single work situation

Illustrative example: a recurring ventilation problem at a school

The records help identify the specific equipment and its location. Documentation provides the available supporting information, the history shows previous interventions, and a task records the current problem and the person responsible.

Where suitable measurements or supported technical events are available, they add to the picture of how the equipment operates. After the intervention, the result and any further action required are recorded.

The working overview can then show the request's status without management having to examine every technical detail. The individual features support the same process from different perspectives.

The example describes a combination of features within an agreed pilot scope. It does not mean that all the connections described are automatically available in every deployment.

We select features according to the specific need

A municipality does not need to compile a technical list of individual features. It is more important to know which work situation it needs to handle and what outcome it expects.

For one site, equipment and documentation records may be a suitable starting point; for another, measurement and a regular overview. Broader connections between tasks, events and responsibility make sense when suitable information and an agreed way of working are in place.

We therefore prepare the scope so that it is clear what will be introduced, what will be tested and which capabilities remain for a later stage.

Not sure which features you need?

Describe the problem, your current way of working and the sites or systems concerned. It also helps to know what you currently have to search for manually, repeatedly establish or record in several places.

We will analyse the request and suggest a suitable combination of available capabilities, a possible pilot and the next steps.

Describe your requirements · View solutions

Alternative contact: info@smartgov.sk