One of FixMyStreet Pro’s key features is its ability to enable councils to automatically keep residents informed on the status of their reports as they progress.
Status updates are important because, according to research we carried out with YouGov last year, receiving updates in response to a report is one of the most important things citizens expect from a reporting service. It’s also the thing that would most effectively stop them from chasing updates via other channels, which drives up the cost of reports for councils.
Templates for report status updates can be created and managed directly from the FixMyStreet Pro administration dashboard, or they can be pulled from an integrated case management system used by the council. Each time a report’s status is changed, an update will be sent to the report-maker and to anyone else subscribed to the report.
Common status updates relate to scenarios such as, but not limited to:
There is no limit to the number of templates you can create within FixMyStreet Pro, and they can be edited or deleted whenever necessary by staff, enabling you to quickly address any seasonal or situational changes.
So that’s what status updates are, but what makes a good one?
For updates to be effective in reducing avoidable follow-up contact and failure demand, they need to accurately reflect what’s happening with the report. That means as well as explaining what you are going to do about a problem, you also need to explain if you are not able to do anything and why that is.
Honest and open updates help you to educate residents on your intervention criteria, manage expectations during periods of high demand and discourage despondency and disengagement even if a problem cannot be fixed.
Make it relevant
Tailor your updates to the different types of problems residents are able to report to you so that they know what to expect once a report has been submitted. It helps to outline the timeframe within which you will respond to different problems, or explain why a particular problem may be higher or lower on your priority list.
Use accessible language
Take care to ensure your updates are understandable to everyone who may receive them. Avoid using technical jargon that only makes sense to members of staff, or codes from your integrated systems that won’t mean anything to residents.
Additionally, consider using the local words for things where appropriate to apply an extra level of accessibility to the language within your updates.
Signpost to more information
While it’s good to provide detail in your updates, it’s also important to keep them concise. Put the essential information in the update and include a link to another web page or document where the recipient can find more information if they want to.
Signposting can also be used to direct residents to emergency contact details, additional services and even customer satisfaction surveys.
Don’t create a dead end
If the update you provide is to inform the report-maker that the issue is not your responsibility, try to provide information on who is responsible, or assistance on where they might be able to find this out for themselves. This will help to reduce the likelihood of the report-maker getting back in touch.
Acknowledge the value of the report
Finally, don’t forget to thank the resident for their report. Research shows that the main reason why residents report problems is because they want to improve the place where they live. Acknowledging this in your responses helps to improve the experience for residents and encourages continued commitment to helping you care for your area. This is particularly important in instances where the problem cannot be fixed.
Alongside transparent status updates sent to residents after they have made a report, FixMyStreet Pro equips councils with a few useful ways to manage expectations beforehand, too.
One of these is its site-wide messaging functionality, which displays a message from the council to report-makers in multiple places to inform them of, for example, expected delays in responses due to increased seasonal demand.
Councils can also schedule these messages to display only during certain times, such as out of hours or during bank holidays.
Another way FixMyStreet Pro helps with this is by enabling councils to assign in-category messages which display during the report workflow. These can be used in a number of ways, such as to help educate on intervention criteria to ensure the report can be actioned or divert emergencies.
For more information about FixMyStreet Pro and its features, get in touch with us.
Image: Reuben Juarez
Our mission here at SocietyWorks is to help local authorities and other public sector organisations better serve citizens through effective and intuitive digital solutions. That’s a big remit, and a vast user base with a wide range of accessibility requirements. So how do we accommodate everyone? Bekki Leaver, our Head of Product, wrote this blog post to explain.
Being suppliers of public services we have a responsibility to ensure our tools and solutions are accessible to the broadest audiences possible. This is both a legal and moral obligation, and something we take seriously.
As Head of Product, it’s my job to ensure our tools are built to meet, if not exceed the Web Content Accessibility Guidelines (WCAG) AA standards. Here’s what this means in practice, and some advice for local authorities and any other public sector bodies who provide public-facing digital services.
WCAG is the international standard for web accessibility created by the World Wide Web Consortium (W3C). Within WCAG there are four principles for web accessibility. Each of these has conditions that need to be met to achieve a particular standard. These very sensible principles are:
The UK Government expects all public services to meet the WCAG 2.1 AA accessibility standard, both for citizens and staff users.
SocietyWorks is heavily influenced by the GOV.UK Service Manual when it comes to designing or improving our tools and products. If you’re familiar with this, you’ll know that this means everything starts with needs: both user needs and the service needs.
We also consider the context of use: where, when and how will the service be accessed? In addition to considering any permanent physical impairments that may impact the way a service needs to be used, we think about situational and temporary impairments too.
For example, making button targets larger for people using a service one handed due to holding a baby, having a broken arm or having bad arthritis, or improving the contrast for use of a service in poor lighting environments or by users suffering with an eye injury or partial blindness.
Our developers use semantic HTML – that’s using HTML elements for their intended purposes to build the front end of our tools. This lets browsers know what the element is and how it should behave, which makes it easier for keyboard navigation and for other assistive technologies to correctly render a website for their users.
When we’ve got something designed and built, we test it. We use a combination of automated and manual testing to make sure the technology meets the WCAG standards, which includes, for example, checking we can tab through elements and that screen readers behave as expected.
Knowing that no two councils or public authorities are the same, we build our digital solutions to be flexible enough to adapt to each of our clients’ individual needs. This is a great strength, but it can occasionally pose a challenge when those needs have an impact on the accessibility of the solution.
For example, we are sometimes asked to apply brand colours which have a poor contrast ratio or adjust forms to match a third party integration’s workflow in a way that makes them more difficult to use for users with certain needs.
When these instances occur, we do our best to help mitigate any negative effects on the accessibility of the services we provide. Here are some of the top tips I offer to clients when it comes to accessibility.
Firstly, I would always highly recommend commissioning an accessibility audit with a reputable auditor, such as RNIB, but you can find other providers through the Digital Marketplace. This will give you complete peace of mind that everything is working as it should for everyone who needs to use the service.
Secondly, consider your brand colours. Colour is a regular issue with accessibility, usually caused by text and background colours not having a high enough contrast.
Lastly, ensure the language you’re using is appropriate. Whether you’re writing form field labels or creating explanatory text, use language your users will understand. For example, avoid using system-related terminology that residents may not understand, but do consider using the local names for things. You can check the readability of your content using online tools like readable.com.
Creating and maintaining an accessible and inclusive service is an ongoing task. Criteria and expectations change. Keeping these goals in mind from the beginning certainly helps, as does remembering that designing services to be inclusive makes them better for everyone.
If you’re interested in learning more, check out these resources:
Or, if you have any questions about making digital services accessible to everyone, get in touch with us here.
Featured image – Daniel Ali on Unsplash
Illustration – Sherm for Disabled And Here
The use of disclosure logs in relation to freedom of information (FOI) requests under the Freedom of Information Act 2000 is recommended for principal local authorities by the Information Commissioner’s Office (ICO).
There are a number of reasons for this advice, the main one being because well-maintained disclosure logs make it much easier for citizens to access information that is already available. This, in turn, saves local authorities time and effort spent on responding to duplicate requests, or requests for information that have already been published elsewhere.
With an easy to navigate disclosure log in place, citizens should be able to browse or search for already published information. If a request is made for information that already exists in the public realm, information officers can quickly apply the Section 21 exemption in response and simply signpost requesters to the information they seek.
Disclosure logs also represent an opportunity for citizens to learn what a successful request for information looks like. The more responses published in the log, the more useful it becomes, with today’s responses answering tomorrow’s requests.
In certain cases, some of the software used by local authorities may even allow information officers to manually enter topical information into the disclosure log in anticipation of potential future FOI requests, giving them the opportunity to work proactively and publish information before it is requested.
In spite of being recommended by the ICO, and in spite of the usefulness they represent, research in 2019 by our parent charity, mySociety, shows the use of disclosure logs by local authorities is still inconsistent.
There is a distinct lack of established sector-wide process for setting up a disclosure log, technology is rarely designed to meet the needs of information officers or FOI requesters, and there is a huge disparity in inter-authority knowledge sharing and training around this topic.
Of course, local authorities are under significant pressure to reduce costs, create efficiencies and contribute towards Net Zero targets, among many other responsibilities. Understandably then, while the long term benefits for councils’ information officers and for citizens are desirable, the short term effort required to establish an easy-to-maintain disclosure log may be considered a relatively low priority.
However, with fifteen years’ experience working in freedom of information, and over a decade of experience providing services to the local government sector, we have seen firsthand how disclosure logs, when used to their full potential, can save significant time and effort for local authorities in the context of managing scarce resources and competing priorities.
In collaboration with the FOI experts on mySociety’s Transparency team, who run the well-used WhatDoTheyKnow request service, and expert FOI consultant Martin Rosenbaum, who was the BBC’s leading specialist in using freedom of information for journalistic purposes, we have put together a best practice guide to using disclosure logs for local authorities.
Download Disclosure logs: a best practice guide for local authorities to discover:
You can view more research and guidance for local authorities and the public sector on our website: https://www.societyworks.org/research-and-guidance/
Image: Iñaki del Olmo
This week was Public Sector Insight Week 2023 – an annual event dedicated to bringing together government and businesses to help each other use digital more effectively.
As part of the event, our managing director Angela Dixon delivered a best practice session on closing the feedback loop between local authorities and residents.
Closed feedback loops are essential to building trust, managing expectations and increasing efficiency.
In our twenty years of experience working within the public sector, we have seen how difficult it can be for councils to keep feedback loops closed, with over-stretched budgets, the transient nature of local authority staffing and a multitude of different systems used for dealing with different issues.
Angela spoke about the common problems local authorities in particular face when feedback loops are broken, how to fix them effectively and shared some of our lessons learned from our experience of helping to bridge the gap between citizens and the public sector with innovative open-source digital solutions.
If you couldn’t make it to Angela’s talk, but you are interested to hear what she had to say, you can watch the full session on YouTube.
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.
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.
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])
Report has been reviewed and action has been scheduled
Report is awaiting internal review or re-categorisation
Report’s resolution is in progress/action is being carried out
Report is under investigation
Report’s resolution has been planned/scheduled as part of a wider maintenance project
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)
Report is about an issue that’s already been reported
Report has been referred to another team within the council/public body
Report is about an issue that is the responsibility of another council/public body/private organisation
Report’s issue cannot be fixed/issue does not meet intervention criteria
Report’s issue has been fixed
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.
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.
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.