Citizen Services9 min
Many citizen reports bounce between departments because the report type was picked from a list nobody governs. This article explains why every service needs a defined owner, required data and destination, and which rules let a report reach the team that resolves it on the first try.
Citizen Services9 min
Many citizen reports arrive with references like «across from the store» or «by the park», and the crew loses the visit searching for the spot. This article explains why location must be captured as data rather than as a description, and which operating rules make every report land on a verifiable point on the map.
José Campillo
Citizen Services8 min
Many municipalities measure how many reports they close, but few measure how often the same problem returns to the same place. This article explains why recurrence is the most useful signal citizen services leave behind and how to turn it into preventive maintenance and better investment decisions.
José Campillo
Citizen Services9 min
Most municipalities already confirm that a report was received, but almost none show what happens next. This article explains why operational transparency, with statuses, evidence and public data drawn from the same workflow, is the most direct lever for rebuilding trust in municipal services.
José Campillo
Citizen Services7 min
A citizen-service platform does not mature when every report receives a case number. It matures when classification, location, deduplication, department ownership, SLA logic, field evidence, and follow-up operate through governed routing rules.
José Campillo
Citizen Services7 min
Municipal service deadlines only create value when they are tied to ownership, evidence, escalation, citizen communication, and operational correction. This article explains why SLAs in citizen service must behave like governance rules, not countdown clocks.
José Campillo
Citizen Services7 min
Municipal citizen service does not become reliable when a report receives a folio or a status update. It becomes reliable when intake, routing, field execution, evidence, closure, citizen follow-up, and analytics operate as one verifiable loop.
José CampilloA resident reports water gushing up next to the sidewalk. The city app has no "water leak" option, so she picks "pothole," because the pavement is already sinking. The report gets a ticket number and is routed to the pothole crew.
The crew arrives, sees that the problem is a leak, and knows it cannot patch anything while water is still flowing. It sends the case back to the office. Someone reclassifies it as "other" and forwards it to public works. Public works replies that water belongs to the water utility. Three days later the report is still open, the leak is still running, and the pothole is bigger.
Nobody in that chain did a bad job. Each team did its part with the information it received. The problem came earlier: in the list of options the resident saw on the screen. That list said what could be reported, but not who resolves it, what data is needed, or what to do when a report fits none of the options.
A dropdown is an interface. A service catalog is an institutional agreement on who owns each problem in the city. When a municipality confuses one with the other, every misclassified report becomes a case that bounces.
The problem is neither new nor unique to Mexico. When Minneapolis was preparing its 311 line, a 2008 case study published by the Office of Community Oriented Policing Services (COPS) of the U.S. Department of Justice documented that 20 to 30 percent of the calls received by city agencies were routed to the wrong agency. For the police, just over 60 percent of calls were misdirected.
New technology does not solve this on its own. In March 2026, a public communication filed to Los Angeles City Council File 26-0162, which reviews the performance of the new MyLA311 system, described three symptoms any citizen services team will recognize:
The communication points to a consequence that goes beyond efficiency: when a category is hidden, the problem stops being measured. Nobody can ask for budget for something the system does not record.
We have written before about why routing needs operating rules, not just ticket numbers, and why an address is not a location. The point here comes earlier: routing rules only work if the report type they receive is the right one.
In Mexico, the foundation of the catalog is in the Constitution. Article 115, section III, establishes that municipalities are in charge of, among other things, drinking water, drainage, sewerage, and wastewater treatment and disposal; public lighting; street cleaning and the collection, transfer, treatment and final disposal of waste; markets and wholesale supply centers; cemeteries; slaughterhouses; streets, parks and gardens and their equipment; and public safety, municipal preventive police and traffic. It adds any other services that state legislatures determine.
The same article allows municipalities to coordinate and associate with one another, or to sign agreements with the state so that it provides some services temporarily or jointly.
That explains why the catalog cannot be a generic list copied from another city. In one city, water is run by a decentralized utility. In another, garbage collection is under concession. In another, lighting on primary roads belongs to the state. The same "streetlight out" can have three different owners depending on the stretch of road. A useful catalog reflects that reality; a dropdown ignores it.
Citizen reporting standards solved this years ago. The Open311 GeoReport v2 specification, used by several cities to receive reports from third-party apps, does not treat report types as loose labels. Each service has a unique code, a name, a description, keywords that help people find it, and a group that organizes it with related services. Each service can also declare its own attributes: what data it asks for, of what type, in what order, and which fields are required before the report can be submitted.
That structure points to what a municipality needs to define for every report type:
A name residents actually use. People do not report a "secondary distribution network failure." They report "water coming out of the sidewalk." The catalog needs plain-language names and synonyms that lead to the right option.
An owner. The department, utility or contractor responsible for resolving it, with a person accountable for that category. If a report type has no owner, it should not be published.
A destination based on place. When responsibility changes by zone, road type or concession, the catalog must record it so the system picks the destination without relying on an operator's memory.
Required data. What the crew needs to handle it on the first visit: a photo, the location, the streetlight or meter number, whether people are at risk. Each service asks for its own; not every report needs the same form.
A committed response time. The deadline the service is measured against, agreed with the department that delivers it rather than set by the platform.
A rule for what does not fit. What happens to reports that match no category: who reviews them, how fast, and how to decide whether a new type is needed.
With those six elements, the catalog stops being a list and becomes an operating contract between the front desk, the departments that deliver services, and residents.
Misclassified reports tend to have repeatable causes:
Categories organized by department instead of by problem. If the list says "Public Works Department," "Public Services Department" and "Water Utility," residents have to guess the city's org chart. Almost nobody knows it.
The "other" bin. When "other" is one of the most used categories, the catalog is saying it does not describe the city. Every report that lands there waits for someone to read it, interpret it and route it by hand.
Duplicate or near-identical categories. "Pothole," "sinkhole," "damaged pavement" and "street in poor condition" may go to the same crew or to three different ones. If nobody decided, each operator decides differently.
Reclassifications without a trail. The receiving team changes the category and sends it back, but the system does not record who changed it, from what to what, or why. The municipality loses the information that would tell it which categories are failing.
Uncontrolled catalog changes. One department hides a category because of a backlog, another creates a new one for a temporary program, and nobody updates the dashboards. One month's indicators can no longer be compared with the next.
Organize by problem, not by agency. Group report types by what people see: water, lighting, trash, streets, parks, animals, noise. The responsible department is internal catalog data, not an option residents should have to choose.
Assign an owner to every category. Every published report type should have a responsible department and a person accountable for it. Review the catalog with those people at least twice a year.
Set the destination by rule. If responsibility depends on zone, road or concession, write it as a rule in the system. An operator should not have to remember which stretch of which avenue belongs to the state.
Ask only for data that changes the response. If a field does not change who goes, what they bring or how urgent it is, it does not belong.
Record every reclassification. Keep the original category, the new one, who changed it, when and why. That log is the best diagnosis of the catalog a municipality can have.
Measure bounces. Review every month how many cases changed category or department before being handled, by report type and by channel. A high rate in one category means its name is confusing or its owner is unclear.
Version the catalog. Creating, merging or hiding a category should be recorded with a date and a reason, and dashboards should be able to show that history. Hiding a category does not make the problem go away; it only stops counting it.
Fewer wasted visits. A well-classified report reaches the crew that can resolve it, with the data it needs.
Response times you can defend. When a case bounces, the service clock keeps running while nobody is working on it. With fewer bounces, the measured time looks like the real response time.
Comparable indicators and data-backed budgets. If categories are stable and their changes are recorded, the municipality can compare months and zones, and show the real demand for each service when asking for resources.
Agora, Intello's citizen services platform, is designed so that every report reaches the team that resolves it with the information it needs.
Omnichannel intake brings everything that arrives through web, app, chat, phone and walk-in counters into a single system, so every channel uses the same categories. Automated intelligence, with classification, deduplication and data extraction, helps organize what comes in, including reports residents describe in their own words.
Crew and vendor management sends geolocated work orders with all the case information to in-house crews and external vendors on the same platform. Full traceability records who did what, when and with what result, so every change to a case stays in its history.
On top of that foundation, real-time dashboards and territorial heat maps show which report types concentrate where.
If several answers are no, the municipality has a dropdown, not a service catalog.
The service catalog is the first operational decision a citizen report touches. It defines which problems in the city the municipality recognizes as its own, who answers for each one and with what information. Governing it as an agreement between departments, with owners, rules and recorded changes, costs little compared with every report that bounces.
If your municipality wants every report to reach the team that resolves it on the first try and stay traceable until it is closed, see how Agora works, learn how Tribuna applies the same logic to public safety and civic justice, or request a demo. If you are interested in the other half of the problem, read why an address is not a location.