Highways Fault Reporting Service
An application for comprehensive map-based fault reporting and case management for councils. Citizens can report a variety of highways faults using map or non map options. Cases are created and ranked according to the council’s own business rules, usually differentiating by severity.
- Citizens can report a variety of highways faults online
- Mobile version included
- Map shows all faults reported in the selected area
- Functionality to submit photos of the fault
- Acknowledgement of fault report submission
- Citizens can subscribe to a reported fault to receive updates
- Anonymous report submission option
- Prioritising and routing faults according to council’s categories
- Includes case management system or integrates with the council’s own
- Comprehensive list of faults
- Improves the accuracy of faults reported
- Reduces number of phone calls to the customer service desk
- Integrates with the council's asset management system
- Filters out issues not addressed by the council
- Targets limited resources at the highest priority faults
- Enables the council to change their fault management approach
- Reduces the number of duplicate issues reported
- Open standards compliant to allow for data transfer between services
- Intelligent analysis drives a customisable workflow
- Provides clear communication of progress to the reporter
£900 to £4000 per licence per month
- Education pricing available
- Free trial available
- Pricing document
- Skills Framework for the Information Age rate card
- Service definition document
- Terms and conditions
0330 124 2020
|Software add-on or extension||No|
|Cloud deployment model||Public cloud|
|Email or online ticketing support||Email or online ticketing|
|Support response times||Every issue raised by a client or our internal monitoring is assessed by our triage team for severity and priority. The severity specifies the impact of the issue whilst the priority states the urgency of resolving it. Each issue is also assigned a type ranging from support issue to bug to new feature request. The most common target fix times are 1 hour, 2 hours, 24 hours, 1 working day or 5 working days. The response time varies with the fix time.|
|User can manage status and priority of support tickets||Yes|
|Online ticketing support accessibility||WCAG 2.1 AA or EN 301 549|
|Phone support availability||9 to 5 (UK time), Monday to Friday|
|Web chat support||Yes, at an extra cost|
|Web chat support availability||9 to 5 (UK time), Monday to Friday|
|Web chat support accessibility standard||WCAG 2.1 AA or EN 301 549|
|Web chat accessibility testing||We use a web chat service that performs all testing for assistive technology users for us.|
|Onsite support||Yes, at extra cost|
Every issue raised by a client or our internal monitoring is assessed by our triage team for severity and priority. The severity specifies the impact of the issue whilst the priority states the urgency of resolving it. Each issue is also assigned a type ranging from support issue to bug to new feature request.
The most common target fix times are 1 hour, 2 hours, 24 hours, 1 working day or 5 working days. Other fixes will be based around an agreed plan.
Although clients can purchase additional support if required we do not believe that this will be a standard scenario as the default support should be sufficient.
For every product we have a member of our team designated as product manager and lead developer. Each client will also have an assigned account manager who will endeavour to understand their circumstances and work with them to resolve support issues.
Any issue that is raised that is above a certain level or priority or severity will immediately be escalated to the product manager and lead developer as well as any account managers that are impacted. Further escalation will be possible to the development manager and operations director.
|Support available to third parties||Yes|
Onboarding and offboarding
We have two different targets for our onboarding process.
Firstly, the customer's IT department where we provide system documentation, technical guides and guidance to enable the technical implementation of the service. This can be extended to more detailed collaboration and onsite training if required.
Secondly, the focus is on the individual service itself. For these we provide online training guides, full user documentation, train the trainer sessions and configuration training sessions. These can be extended to onsite training if required.
We would normally expect to have detailed conversations with the client during the onboarding process to fully understand their business process, the implementation they're trying to perform and any nuances there are to their service.
This is agreed with the client to provide the most appropriate experience to them.
|End-of-contract data extraction||All the data from the system is accessible via the APIs for the whole duration of the contract. Moreover, at the end of the contract, a bulk export of all the data can be provided.|
The end of contract process will depend on whether the council is replacing the system or simply removing the service.
If they are removing the service then we will work with the council to close the service down, extract all of the data into a final archive and provide that to the council for retention.
If it is to migrate to another provider then once the council has selected a change over date then we will work with them to provide an extract of the data on that date for import into the new system.
Using the service
|Web browser interface||Yes|
|Application to install||No|
|Designed for use on mobile devices||Yes|
|Differences between the mobile and desktop service||
All elements of the service can be accessed and used on a mobile device. This is done using both responsive and adaptive design depending on the circumstances.
Some clients might also choose to install an Android, Windows mobile or iOS application to interact with the service but this is not required.
|What users can and can't do using the API||All the data stored in the system can be access through the API. Moreover, all the actions that can be invoked through the user interfaces can also be triggered via the API. This allows the client to freely integrate the product with any other system that would benefit from such integration (e.g. CRM systems, mobile applications, financial transaction systems, etc).|
|API documentation formats||
|API sandbox or test environment||Yes|
|Description of customisation||
There are three different types of customisation.
Firstly, the application can be integrated with the customers existing systems, such as CRM; this is done by Athium developers in collaboration with the customers' IT specialists. Some of this has already been done and can be offered out of the box with just configuration required.
Secondly, the service can be customised in conjunction with the buyer to provide additional features or appearances. This can be done either by Athium or by the customer.
Finally, the service is set up to be configured by the buyer. It is expected that the customer (together with Athium if required) will insert their own data that will drive what services the customer provides, what data they collect and how they interact with their customers. This can be done through the interface provided.
|Independence of resources||
This service is hosted on public cloud services with aggressive horizontal scaling configuration to ensure that the system always has sufficient resources to deliver the service. This is both for the specific user as well as across users.
This is a guarantee we can provide and offer additional options around dedicated hardware if required.
|Service usage metrics||Yes|
Full analytics can be provided using Google analytics or Piwik analytics.
Additionally every interaction with the system is recorded, whether by the citizen or council user. This can be returned to the council in a variety of standard reports as well as custom ones if required.
These will tend to include financial reports, technical reports, business management reports and service focused reports,
|Supplier type||Not a reseller|
|Staff security clearance||Other security clearance|
|Government security clearance||Up to Security Clearance (SC)|
|Knowledge of data storage and processing locations||Yes|
|Data storage and processing locations||United Kingdom|
|User control over data storage and processing locations||No|
|Datacentre security standards||Managed by a third party|
|Penetration testing frequency||At least once a year|
|Penetration testing approach||‘IT Health Check’ performed by a CHECK service provider|
|Protecting data at rest||
|Data sanitisation process||Yes|
|Data sanitisation type||
|Equipment disposal approach||A third-party destruction service|
Data importing and exporting
|Data export approach||Data can be exported from the system using both the user interface (CSV and PDF formats), as well as using the REST APIs (JSON and XML format).|
|Data export formats||
|Other data export formats||
|Data import formats||
|Other data import formats||
|Data protection between buyer and supplier networks||
|Data protection within supplier network||
Availability and resilience
Our SLA guarantees 99.9% availability with specific exceptions (including those that mirror Amazon Web Services).
There are service credits available for any outages beyond this. There are also clearly defined maintenance windows.
|Approach to resilience||Full details are available on request but the solution is designed to both be able to be resilient and to recover quickly. The full solution uses multiple availability zones and more than one public cloud provider.|
Outages are reported in real time using a combination of techniques depending on the severity of the incident and the amount of our infrastructure that has been impacted. For the worst case scenario we have a third party dashboard service together with SMS messages to key contacts at each customer.
For less server outages we have a combination of our own dashboard, queries to the APIs, information within the system itself and email alerts.
These will be followed up with detailed analyses within our issues management system and the customer dashboard.
Identity and authentication
|User authentication needed||Yes|
|Other user authentication||This service is delivered to a number of different user types, from the citizen interacting with it (who doesn't have to use a username or password at all) to the customer's IT expert or third party who have access to the data via the API's. There are therefore a wide range of methods to access it (and that can be configured with the customer) with increasing levels of security being required depending on the type of system and data access that a user has. Full security can be provided using a combination of keys, VPN and multi factor authentication.|
|Access restrictions in management interfaces and support channels||
When accessing via the management interface or the support channels a user is still accessing using their user permissions. Other than during defined on boarding and leaving processes working with us all interactions within the system are done using a user with clearly defined permissions.
These permissions can be supplemented with smart checks (related to our protective monitoring) which can allow a user to have access to any individual set of data but flag up when it appears as if an unusual number of individual sets are being accessed.
Full monitoring of these users also occurs, as with other users.
|Access restriction testing frequency||At least once a year|
|Management access authentication||
|Description of management access authentication||Full security can be provided using a combination of keys, VPN and multi factor authentication. In addition to other access methods there is some access via SSH shells. These are secured with SSH keys.|
Audit information for users
|Access to user activity audit information||Users have access to real-time audit information|
|How long user audit data is stored for||User-defined|
|Access to supplier activity audit information||Users have access to real-time audit information|
|How long supplier audit data is stored for||At least 12 months|
|How long system logs are stored for||At least 12 months|
Standards and certifications
|ISO/IEC 27001 certification||No|
|ISO 28000:2007 certification||No|
|CSA STAR certification||No|
|Other security certifications||No|
|Named board-level person responsible for service security||Yes|
|Security governance certified||No|
|Security governance approach||
Our physical and infrastructure security is provided by the cloud providers that we use.
Our focus is therefore on the security of the applications and the data within those applications and we follow the NCSC principle for Governance framework.
We use the ITIL security management practices as well as other industry best practices. Our software has been developed in line with OWASP recommendations and best practices.
On a day to day basis the focus is on controlling access to the data within our systems, ensuring access is limited, proportionate and appropriate.
This can be tailored with the customer where required.
|Information security policies and processes||
Our information security policy is owned by the Managing Director and is reported upon at board level.
This includes a core policy document that sets out the purpose, scope and principles of the policy together with compliance, discipline and incident management procedures. It also states who owns the responsibilities and when the document should be reassessed.
This is then supplemented by a number of other documents that address individual areas, for example access control.
These documents have been built up over a number of years working in both the public and private sector with organisations that have either extremely high profile data, extremely sensitive data or sometimes both.
This is a key area for us as an organisation and is reflected by the amount of attention it receives and the fact that these standards are applied across all of our work both in the UK and beyond.
These documents can be discussed with any customer during the onboarding process and any specific issues that customer has can be addressed.
|Configuration and change management standard||Supplier-defined controls|
|Configuration and change management approach||
We follow the ITIL recommendations (based on ISO 27001) for our change management processes.
Before any changes are made to production services they have to have been promoted through both the test and QA environments where they have undergone rigorous testing for functionality, regression, data integrity and security amongst other elements. These tests are performed using both automatic and manual testing tools.
A change is then raised and logged within our change management system. This change is then tested, as is the backout, before it is performed by script at an agreed point on the production system.
|Vulnerability management type||Supplier-defined controls|
|Vulnerability management approach||
Our vulnerability management is a multi layered process that addresses threats at a wide range of levels. Each component within the system is tracked and added to a threat matrix together with the source for information about that component (whether internal or external e.g. Mitre's CVE list).
Although we are prepared to react to some vulnerabilities in advance we assess our core lists on a daily basis. We also look at routine patching on a weekly basis.
Once we understand all the potential vulnerabilities they are patched in the most appropriate timeframe, ranging from minutes up to a few weeks.
|Protective monitoring type||Supplier-defined controls|
|Protective monitoring approach||
We use both third party services and our own tools to identify potential compromises. Once we have identified a potential compromise then the mitigation depends on what that could be.
Some responses are automatic and immediate (e.g. a simple attack from one or more IP addresses on a login page) whilst others require manual intervention and potential discussion with a client (e.g. an attack from a client network).
Even when the user is in the system our audit tools will ensure that incidents are spotted and addressed.
As part of the onboarding process the client would work through these scenarios.
|Incident management type||Supplier-defined controls|
|Incident management approach||
We follow ITIL best practice when dealing with incidents, as well as considering the NCSC guidance principles.
We use our issues tracker and knowledge base to deal with the majority of incidents, and a combination of automatic and manually driver responses that deal with those events.
Other incidents will be reported by a user (or picked up by our monitoring system) and added to our issues tracker. Management of the incident will then occur within that issue to ensure that it is fully recorded and assessed afterwards to see if it could have been avoided.
|Approach to secure software development best practice||Conforms to a recognised standard, but self-assessed|
Public sector networks
|Connection to public sector networks||No|
|Price||£900 to £4000 per licence per month|
|Discount for educational organisations||Yes|
|Free trial available||Yes|
|Description of free trial||
A full trial version can be setup with the potential client for them to be able to assess the merits of the software.
To save the customer having to enter all of their own information it is setup with a default configuration.