Note to 311: Don’t mark things fixed until they really are
Good advice sometimes comes from an unlikely source, which makes it easy to disregard.
Here’s hoping Toronto 311 will consider the suggestions of Robert Finlay on how to respond to problems posted on SeeClickFix, a humble blueprint for fairly and accurately informing the public on their status.
I’ve blogged and written a column over the past week about 311’s insistence on marking problems on SeeClickFix as “closed,” which is meant to be used only when they’re fixed, after issuing a service request ID number.
In one case, people kept going back into the report and re-opening it because it hadn’t been fixed, but each time, 311 would create a new service request ID number and mark it closed again. It happened five times over, prompting outrage among SeeClickFix users.
To be fair, 311 it isn’t obligated to surf SeeClick for problems beyond potholes and graffiti, which are automatically entered into its data system, and deserves credit for seeking out and trying to fix problems not directly reported to it.
Patricia MacDonell, manager of 311 Toronto, told me that in the case above, the problem was wrongly categorized as a pothole, which repeatedly triggered an automated “closed” response because some potholes had been filled at that location.
But she conceded that 311 needs to do a better job of actually reading SeeClickFix complaints, to make sure they are properly understood and acted on.
Finlay has some good ideas on how to do it, which he sent me in an email that shows an advanced understanding of the issues.
“Saying that something is fixed as soon as a service request is made is incredibly stupid,” he said.
“They are strictly going on whatever the public has said is the problem. The real cause of the problem might be something quite different.
And even if the citizen has correctly identified the problem, the fix might be complicated.
“How could anyone really know what the problem is until someone from the city sees it?
“Why don’t they simply report what is actually happening?
“When a problem is reported, simply record the day and time. When the fix is scheduled, report the expected date. When they start working on the fix, report it. When completed and it is certain that the problem is fixed, then report it.
“Internally, wouldn’t they have something like that, so they would know what work was to be done and who’s available to do it? So why wouldn’t the city use that to enter the information on SeeClickFix?”
The city does, but its computers don’t interface with SeeClickFix, so someone from 311 would have to go into each SeeClickFix report and continually update it.
MacDonell told me that 311 staffing levels are geared for its own system; monitoring SeeClickFix creates extra work for its staff, which would only get worse if they’re required to regularly update the status of fix efforts on SeeClickFix.
Given the popularity of SeeClickFix as reporting tool for local problems and citizen engagment, it's worth the trouble.