Municipal software
Resident apps, administration systems and urban operator services. Requests, mapped assets and service work share one workflow.
Discuss a municipal systemExplore the scopeDefine access, responsibilities and the next action for residents, administration and contractors.
Requests with an address and photo, appointments, notifications and resolution history.
Requests with an address and photo, appointments, notifications and a history of the resolution. Forms explain what information is needed, and the account shows a clear status.
Task assignment, response approval, deadlines and a department activity log.
Intake, assignment between departments, response approval, deadlines and an activity log. We define how repeat requests and transfers to another service are handled.
Mapped assets, documents and work history. Every record has a stable identifier.
City assets, roads, lighting and sites on a map. Each asset has a responsible party, documents and work history; geometry and address share a stable identifier.
Accounts, timetables, transport events and payment statuses — within the existing infrastructure.
Passenger or carrier accounts, timetables, onboard device events and payment statuses. The exchange scope depends on the existing transport and payment infrastructure.
A request and a service visit should refer to the same asset. Staff can see earlier work, while residents receive an update on their own request.
An address can change. Identifiers and matching rules preserve the links between assets, requests and documents.
The public map shows an agreed set of information. Working records are available to the roles that need them.
Photos, comments and completion time become part of the assignment. The process owner defines when it can be closed.
Before development, we map the data: where the original record lives, who may change it and how exchange results are accepted.
| Source / scope | What we define | Outcome |
|---|---|---|
| GIS and asset register | Addresses, geometry, categories and owners | Asset record and change history |
| Request management system | New submissions, assignments, responses and statuses | Request linked to its resolution |
| Government services | ESIA, SMEV, GIS GMP or GIS Housing — subject to scope and access | A separately agreed connection scope |
| Transport and urban operator | Timetables, routes, events and payment statuses | Exchange monitoring and source reconciliation |
We scope the first release to an agreed area, asset set or department so the workflow can be checked with real users.
Map the request journey, roles, exceptions and existing systems. Define the outcome and the first-release boundaries.
Agree reference data, check addresses and duplicates, and identify source systems. Prepare migration and correction rules.
Walk through scenarios with staff and residents. Use test data to check access, external responses and recovery after a failure.
Provide instructions, an integration register and a support procedure. Assign owners for data, requests and technical incidents.
We need owners for the workflow, source registers, staff access and publication approval. The contractor should not decide user authority on its own.
Define the specific scenario and whether ESIA or SMEV applies. Connection depends on participant status, current procedures and granted access rights.
Yes, where the required data and interfaces are available. We first check formats, address quality, map rights and geometry update rules.
We check devices and connectivity. Where needed, we design local task storage, upload after reconnection and conflict handling.
Describe the area, users and existing systems. If there is no specification yet, we will start with the workflow and available data. For procurement, include the specification scope, hosting requirements, source-code handover and acceptance criteria.
Discuss a municipal system
