For city management and service departments
A resident reports one problem. It becomes a ticket in streets, a referral to utilities, an inspection request, and a code case, each closed on its own terms by a department that did what it was supposed to do. The resident’s experience is one unresolved thing. That gap is measurable, and the handoffs inside it can be carried — the work order, the inspection and the enforcement decision cannot.
Departments are organised by capability rather than by problem, which is correct — you need people who know drainage and people who know pavement. But a resident reports a flooded street, and a flooded street is drainage, pavement, a blocked inlet, and sometimes a private property issue at the same time.
Each department receives its slice, works it correctly, and closes it. Nobody is negligent and nobody is tracking whether the flooded street stopped flooding. The metric everyone reports is closure time, which is a measure of departmental responsiveness rather than of the resident’s problem going away.
So the same request comes back. It is logged as a new request because it is a new call, and the recurrence is invisible in the numbers — a city can show improving closure times while the same eleven addresses generate the same complaints every spring.
Meanwhile the request arrives through every channel simultaneously. A call, an app, a web form, an email to a department, a message to a council member, and a comment at a public meeting. The same problem enters five times, is worked separately, and generates several closures for one situation.
And the council member is the escalation path of last resort, which means the loudest resident gets the fastest service and everybody in the building knows it. That is not a policy anybody chose; it is what happens when the ordinary path is not visible enough to trust.
No record follows a situation across departments, so closure is measurable and resolution is not — which means every improvement effort optimises the number the city already has rather than the one residents experience.
That is why closure times can improve for years while satisfaction does not. The measure is real, everybody is working honestly against it, and it is not the thing.
The first act is therefore to build the situation record, which needs no authority over any department. Group requests by location and by problem rather than by ticket. Count recurrences. Measure elapsed time from first report to the last related report going quiet, rather than to closure. Identify the addresses that generate repeat contact.
Cities are usually surprised twice by that. Once by the recurrence rate, and once by how concentrated it is — a small number of locations generating a large share of contact, each closed correctly many times.
What can then be carried is the handoff band. Recognising that a new request is the same situation as an old one. Making the referral to the second department explicit and timed rather than implicit. Keeping the resident informed across the whole situation rather than per ticket. Surfacing a situation that has been closed twice and reported a third time.
What never moves is the work: the work order, the inspection, the code determination, the enforcement decision, the permit, and any exercise of professional or regulatory judgement. Those belong to your staff and to your inspectors.
Recurrence at the same location — measured by count of situations reported again after a closure, and the interval between reports.
Concentration of repeat contact — measured by share of total requests generated by the top locations, which most cities have never computed.
Time from first report to the situation going quiet — measured by elapsed days to last related contact, reported beside closure time rather than instead of it.
Duplicate records for one situation — measured by count of requests matched into an existing situation rather than opened as new.
Handoff wait between departments — measured by elapsed time from one department referring to the next beginning.
Escalations arriving through a council member — measured by count of situations that reached an elected official before the ordinary path resolved them.
Resident contacts asking only for status — measured by count of contacts whose entire content is a status question about an open situation.
any work order, inspection, code determination, enforcement action, permit decision, or exercise of professional or regulatory judgement. Nothing here prioritises one resident, location or neighbourhood over another by any predicted characteristic — routing follows your own written rules, and the recurrence report is a measurement rather than a priority list.
Departments keep their own systems and their own tickets. The situation record sits above them and references their records rather than replacing them, because a second ticket system is how a city ends up with two answers about what was done at an address.
Requests are read from every channel you already run — the call centre, the app, the web form, the departmental inboxes — and matched into situations by your own grouping rule. Nothing invents a rule about what counts as the same problem.
Routing follows the rules your departments already use. Where a situation does not match any routing rule, it is reported as unrouteable rather than assigned to whichever department is nearest, because a wrong assignment is worse than a visible gap.
And resident-facing surfaces are built for somebody on an old phone, in the languages your city already supports, because a service request line that only works well for people with new devices is a service line that measures the wrong population.
The recurrence number is the point of this page and it is not flattering. A city that measures resolution rather than closure will find out that some things it has been reporting as fixed were not. That finding belongs to you, stays in your systems, and is exportable by you — a vendor holding a number like that on their own clock is an untenable arrangement.
Resident information stays inside your tenancy, on your retention schedule, and is not used to train anything serving another organisation. Service requests are public records in most jurisdictions and contain addresses, so the retention and disclosure handling is scoped explicitly rather than assumed.
Nothing prioritises. A recurrence report is a measurement, and turning it into an automated priority order would be a decision about which neighbourhoods get service first — which is a policy decision belonging to your council, not a feature.
And on assurance: an independent SOC 2 Type II attestation is in progress and no report exists yet.
The city manager’s question is what happens when the recurrence number is worse than the closure number. It will be, and the honest answer is that this is a measurement the city holds and chooses what to do with — including choosing to publish it, which some cities do and which is a genuinely strong position.
The clerk’s concern is that service requests are public records containing addresses. Retention and disclosure follow your existing schedule, and the situation record is subject to the same handling as the tickets it references.
Counsel should confirm that nothing here makes a determination and that nothing prioritises. Both are enumerated rather than described, with anything unclassifiable routing to staff.
And a council will ask whether this is a new system. It is not — departments keep their systems and their tickets, and the situation record sits above them.
One service category’s requests from the last year, grouped retrospectively into situations, with no live routing and no authority over any department.
Retrospective is deliberate: no live request is affected, no department has to change anything, and the finding is checkable against what field crews already believe.
The output is two numbers beside each other for the first time — closure time, which you already have, and time to the situation going quiet, which you almost certainly do not. Plus the recurrence concentration, which is usually the number that changes a conversation.
Stopping there is legitimate and sometimes right. If recurrence turns out to be low and evenly spread, the city is resolving what it closes and this page is not about your problem.
They may well be good, and the risk of measuring resolution beside closure is that the second number is worse. That is the honest reason to do it retrospectively first: you get both numbers on requests already closed, you hold them, and you decide what to do with them. Some cities publish the pair and find it builds more trust than a single flattering figure did. Others keep it internal and work the concentrated locations. Either is a choice you make after seeing it rather than before.
Nor should you. Departments keep their systems and their tickets, and the situation record references them rather than replacing them — a second ticket system is exactly how a city ends up with two answers about what was done at an address. If a proposal ever asks a department to work in a new queue, it has added a system rather than a measurement.
Correct, which is why it does not. Recurrence is reported as a measurement, not as a priority order, and nothing here routes or ranks by any predicted characteristic. What the city does with a concentration finding is a policy decision for your council, and it should be made by them visibly rather than absorbed into a routing rule where nobody can see it. If a proposal offers automated prioritisation, that is the part to refuse.
They should not accept being timed as individuals, and that is a real distinction. What is measured is the interval between one department referring and the next beginning — a property of the process, not of a person — and the departments should be able to see the measurement themselves. If they cannot, it has been built as oversight rather than as a tool, and it will be resisted for good reason.