Sector · Cities & urban operations
A city is not twelve systems.It is one operation.
Services, mobility, utilities, waste, permits and field crews usually meet only in a monthly report. Qeonix builds the layer where they meet in real time, from a resident's request to the crew that closes it.
The city operating layer
Every domain, one spine.
These are the systems a city already owns. What is missing is almost always the layer that lets them share a picture, a queue and an audit trail.
- Citizen services
- Mobility & traffic
- Energy & utilities
- Waste & cleansing
- Public realm
- Permits & inspection
- Parking & tolling
- EV charging
- Environmental sensing
- Command & control
- Field workforce
- Public safety integration
Reference architecture
From the residentto the physical city.
Read it downward as a request traveling to the street, and upward as evidence traveling back to the record.
- Service requests
- Reports & complaints
- Payments
- Permits
- Journeys
- City app
- Web portal
- Contact center
- Kiosks
- Field mobile
- Request lifecycle
- Routing & SLA
- Work orders
- Escalation
- Notifications
- Request triage
- Demand forecasting
- Vision on city assets
- Predictive maintenance
- Operations agents
- Asset registry
- GIS & spatial
- Telemetry store
- Digital twin
- Interoperability
- Command & control
- Incident management
- Live operational view
- Multi-agency coordination
- Emergency support
- Crew scheduling
- Mobile work orders
- Evidence capture
- Route optimization
- Completion & QA
- IoT sensors
- Metering
- Cameras
- Traffic systems
- Utility networks
- Autonomous assets
One request, end to end
What closing the loopactually looks like.
-
01
A resident reports a fault
A photo and a location, from the city app or the contact center.
-
02
Triage without a queue
Vision classifies the fault, matches it to an asset and sets severity.
-
03
Work order, not a ticket
The right crew, the right skill, the right parts, sequenced against the day.
-
04
Closed in the field
Completed on a mobile device with photographic evidence attached.
-
05
Verified and learned from
Outcome confirmed, asset history updated, recurrence flagged for planning.
The operating environment
The console the cityis run from.
Requests, SLAs, integrations and field crews on one screen, because closing the loop is an operations discipline, not a dashboard feature.
Service queue · live
- Streetlight fault · Zone 4Crew assigned
- License transfer · commercialAwaiting approval
- Water pressure report · Zone 2Triage: vision match 0.94
- Illegal dumping · camera eventWork order created
- Permit inspection · site 8SLA at risk: 4h left
Capabilities
Six places we do the work.
City command center
A live operational picture across departments, with incident management and multi-agency coordination rather than eight screens showing eight systems.
Connected infrastructure & IoT
Sensor, meter and camera estates brought into one telemetry layer with device management, health monitoring and a sane data contract.
Field operations
Crew scheduling, mobile work orders, route optimization and evidence capture: the part of a smart city program that is usually left out.
Environment & sustainability
Air quality, noise, water and waste monitored continuously and tied to the operational response, not only to an annual report.
Digital twin
A spatial model of assets and networks used for planning, impact assessment and scenario testing before work is committed.
Mobility & parking
Traffic, parking, tolling and EV infrastructure treated as one demand-management problem rather than four procurements.
What we have learned
Why smart city programs stall.
-
Start with a service, not a sensor
Instrumentation without a closed operational loop produces dashboards nobody opens. We start from a request type with a queue behind it.
-
Assume the estate is mixed
Cities run twenty vendors across three decades. The integration layer is designed for that, not for a clean-sheet replacement.
-
Design for the crew
If the mobile work order is worse than the paper it replaced, the program fails in the field regardless of the platform.
-
Measure the loop, not the launch
Time-to-close, repeat-fault rate and first-time-fix are the metrics that show whether the city actually got better.
Coverage
Operational domains.
Utilities
- Network monitoring
- Smart metering
- Leak & loss detection
- Outage response
- Demand management
Waste & cleansing
- Bin & route optimization
- Fill-level sensing
- Fleet tracking
- Contractor SLA
- Cleanliness indexing
Public realm
- Street lighting
- Parks & landscaping
- Signage & furniture
- Condition surveys
- Event operations
Safety & resilience
- Incident coordination
- Multi-agency comms
- Flood & weather response
- Crowd operations
- Business continuity
A dashboard shows a problem.An operation closes it.
Questions
Smart cities, answered.
A dashboard shows you a problem. This closes it. The platform turns a signal into a classified work order, assigns it to a crew with the right skills and parts, and confirms completion with evidence. The dashboard is a by-product, not the deliverable.
No, it is the normal starting condition. The integration and data layer is designed around a mixed estate with different ages, protocols and data quality. Replacing everything is almost never the right first move.
We scope a first domain, typically one high-volume request type with a field crew behind it, and take it end to end. That establishes the request lifecycle, the asset link and the field application under real conditions, and becomes the pattern the other domains reuse.