Request a demo

Blog posts about advice

Return to latest posts

How to increase transparency with FixMyStreet’s report statuses

FixMyStreet, our map-based reporting tool for street and highway problems, and FixMyStreet Pro, the fully branded, hosted and integrated version of the service, enable you to assign a status to each report you receive that is visible to the public and reflects the issue’s journey to resolution. 

With all reports displayed on the map, this report status adds an extra layer of transparency for councils and other public sector organisations using the service, allowing citizens to see not only what problems have already been reported, but also what’s being done about them.

A tool for transparency

When used properly, report statuses help to build trust and increase transparency, while also deterring duplicate reports and failure demand, which pushes report-makers back onto the phone to your customer contact centre in search of clarification or more information.

Councils and other public sector FixMyStreet Pro customers can choose from a number of statuses, designed to help you accurately share where a report is up to within your internal processes in a way that is easy for citizens to understand. 

The standard report states on FixMyStreet are currently as follows:
  • Open

Report is open and confirmed (automatically applied to all new reports once report-maker has verified their email [if not signed in at the time of reporting])

  • Action scheduled 

Report has been reviewed and action has been scheduled

  • For triage

Report is awaiting internal review or re-categorisation

  • In progress

Report’s resolution is in progress/action is being carried out

  • Investigating

Report is under investigation

  • Planned

Report’s resolution has been planned/scheduled as part of a wider maintenance project

  • Closed

Report has been closed for one of a number of reasons (this is a generic status only to be used if another cannot be assigned, such as ‘fixed’, ‘not responsible’ or ‘no further action’ – reasons for closure can and should be included within the response template, which can be done manually or automatically via integration)

  • Duplicate 

Report is about an issue that’s already been reported

  • Internal referral

Report has been referred to another team within the council/public body

  • Not responsible

Report is about an issue that is the responsibility of another council/public body/private organisation

  • No further action

Report’s issue cannot be fixed/issue does not meet intervention criteria

  • Fixed

Report’s issue has been fixed

Best practice

We leave it up to you to decide which statuses best suit your internal processes – report status names can be modified across the FixMyStreet platform (this includes the national, free-to-use FixMyStreet.com site) to better reflect those used by your customer service and inspection teams, and terms used within your integrated back-end systems. 

You can also make use of hardcoded statuses, which are named differently on the front and back end to make them easier to understand for citizens on one side and staff on the other.

Equally, additional statuses can be added if required, or you can restrict those which you do not want to be visible to the public.

However, we do recommend that, when changing the status of a report, you make use of FixMyStreet’s ability to provide a tailored, explanatory response update that will be attached to the report and emailed to all subscribers, giving more context about what the status means to help manage expectations. 

Screenshot showing an example of one of Bromley Council's response templates used via their FixMyStreet Pro portal. The response template is attached to the 'In progress' report status and reads: "Thank you for your report, this is not being investigated. Information on our services and the timeframes we aim to respond in can be found: [URL to Bromley's website]"
Example of a response template used by Bromley Council for reports marked ‘in progress’ on their instance of FixMyStreet Pro
For example, when marking a report as ‘no further action’, it’s important to say why this is to help the report-maker and anyone else who’s interested understand your reasoning.

Similarly, when marking a report as ‘action scheduled’ it is worth explaining your service level agreements to set expectations for when the action should be carried out.

You can also use automatic templates that can be added to the FixMyStreet Pro front-end workflow based on back-end codes. For example, multiple codes used in your asset management or CRM system can be attached to different ‘action scheduled’ responses. 

Or if you’re using FixMyStreet Pro as your case management system, you can create your own templates and simply select the most relevant as you go.  

Avoiding confusion

Whichever way you organise your report statuses, our golden rule is to ensure that reports are not marked as ‘fixed’ until the problem has actually been resolved, or assigning one of the closed statuses (eg. ‘closed’, ‘no further action’, ‘not responsible’) without providing an explanation as to why and what this means to you.

For example, ‘closed’ to you could mean ‘action scheduled’, but to the report-maker ‘closed’ could be interpreted to mean that the issue has been fixed, so when they see that the problem is still there, it may provoke them to call you or try to reopen or duplicate the report.

Sometimes this occurs because your customer contact centre hasn’t been provided with enough guidance on what each status means in relation to your processes or how to use the response templates. Other times it’s because your front-end status mapping isn’t quite matched up to your back-end (asset management and/or CRM) status mapping.

We can help with training sessions or report status mapping, so please speak to your account manager if this is something you’d like to explore.

Want to know more about FixMyStreet or FixMyStreet Pro?

Take a look on our website, or why not request a short demo with our team?

Schedule your one-to-one demo

Request a callback