Case study
A city government in southern Ontario serving a population of about 180,000 had residents writing to eleven departmental inboxes, a third of them the wrong one. We built an intake layer that reads, classifies and drafts, while officers still approve.
Named only with client approval Figures marked are illustrative Reply within one business day
Illustrative product interface — not client data.
OlDevs built an AI intake and triage layer for a city government in southern Ontario serving a population of about 180,000.It reads every incoming enquiry, classifies it by service area and urgency, extracts the address and the specific request, and drafts a reply in English or French. Routing happens automatically, but the draft reply, any service request raised in the city's work order system and every escalation waits for a named officer to approve or edit it. Eleven intake inboxes were consolidated to one, and every classifier decision is logged with its confidence so the city can correct and retrain against real cases.
Key facts
The challenge
Residents wrote to eleven different departmental inboxes, and roughly a third of what arrived was in the wrong one. Staff spent their mornings reading messages only to forward them, bylaw complaints sat unread beside pothole reports, and nobody could say how long anything actually took. Council wanted faster responses without anything consequential being decided by software.
Residents cannot be expected to know which department owns a problem, so roughly one message in three landed somewhere it did not belong. Each one had to be read by someone whose only possible action was to send it on to a colleague.
Staff opened the day by triaging a queue by hand, which meant the first hours went to sorting rather than resolving. The work was necessary, repetitive and invisible, and it pushed actual responses later into the day every day.
A bylaw complaint that needed attention today sat in the same undifferentiated list as a pothole report that could wait. Nothing in the inbox distinguished them, so priority depended on the order messages happened to arrive in.
With eleven inboxes and forwarding by hand, nobody could say how long a resident actually waited. Council was asking for faster service against numbers the city could not produce.
What we built
OlDevs built an intake layer that reads every incoming enquiry, classifies it by service area and urgency, extracts the address and the specific request, and drafts a reply in English or French. Routing is automatic, but the draft reply, any service request raised in the city's work order system and every escalation waits for a named officer to approve or edit it first. Each decision the classifier makes is logged with its confidence, so the city can see where it is wrong and retrain against real cases.
Mail from all eleven departmental addresses now flows into a single queue that reads each message, identifies the service area and urgency, and routes it to the right team. Residents keep writing to the address they already know.
The system pulls the civic address and the specific ask out of free text, so a service request arrives with the location and the problem already filled in. Officers correct what is wrong rather than retyping the whole thing from the message.
A reply is drafted in the language the resident wrote in, English or French, and held for a named officer to approve or edit. Nothing is sent, no work order is raised and no escalation is made without that person acting on it.
Every classification is written down with the confidence behind it and whether an officer changed it. That record shows where the model is weak, and gives the city a set of real corrected cases to retrain against.
Process
Enquiry sampling and service mapping
We read a real sample across all eleven inboxes with city staff, agreed the service areas and urgency levels, and wrote down which requests must always reach a person.
Classifier build and evaluation
Classification and extraction were built and measured against real enquiries in both English and French, with error cases reviewed alongside the staff who handle them.
Weekly demos with front line officers
Officers saw working software every week and edited real drafts in it. Their corrections shaped the reply templates, the urgency thresholds and where the approval step sits.
Work order and approval integration
The city's work order system was connected so an approved enquiry raises a service request, with the officer's name recorded against the decision that created it.
Consolidation and measurement
The eleven inboxes were cut over to a single intake queue, and response and rerouting figures were reported to council from data the system produces itself.
Stack
Intake and messaging
Language and classification
Application
Data and audit
Integrations
11→1
Intake inboxes consolidated
−47%
First response time
3.2x
Enquiries closed without rerouting
Outcomes
Intake was consolidated, recorded as 11→1 Intake inboxes consolidated, so staff work one prioritised list instead of eleven separate ones that nobody could see across.
First response time fell, recorded as −47% First response time, because messages reach the right team on arrival rather than after a morning of forwarding.
Enquiries closed without rerouting rose, recorded as 3.2x Enquiries closed without rerouting, as classification put each request in front of the team that owns it.
Staff still read everything that goes out, but they are editing a draft instead of writing from a blank page, and each approval is recorded against their name.
In their words
Nothing goes out that one of our officers has not read, but they are approving replies now instead of writing them from scratch.
Director of customer service, mid sized municipality
Municipal government
FAQ
No. Routing a message to a team is automatic, but the reply itself, any service request raised in the work order system and every escalation waits for a named officer to approve or edit it. The officer who approved a given response is recorded with it, so accountability stays with a person.
The system detects the language a resident wrote in and drafts the reply in that language, English or French. Bilingual EN/FR capability is part of how we build and test, so French enquiries are classified and drafted as first class cases rather than treated as an afterthought.
Every classification is logged with its confidence and with whatever an officer changed it to. That gives the city a live view of where the model is weak and a set of genuinely corrected cases to retrain against, rather than a vendor deciding on their behalf what needs fixing.
No. The existing departmental addresses keep working and residents carry on using whichever one they know. The consolidation happens behind them: all eleven feed one intake queue, which is why enquiries stop bouncing between departments before anyone answers them.
The city does. Clients own all code, designs, accounts and IP from the outset, including the classifier, the training data drawn from their own enquiries and the logs. The work runs on the city's own accounts, so there is nothing to migrate if you later take it in house.
Let’s connect
Tell us what is not working. We’ll reply within one business day with how we would approach it and a tailored quote.