What's behind a citizen report?

The brief looked like a system-design request: improve the citizen experience and internal processes across channels, with a new model for managing service-related reports. The website form was part of that system, and improving it would matter, but the first task was to understand what the system had to treat, before redesigning the form.

We worked across four streams: interviews with the people receiving and managing reports, inside and outside the City; mystery analysis across all reporting touchpoints; navigation of internal management systems; and detailed journey mapping.

The interviews involved seven municipal departments and five municipal service companies, each conversation crossing organisational boundaries that usually stay closed inside a single project. We asked each interviewee the same opening question:

What is the typical path of a report in your case?

The phrase "in your case" became the key to the project: for each person the path was different.

One word, many meanings

For citizens, a report could mean many things: a pothole, a broken streetlight, a question about the waste tax (TARI), a complaint about a noisy neighbour, an idea for the city, a request for a certificate. Everything entered through similar doors, with the same label. For the URP, a report was something to classify and route. For second-level technical offices, it was work arriving from elsewhere, sometimes unrelated to their mandate. Some offices expected the URP to filter more; the URP often lacked the criteria, authority or tools to do so.

The website form showed the problem clearly. Of the 139 reports the official form received, only 19% were handled and resolved by the URP; the remaining 81% were forwarded to second-level offices. The channel that was supposed to filter forwarded almost everything, and downstream each office decided for itself what belonged to its responsibility and what did not.

Only one report in five found an answer at the first level. The other four entered a maze.

Six ways to report, six ways to get lost

Crossing mystery analysis with interviews revealed a citizen experience with many doors and no reliable route, each channel with a different failure mode, none giving the City a complete view of what it received.

The two most dispersive channels were the least traceable: the phone, generating around 1,000 reports a month without automatic registration, and direct email to internal contacts, used precisely to bypass the queue.

Behind these channels, the City had an invisible architecture. In theory the system had three levels: the first receives and assigns, the second takes charge and resolves, the third maintains the systems. In practice, reports entered from any level and moved backwards, sideways and in loops, in what one person described as continuous escalation. A report could be received by the URP, sent to a technical department, rejected, sent back, forwarded to a service company, harder to locate at each step. At any given moment, no one could say how many were open or where.

Translation before automation

This is where I focused the first part of the work. Before touching the process, we had to fix the object. What is a report? What is not? Which requests belong to this process, and which, though they enter through the same channels, should be recognised as out of scope rather than processed by mistake?

There is something I learned in those interviews that holds beyond Vicenza. To understand a public process, it is not enough to ask how it works; you have to hear what people would like and do not dare to ask. The operator who treats talking to citizens as time stolen from real work, the office that feels things outside its mandate dumped on it, the person who defends an old practice because it is the only thing that gives control: a process audit never hears these voices, yet they explain why a system goes unused. The technical side explains how the machine runs; the personal side explains why it jams.

Translation, in this project, meant listening to that second side first, and it became the opening move of every flow we designed. A citizen does not arrive with a classified issue. They arrive with a sentence: "There is a hole in the road"; "I do not know who to ask". The system cannot simply record that sentence; it has to turn it into a governable object: category, type, location, responsibility, status. In the blueprints, the first phase is named exactly that, needs translation. It is translation, not registration.

From research, we defined four guiding principles. First, educate citizens, so they understand what a report is and where to send it. Second, educate operators, so the new process does not collapse the first time it meets old habits. Third, connect the organisations and systems that already exist, instead of pretending the City operates in isolation. Fourth, orchestrate communications, giving citizens consistent updates throughout the journey.

Under all four sat the same issue: visibility. The City did not know how many reports were open, where they had gone, or who was handling them. The challenge was to design a model that gave the administration the sight it lacked, turning reports into visible, traceable and governable objects.

Two scenarios, one political choice

Together with the service designer in the team, I worked on two target scenarios. They were two possible governance models, not two interface options.

The first was conservative: City and municipal service-company touchpoints would coexist, each with its own system but able to talk to one another, and the existing reporting app would stay with the company that already managed it. The second was transformative: the City would become the central governing actor through a single system that collects, classifies and routes reports, and the app would be internalised under the City's ownership.

The choice between the two did not belong to us. It depended on how much control the administration was ready to take back, and that was a political and organisational decision before it was a design one. Our role was to make it informed. The City chose the transformative scenario.

That decision changed the philosophy of the service. The City would no longer treat reporting as a set of disconnected intake points; it would treat it as a managed civic process.

Six interventions

The selected model required six concrete interventions, each tied to a broken node revealed by research. We presented them as parts of one system rather than a feature list: bringing into one governed model what had lived scattered and outside traceability.

Under these interventions, the system had to treat a report in two ways. Some reports are managed by the City: classified, routed, monitored and closed within the system. Others are only known to the City: handled by someone else, yet still visible enough for the City to govern the relationship with the citizen. That distinction became central to the detailed blueprints.

The easiest case is the report that enters the City system, is classified correctly and reaches the right office. We designed it, but it was not where the project most needed attention. The critical journeys were the unstable ones: a report sent to the wrong office and reassigned; a report that cannot be processed and is rejected with a clear explanation; a report paused for further information; a report transferred to an external service company. These were the cases the old process managed verbally, across channels, without a reliable trace, and exactly where reports disappeared. So we fixed them inside the system.

The hard part: municipal service companies

Vicenza does not manage every report alone. Some are handled by municipal service companies, each with its own tools, processes and technical maturity. Some could integrate fully with the City's system. Others could not. Asking every company to integrate the same way would have produced an elegant but unrealistic model, so the system was designed around three integration levels.

First level: internal management

The first level covers reports that remain inside the City. The report enters through a City touchpoint, is translated into category, type and location, then routed to the right office. The system tracks each step, from intake to closure, and the citizen receives updates as the report moves.

Second level: full external integration

The second level covers companies whose systems can communicate fully with the City's. The report changes hands, but the citizen experiences no break: status stays alive, communications continue, the City can still see what is happening. The work is handled outside the City, yet the relationship remains governed.

Third level: light integration

The third level was the most important design decision in the project. Some companies, such as those managing lighting or parking, use their own systems with no automatic bridge to the City's future single system. A report assigned to them leaves the City's field of view the moment they take charge.

The comfortable response would have been to ask them to integrate anyway. We did not. We designed for the reality that they might not. Reports assigned to those companies start with an automatic email, then are retraced through a periodic summary the company sends back to the City, ideally every 15 days, which the URP realigns by hand in the central system.

For those reports, the City system cannot send a final closure email to the citizen. It does not know when the issue has been closed, because that change of status lives inside a system it cannot see. That is a limit, and the design does not hide it. It declares the limit and places a human safeguard around it: the periodic summary and the manual check by the URP.

This is the decision I value most in the project. A system that recognises where its own eye does not reach, and places a person there, is more serious than one that promises total automation and fails in daily use. Visibility comes in degrees. The model had to account for each one.

Giving an administration a complete view has a cost, and that cost is counted in people. Before the project, Vicenza's reports were managed by two URP operators for an effort worth roughly half a full-time equivalent (FTE). That half covered around 375 reports a month, the ones it could register through form, switchboard and email, already a fraction of the city's real reporting volume.

The new model would trace more, route more, communicate more and operate on a larger base. If the single system also captured reports that had lived outside the City's channels, the expected volume would rise to around 1,900 a month. A better process would not reduce the work by magic; it would reveal work that had been invisible.

To make that cost discussable, we built three staffing hypotheses, calibrated on how much coordination the City wanted to keep and grounded through comparison with other municipalities. Parma was the closest reference. It runs its reporting with four and a half full-time staff: two and a half outsourced to an external company and two internal coordinators. Genoa offered a larger-scale comparison. From that benchmark, the estimate for Vicenza moved from the current half an FTE to three scenarios, 2.7, 3.1 or 4.7 FTE, depending on the operating model.

Those numbers were part of the design, not a footnote to it. A model that asks an administration to govern more must also say what governing more costs.

Bringing Vicenza to Parma

The comparison with Parma served a purpose beyond staffing: it showed the proposed direction was not theoretical. Parma had started from similar process problems and had already moved to a single system, centralised handling and fewer workarounds. The continuous escalation that dispersed reports in Vicenza had been absorbed there into one governed flow.

So we brought the two administrations into the same room. Vicenza's general management and the people who work on reports every day visited Parma for a working session we mediated. The discussion was technical, reassignment rules, coordination roles, platform customisation, but the real value was organisational: Vicenza could see a city of comparable scale that had gone through the same bottleneck and come out with a working model, and that made the choice less abstract.

Citizens will never see the blueprint. They will see the messages they receive while their report moves through the process, reading in them whether the administration is accompanying them or has lost them.

I redesigned the communications across the journey using three rules. Give citizens only the information they need, while keeping internal machinery out of sight. Use language that is simple and direct, yet not careless. Make sure every request receives an answer, including reports that cannot be processed, which in the old process too often ended in silence.

The clearest example is the first message. Today, when a report arrives, the citizen receives two separate communications: one with a request number, one with a registration number. Two codes, two emails, to say what is effectively one thing. I merged them into one message, with one identifier to keep.

Before, the citizen read a sentence like:

Your request for the Report a Service Issue service has been correctly received. The request number is 9434da0c-49d2-43af-8f4c. Always refer to this identifier for communications related to your request.

Afterwards, the message became:

Thank you for your report. We have received it and assigned it an identifier, which you should keep for any future communication.

When timelines extend beyond expectations, the system says so before the citizen has to ask, because in a relationship between citizen and administration, silence is never neutral, and reads as abandonment. When a report passes to a municipal service company, the message says so, so that an update from a different sender does not look like a mistake.

Far from decoration, the communication layer is the part of the system the citizen actually experiences.

The original mandate was to design the new reporting model and the experience around it; implementation sat outside the scope assigned to us. We delivered two viable scenarios, the blueprints that translated the selected scenario into process across three integration levels, six interventions on the broken nodes, three staffing hypotheses, rewritten citizen communications and an eight-action roadmap. The design went as far as the point where someone could pick it up and start, and the City of Vicenza decided to build it.

At the start, four reports in five did not find an answer at the first level, and many more were never registered at all. In that context, the most useful thing we could give the administration was the ability to choose a model, knowing what it would cost and require.

There were no post-launch impact metrics to claim: the project ended before implementation, and that matters. The measure of this work is less a conversion rate or a satisfaction score than the quality of the decisions the administration could now make: what to centralise, what to leave distributed, where to automate, where to keep a human safeguard, and how to keep citizens informed even when the process crosses organisational boundaries.

It is a less convenient result to sell, and a more honest one to stand behind.

Afterword

This case shows something that larger programmes often hide. In big projects, the first work, getting the organisation to agree on what is being handled, stays submerged under everything else, almost invisible. In Vicenza, for a single process inside a provincial city, that work stayed on the surface, legible, impossible to skip.

Before any system comes the agreement on what the system is meant to handle. That agreement is already design, not its prelude.