Recent Cases

Each time you select an application within the work items menu, the browser uses cookies and will record this entry and save it to the Recent sidebar. This function enables you to quickly go back to the applications when working in batches. Once you have signed off, the Recent Cases start afresh. See the most recent cases as illustrated below:

This function is used to manually create a new organisation in the CMS.

Vehicles can also be added at this stage

Clicking on the Validate button will invoke the integration call to the DVLA to check the vehicle details.

Local Search

This function is used to search for Cases within the CMS.

You will be presented with the Local Search screen as illustrated below:

You can perform a basic search using the following:

• Badge/Pass/Card Number

• Case reference number

• Last name

You can also search using the advanced function.

Cases can be searched using the following fields:

• First Name

• Last name

• DOB

• Email

You can use a wildcard feature within each search field. The wildcard is denoted by %. For example, if you want to find all cases with first 3 letters of the last name “bowman” you would enter “bow%” into the last name search box field. Wildcard also works at the start of the last name

The seach returns the following basic data:

Clicking on an individual Customer record will display the Customer record view.

The customer record displays all badges/passes/cards along with their current Status (Blue Badge only), these are:

• Ordered

• Issued

• Cancelled

• Replaced

Also shown are all cases associated with the Customer.

For Blue Badge only, clicking on a badge, displays the badge record data from the DfT National database :

The following illustrates the badge record data:

The Timeline tab contains the entries made by selecting outcomes within the workflow. The entries are preconfigured in the system to reflect the outcome status selected throughout the workflow.

The timeline is also added to whenever your Customer accesses the self-serve portal.

Timelines can be used for a quick update on the progress on the application/workflow. Timeline entries cannot be edited.

The 'Replacements' workflow is created automatically if a request for a replacement has been received either through the DfT for a Blue Badge, or manually if a paper application is received.

If a badge number has been supplied by the applicant, the system will attempt to link this ‘Replacement’ workflow with the correct badge holder in the CMS.

So we try our best to link the correct replacement request with the correct citizen in the CMS. To achieve this, we perform further validation, by checking the following:

If there IS a badge number entered:

• if the date of birth and last name match with a case in the CMS that has the same badge number as was entered by the applicant, we link the two

OTHERWISE

• we create a different case

If there IS NO badge number entered:

• if the NINO and date of birth match with anyone in the CMS, we link the two,

  OR IF NOT

• if the date of birth, last name and postcode match with anyone in the CMS we link the two,

  OTHERWISE

• we create a different case.

The Replacement workflow commences with the stage 'Replacement Request'.

The 'Work Items' Tab, when opened, will show all new 'Replacement' applications received. It will also show to which stage existing workflows have been progressed.

The 'Replacement' application is progressed depending upon the decision that is made at a specific stage. For example at the 'Replacement Request' stage, there are a number of 'outcomes' depending upon reviewing the submitted Replacement application:

Subsequent stages are dependent upon the choice of outcome from the option above. In our example I have selected 'Badge is Stolen'. When selected, further questions are asked which can be mandatory or not. In this case any Notes relating to the theft and a Crime Reference Number are mandatory before this workflow can be progressed:

The Fast Track workflow is either started by an outcome from a new Application, or can be started manually.

If a new application is received, and a decision made to Fast Track it, then this is one of the options available from the 'Initial Checks screen:

If you select this option, this workflow completes at this stage and automatically starts the 'Fast Track' workflow. By pressing the WORKFLOW tab at the top you will see that the new 'Fast Track' workflow has been automatically started:

If you select this workflow, or if you have started the workflow manually, the following screen appears:

The only entry required at this stage is notes detailing the reason why a decision has been made to fast track this application. This is a mandatory field and of course is very relevant to DS1500 cases.

Once 'Continue' is pressed the following Badge/Card/Pass details are required. For Blue Badge, this will generate a request to the DfT for a Badge to be Fast Tracked.

For Freedom Pass and Taxi Card, it is data that will be needed to pass to London Councils when an API link is made available.

'Appeals' are accepted in two ways.

Firstly, this workflow can be started manually

Secondly, at a point in the Application process after a Refusal, the applicant has a right to Appeal. If this is the case the Appeal process will be started automatically if within the Blue Badge Application process as a new workflow. It can only be started manually if a Freedom Pass or Taxi Card Appeal is received.

1. If starting manually the following first screen appears:

This allows you to upload the communication document whether that be by e-mail or letter and to send a communication in return - either e-mail or letter - to advise the sender that you have received the Appeal.

Like other workflows, once 'Continue' is pressed the next stage of the workflow is presented. In this case there are now two options available from this stage:

At the point of refusal within a new application the workflow stays at a holding stage in case the applicant decides to appeal as shown in the following screen:

1. The Appeal workflow can start automatically (within the Blue Badge Application only). In the application workflow, the applicant would have received an e-mail or a letter detailing the reason for Refusal, but has the right to appeal that decision. If they do,then selecting the option 'Appeal Received', the application workflow completes at this stage and automatically starts the 'Appeals' workflow. By pressing the WORKFLOW tab at the top you will see that the new 'Appeals' workflow has been automatically started:

Within the Blue Badge Appeal workflow only (and then only if the Appeal has been upheld) there are extra stages. These are to request payment, which on receipt through the self-serve, will automatically progress the Workflow to the DfT for printing and distribution.

The Stage Targets are added to the Workflow Stages in the Workflow configuration screen:

Security groups can only be accessed by those that have the correct permissions. The first user created by ieg4 in your organisation will have access to Security Groups.

Once you have signed-on to the configuration system, the following screen will appear:

By clicking on 'Security groups', any existing groups will be displayed:

Within the Case management system there are 5 levels of group security

• Application permissions - allows access to the system from sign-on

• Administration permissions - allows access to the configuration system

• Case permissions - allows access to areas and actions within the Case

• Reporting permissions - allows access to the Reportal

To update an existing group, by clicking on one of the groups the following screen will appear:

Clicking on 'Manage Permissions' gives you access to the full permissions screen.

You are then able to amend any of the permissions for this Permissions group, and press Save.

To create a Security Group, click on the 'Create' button and the following screen will appear:

Give the group a name and press 'Create'. The screen that appears will be the top level 'Security Groups' screen allowing you click on the group and amend the permissions that you wish (the new group will have no permissions set until you have updated it).

Workflow Security Group Settings

A powerful aspect of the Concessionary Travel system is the ability to apply Security Group controls to the Workflow Stages. This enables the Authority to control which groups of users see and are able to progress the different stages of the application process.

The Search results visibility section shows which Security Groups are able to see the Workflow Stage in the Work Items screen.

Click on an Outcome and that will show Outcome Settings which includes the Destination stage if that Outcome

Components and Actions enables the content of the page and any system actions for the Outcome selected to be configured. This part of the configuration is maintained by IEG4.

Click on Advanced Settings to show the Security Groups that are able to select each Outcome

Users can only be added by those who have the right permissions to do so.

Once you have signed-on to the configuration system, the following screen will appear:

By clicking on 'Users', any existing Users will be displayed:

Pressing the 'Create' Button, the following screen will appear:

You can now enter the relevant information:

By pressing ‘Create’, the system will create the User and automatically send an e-mail to both the Administrator of the Organisation (for Audit purposes) and to the new User. The user will have to create a new password on first use, or if a User already has a OneVu account (assuming the Organisation uses our OneVu system), then they will be able to sign-on using their existing OneVu password.

The following screen will then appear:

The User will now be created, but needs the addition of security group(s) which gives them certain permissions as to what they can access (See Security Groups below).

Having approved and issued a Badge within the workflow, the system automatically sends the required data to the DfT through an API. This function shows the integration actions that exist between the CMS and the DfT.

The Process date is when the individual item will be processed. This will typically be 15 mins ahead of when the item was added to the queue.

The Status of the badge is a DfT status which will change to 'Success' if it has printed successfully.

If the system detects a duplicate message for the same customer within the last 90 days it will be added in a ‘Paused’ state and require a manual intervention to ‘Un-pause’ the items.

The search facility enables you to select the Case Reference to view an individual application.

Also, by clicking on the Application Reference, a further screen will be displayed that shows the data that is being passed to the DfT through the API:

Integration functions

Pause

When a badge is queued it will wait until the automatic processing pushes the request to the DfT site. Whilst the badge is queued you are able to pause the request by clicking on Pause. You can then click Un-pause to place the request back in the queue. This is useful if you notice that some part of the request was incorrect or missing. For example you could go and amend or add a telephone number in the Cases screen and this will then be picked up when the request is un-paused.

Cancel

If you decide that you do not want to request the badge whilst the request is in the queue you can click on Cancel and this will stop the badge from being processed.

Error

If a request status is Error this means that the request has failed when it has been sent to the DfT national site. Click on the request to see the response. A common reason is that the applicant's telephone number is blank or invalid. You can go to the Case and correct this and then from the Integration menu open the request and click Re-queue. The badge request will then be processed again.

Introduction

For Blue Badge, API keys are required to set up Connectors that access the DfT and for GOV.UK Pay or Pay360 and Notify (if used).

We also integrate to Capita Pay360 if this is the Payment system that you use. The API key needs to be requested from Capita to enable us to do that.

Mandatory DfT API Connectors - the API key needs to be requested from the DfT during the implementation (both Test and Live).

Recent Cases

Create a person

Local Search

National Search

Case Import

Work Items

Intuitive user interface

Case administration

Dynamic workflows

Export Cases

Notifications

Create a person

This function is used to manually create a new person into CMS. The system will only allow you to create a new person if there is no existing person using the NINO provided.

You will be presented with the ability to add a new person as illustrated below:

Having completed the relevant mandatory information, and pressing Create, the system will then prompt you to create a case linked to the person record.

By pressing on the 'Create case' button you can then begin to update the case with the appropriate application data.

Having completed the r

Having completed the relevant mandatory information, when pressing on 'Create', the system will then prompt you to start uploading any relevant documentation linked to the person record.

If document upload is completed, or if no documents are available for upload, then by clicking on the 'Workflow' Tab a new screen appears allowing you to create a new workflow.

By clicking on 'New Workflow' a further screen appears allowing you to click on 'Choose Workflow' which will gives a dropdown menu which enables you to chose the workflow manaully for the type of application on which you are working.

High Level Fundamentals

The key fundamentals of the design of Digital Concessionary Travel platform are:

Case management that’s smart and automated

• Streamlines progress tracking of all cases from application to order

Intuitive user interface

• A carefully designed, easy to navigate, user interface that decreases on-boarding time and effectively minimises staff training costs

Dynamic workflows

• Powerful workflows enable standardisation and automation of processes maximising efficiency.

• These include for Blue Badge:

  • Applications

  • Renewals

Timeline

• Recording all application & workflow interactions & note facility for quick customer updates

Integrated auto-generated communications

• Significantly reduce time spent on unnecessary internal & external correspondence by automatically triggering communication

GOV.UK Pay (Blue Badge only) & GOV.UK Notify

• Full integration with GOV.UK Pay enabling payments / refunds to happen automatically (Blue Badge only). GOV.UK Notify can be used to communicate with applicants via SMS / Letter / Email throughout the entire process

Full document repository

• Upon application you can ask your customers to upload documents locally so your council can include evidence & other additional documentation required for assessment approval. All documents are linked to cases and customer records

Self Service Platform 

• To reduce customer/Council interaction there is a self-service platform for customers to:

  • check application status

  • upload evidence

  • make payments using GOV.UK Pay (Blue Badge only)

Advanced reporting and audit

• Analyse the entire application process to effectively plan and manage all the Concessionary Travel services. Advanced operational audit and reporting adds powerful insight into day to day operations

A case is a direct descendent to a customer record, and a customer can have many cases.

A case has a type associated with it, such as Application, Renewal, Replacement. It also has a source, such as Online, Phone or In Person.

Data is separated into tabs across the top, which can be restricted by permissions where required. (For permissions see 'Setting up the System'):

IEG4's Digital Concessionary Travel platform is an intelligent, customisable and, crucially, digital service that enables councils to manage all applications from submission to badge production (Badge production currently only applies to Blue Badges only). It has been designed to drive maximum efficiency through the streamlining and automation of processes meaning faster decisions for customers and more efficient use of officer time.

Key priorities behind the design that continue to inform the development are:

• Effective Dynamic Workflow

• Invisible Integration

• Actionable insight that aids planning

• Channel shift to digital

To create the platform the following products are all designed to work together seamlessly:

• Case Management System

• Self-Serve portal

• Reporting Suite: Reportal

The Concessionary Travel Platform has benifited a wide range of councils by:

• streamlining work progress by tracking all cases from application to order

• being intuitive with a user interface which provides quick view current status

• showing an application summary view, with links to previous badges and highlighted notes

• viewing a timeline tab which records all application & workflow interactions

This guide will walk you through the functionality provided within the Concessionary Travel platform areas specifically, including how to set up, configure and manage the service ongoing.

This screen contains information held within, or applied to, the Case from an on-line entry only. For Blue Badge this is the exact information that has been entered by your Customers into the DfT online application.

For Freedom Pass and Taxi Cards it is a .pdf version of their application only, and the following breakdown is not available.

Contact details: This is a repeat of the Summary data, and contains the basic core date held at the case level: name, address, phone, email.

DfT payment: this shows whether the applicant has paid through the DfT on-line at the time of the their application.

Eligibility: The applicants reason behind why they are making the application. This is detemined by the DfT reasons. You can view all the information that the applicant provides when completing their application through the DfT.

Person: The applicants NINO.

Work Items

This function is the place where most of you will start the Concessionary Travel process. This screen shows all applications, renewals, appeals and replacements that have arrived via the DfT(for Blue Badge) and an on-line application form (for Freedom Pass and Taxi Cards) into the CMS, along with any workflows that you have created from a paper application. A work item is a single stage in a workflow.

By default, the system will filter the list to only show workflows that are active. You can view completed workflows by choosing the “Completed only” toggle.

The Work item table displays applications that are currently being worked upon and show the following information:

A carefully designed, easy to navigate user interface that decreases on-boarding time and effectively minimises staff training costs. This is achieved by designing the workflows to represent your working practices. Although standard workflows are in existance, small changes to these to reflect your operation can be made. For instance, you may perform Desktop Assessments but not face-to face assessments, so we can tweek the workflow to reflect this difference. There are a number of other User customisations that can be made - please see the Item on 'Setting up the system'

Summary contains information held within or applied to the Case.

A recent feature has been added that now displays the current Badge Number of the applicant if they are matched with the information available on the DfT database. This is done as a quick check to prevent the possible fraudulent request for more than one badge. If more than one Badge exists then the message 'multiple badge records found' is displayed in place of the Badge number. Finally, if no Badge exists, the message 'no badge record exists' is displayed.

Similar cases: is where a case is found on the CMS that has matching surname, NINO, date of birth. This is used as a way of enabling you to check that your customer doesn't already have a Case and therefore stopping to some degree the possibility of fraud by having multiple badges/passes.

Person: The applicants NINO.

Contact details: This shows the basic core date held at the case level: name, address, phone, email.

Case: Case type such as Application, Renewal, Replacement. It also has a source, such as Online, Phone or In Person.

Tags: Self Service Tags that are displayed via the Self-service portal to the citizen, that also shows you the current status of the case. This is important if some of your users of the system can only view certain areas of the CMS. For instance, call centre staff who can be restricted to 'view only' instances and add notes. (See Permission groups in 'Setting up the System')

Access History: System users who have accessed the case, noting date & time.

Quick Actions: Within this tab, Quick Actions can be configured to start a specific workflow and link it to the case. For example where a call-handler is logging a query and any relevant information in real-time, before closing down the call, they can start a 'Manager Escalation' workflow, which prompts the manager to look at the case as a result of the call (Blue Badge only).

National Search & Case Import

This function is applicable to Blue Badges only and is used to search for Badges within the DfT National Database.

Search restrictions are dictated by the DfT API’s. The current search functions include:

• Badge Number

• Name

• Postcode

• NINO

You will be presented with the National Search screen as illustrated below:

It is possible to use multiple search functions. By using these, if an individual search is found, then the selection screen will not show, but the badge details screen will be returned.

By clicking on the Badge number, full details about the holder will be displayed:

Search results are retained when navigating away from this screen, and the last refreshed time is displayed alongside a link to Refresh the results.

Should the Badge being displayed originate from another Authority, then the Customer details can be imported using the ‘Import into local system’ facility at the bottom of the screen.

This will seamlessly create a person record, and if required, a Case using the address and contact details from the Badge itself.

The Tag function is used through the system to highlight statuses, control & restrict workflow progression, classify document types, update the Self-service portal and aid reporting. Tags can be applied to Documents, Case, and Customer records.

Tags are a system function, and as such can only be added and/or changed by ieg4. The reasoning behind this is mainly due to the level of Reporting. Tags are an integral part of the reporting suite as they are used as delimeters to drill down within the data.

Tags are essential for identifying different documents and are particularly useful when an Expert Assessor wishes to review the documents as part of their assessment process. By tagging the documents, they then only need to review those documents that are relevant to their assessment process. As an example the following shows the Tags that can be applied to determine the types of incoming documents:

There are different outcomes within the workflow that automatically apply Tags. For instance when a document is sent to the applicant as a result of an officers decision, these documents can be tagged accordingly:

Another important use of Tags, is restricting progress of the workflow at certain stages because certain actions need to be taken prior to advancing the workflow to the next stage. This is done by the workflow checking that certain Tags have been set prior to continuing. Two examples of this are 'Payment' and 'Photograph'.

In the case of a Blue Badge application, before sending the request to the DfT to print and distribute the badge, the applicant needs to pay the requisite amount (if that is required by your operating procedures), and supply an up-to-date photograph. Without these the DfT will not print the badge. Thus in the workflow, prior to releasing the badge request to the DfT, 'Payment' and 'Photograph' Tags MUST BE set. If they are not, you cannot progress the workflow. For example, when trying to progress the workflow without the Payment Tag being set, the following message appears on the screen:

In the case of a Freedom Pass or Taxi Card applications, before approving the application, the applicant needs to supply an up-to-date photograph. Without this, the workflow will not progress, even though there is currently no API link to the printing and distribution of the Freedom Pass or Taxi card. Thus in the workflow, prior to approving the badge the 'Photograph' Tag MUST BE set. If they are not, you cannot progress the workflow.

A further use of Tags has a highly significant bearing on the progress of the Case for both the applicant and the officer concerned. This is the use of self-service Tags. Self-service and its operation can be found below, but setting self-serivce Tags at certain points in the workflow enables the applicant to view through the self-serve portal, the stage at which the officer is currently progressing the Case.

Promoting a self-serve culture provides empowerment to the customer and means incoming e-mails and calls are reduced . Customers can check the status of their application easily, minimising the need for them to contact you via other routes and giving the customer greater visibility of the process.

Having made your decision to issue the pass/card, sharing required information with the Organisation responsible for printing the Pass, is not currently possible through the use of API's. However, the following information is still required for re-keying into the current application system.

The following screen shows the information that is needed for London Councils Freedom Pass:

The following screen shows the information that is needed for London Councils Taxi Card:

Entitlement: This is a London Councils defined field and is used within to determine the reason for issue. There is a drop-down selection menu for you to chose from:

Photograph: This is a London Councils required field and is used as the picture to be printed on the badge - London Councils cannot print the badge without it. As this is a mandatory field, you need to click on 'Select document'. When selected, the screen will only show those documents that have been tagged as 'Photograph'. Thus the importance of tagging documents correctly:

Pass/Card Order Date: This is a London Councils required field and is used as the start date to be printed on the pass. This is currently set to be one day after the current date. This field is editable by you and can be set in the future. For instance, if you are making a renewal, the current pass may not end for another month, thus the start date can be altered to reflect that.

Pass/Card Expiry Date: This is a London Councils required field and is used as the end date to be printed on the pass. This is initially set to be three years after the start date. If you edit the Pass Order Date, then this field may be edited as well to reflect the mandatory five years. As this field is editable by you it can be set in the future. However, there is validation on this field as under the current legislation, the Expiry Date cannot be greater than five years after the Start Date.

Applicant ID: This is not a mandatory field for London Councils, but is a London Councils defined field and is used as the pass/card reference which is recognised by your Authority and London Councils if any communication is needed with the Customer.

There are other fields that are mandatory for London Councils to enable them to print the pass, such as; address and date of birth. These fields are set automatically from the workflow process.

As described previously, all details that have been entered by the applicant at application stage are shared across platforms through API's and thus can be viewed in the CMS without the need to keep swapping into other systems.

Also, having made your decision to issue the badge, sharing required information with the DfT to print and issue it means passing information back to the DfT.

The following screen shows the information that is required for sharing with the DfT:

Eligibility: This is a DfT defined field and is used within the DfT to determine the reason for issue. There is a drop-down selection menu for you to chose from:

Deliver To: This is a DfT defined field and is used to determine where the badge will be deivered. There are only two options - 'Home address' (default) or 'Your Council'. Some councils were finding that badges were not being received by the applicant, thus delivery to the Council offices ensured the applicant received their badge, as they were rquested to come to the office to pick up their badge and sign for it.

Delivery Option: This is a DfT defined field and is used to determine how the badge will be deivered. There are only two options - 'Standard' (default) or 'Fast Track'. For those badges issued as a result of a terminal illness, fast track is used as the preferred option.

Number of Badges: This is a DfT defined field and is used to determine how many badges will be deivered. The default is 1, as this is the only amount allowed for an individual application. However, Organisations can apply for up to 9 badges for the number of vehicles they use for transporting their residents.

Photograph: This is a DfT required field and is used as the picture to be printed on the badge - the DfT cannot print the badge without it. As this is a mandatory field - although not needed for 'Organisation' badges - you need to click on 'Select document'. When selected, the screen will only show those documents that have been tagged as 'Photograph'. Thus the importance of tagging documents correctly:

Badge Start Date: This is a DfT required field and is used as the start date to be printed on the badge. This is currently set to be one day after the current date. This field is editable by you and can be set in the future. For instance, if you are making a renewal, the current badge may not end for another month, thus the start date can be altered to reflect that.

Badge Expiry Date: This is a DfT required field and is used as the end date to be printed on the badge. This is initially set to be three years after the start date. If you edit the Badge Start Date, then this field may be edited as well to reflect the mandatory three years. As this field is editable by you it can be set in the future. However, there is validation on this field as under the current legislation, the Expiry Date cannot be greater than three years after the Start Date.

There are other fields that are mandatory for the DfT to enable them to print the badge, such as; address; date of birth; whether the applicant will need re-assessing in the future etc. These fields are set automatically from the workflow process.

The 'Application' workflow is created automatically if a request for a new Blue Badge has been received through the DfT (Blue Badge Application), or if a request for a new Freedom Pass or Taxi Card has been received through an online application (Freedom Pass Application/Taxi Card Application). Any of them can also be created manually, if a paper application is received.

It commences with the stage 'Initial Checks'.

The 'Work Items' Tab, when opened, will show all new Applications received. It will also show to which stage existing workflows have been progressed.

The new application is progressed depending upon the decision that is made at a specific stage. For example at the 'Initial Checks' stage, there are a number of 'outcomes' depending upon your reviewing of the documentation.

Subsequent stages are dependent upon the choice of outcome from the option above. In our example I have selected 'In Area - Incomplete Application'. When selected, the following screen appears:

The workflow tab contains all the stages and outcomes linked to the application / workflow type.

There are a number of different Workflows for different aspects of the system. The major workflows for Blue Badge are:

• Blue Badge Application - created automatically if a new application has been received through the DfT. This is the same workflow that is used for Renewals

• Blue Badge Appeals - created automatically if an Appeal is received after a refusal, or can be created manually if an appeal is received by any other method.

Ensuring that all documents relating to the Case are in one place in the CMS, all documents that the applicant has submitted with their application are stored in the document management area within the Case. This is added to whenever a communication is sent to the applicant as a result of an outcome from any of the pre-defined places within the workflow where direct communication with the applicant is needed i.e. in the form of an e-mail, a letter or an SMS text.

Open: Clicking on this opens the individual document so you can decide what type of document it is by adding Tags (see 'Document Tags' below) and, of course, allowing the Expert Assessor to read it and analyse it as part of the assessment process.

File: This is the name of the document. Any documents uploaded by the applicant at the time of application will have the same title 'Customer upload via DfT form' if the application is for a Blue Badge, or 'Other Information' if through the Freedom Pass or Taxi Card applications. What distinguishes the form is the Tags applied to it. (see 'Document Tags' below).

Created on: This is the date on which the document was uploaded

Created by

Powerful workflows enable standardisation and automation of processes maximising efficiency. Includes; Applications, Renewals, Replacements, Appeals, Badge or Application No Longer Needed, Fast Track and Organisations.

Workflow process flow diagrams are available as part of the implementation.

For Blue Badge:

• The 'Blue Badge Application' workflow is created automatically if a request for a new Blue Badge has been received through the DfT, or manually if a paper application is received.

For Freedom Pass:

• The 'Freedom Pass Application' is also created automatically but from a Freedom Pass Application created through an online form.

For Taxi Card:

• The 'Taxi Card Application' is also created automatically but from a Taxi Card Application created through an online form.

'Renewals' are created through the 'Application' workflow

'Blue Badge Replacements' are created automatically if a replacement application has been received through the DfT, or manually if a paper application is received.

'Appeals' are accepted in two ways; and workflow can be started manually, or if at a certain point at the Refusal stage within the Blue Badge Application an appeal is received, then the Appeals workflow is started automatically be the workflow..

For Blue Badges only, a 'Badge is no longer needed', is normally created manually when a resident has passed away or have moved abroad. This is usually only known either through a communication from a relative, or in most Councils, as part of the TUO list, which details names of residents who have passed away.

The Fast Track workflow is either started by an outcome from a new Application, or can be started manually.

Introduction

An installation document is introduced at the initial kick-off stage, which contains all the essential detail required for the set up of the system. The document contains the following:

• Users - name and e-mail address of the staff you require to access the system

• User Groups - Each User is allocated one or many User Groups (User Groups names are pre-populated). These are customisable.

• User Stage Permissions - dictates what stages within the workflow that each User Group can access. These permissions allow the User either access to progress the case, to view the case or both. These are customisable.

• System Permissions - dictates what system permissions are given to User Groups. These are customisable.

• Lists - are the selections available at pre-determined times within the workflow. They are used within the templates to dictate what text is extracted to personalise the e-mails or letters. These are customisable.

• Tags - are allocated to both documents and to certain stages throughout the workflow to determine the stage that has been reached. They are used to inform the applicant at what stage the application has reached when the applicant accesses the self-serve portal. These are used extensively in the reportal as filters and are therefore NOT customisable.

• List of Current Templates - for information only.

• Blue Badge Templates - are the pre-defined textual documents that are used to communicate with the applicant at pre-determined times throughout the workflow. These templates are offered as a basis for those communications. These are customisable.

• Freedom Pass Templates - are the pre-defined textual documents that are used to communicate with the applicant at pre-determined times throughout the workflow. These templates are offered as a basis for those communications. These are customisable.

• Taxi Card Templates - are the pre-defined textual documents that are used to communicate with the applicant at pre-determined times throughout the workflow. These templates are offered as a basis for those communications. These are customisable.

• From e-mail address - this is the e-mail adress and Department Name that you want to be used as the contact information on all communucations sent to the applicant. These are customisable.

• Technical Requirements - these are the protocols that are used as the technical communication between your IT systems and the Microsoft Azure environment on which the system is hosted. For Blue Badge only this contains the API keys that are needed to communicate with the DfT. You will have to ask the DfT for these.

• Workflow Day Targets - these are the target times set at certain stages throughout the workflow. They are used to indicate the time taken to perform a stage within a workflow, and are the basis of the BAR indicator (see 'Basic Functions' - Work Items').

• Workflow Testing Outcomes and UAT Testing Outcomes - thse are project management templates that could assis with your recording of your testing of the sysytem. You DO NOT have to use these. However, they are designed to provide as much information to Ieg4 as is needed for us to help solve any issues you may have found.

• Task List - is used as guide to the changes to the templates that you will need to consider - phone numbers, department name, opening hours for face-to-face appointments etc.

The system enables you to export data for reporting purposes.

On the initial screen there are a number of tabs to the left hand side. Export is one of them:

Selecting the 'Export' option:

There are two selections

Selecting 'Expiring Badges', the following data is sent to the csv file:

• Badge Type

• Ieg4 Case Reference

• Badge Holder

• Badge Number

• Age

• Date Of Birth

• Party Type Code

• Start Date

• Expiry Date

• Eligibility Code

• Delivery Option Code

• Status Code

• Application Channel Code

• Building Street

• Address Line 2

• Town City

• Address Line 4

• Post Code

• Primary Phone Number

• Secondary Phone Number

• E-mail

• Badge Id (IEG4 Internal Reference)

• Customer Id (IEG4 Internal Reference)

Selecting 'Payments, the following data is sent to the csv file:

• Id

• Item Id

• Description

• Amount

This can be achieved by simply selecting the export option, the system will then generate the csv file and prompt you when ready to download.

This section is generic to all Workflows where document templates are generated.

Dynamic Communications

Within the system dynamic notifications can be generated within the workflows similar to the example below for Missing Information.

With dynamic notifications the document template is stored in Settings within the Blue Badge system and when the Set content button is pressed the template is loaded to the screen. The user is able to edit the content before clicking Save which then sets that content to be delivered.

There is the option to select to send the document either as an email or a letter. If there is no email address with the application then do not select this option.

You can see in the example below that there is an email address

When you select one or other of the options (or both) a document is generated and when you save that document it will be stored in the Documents tab of the Case. You will need to manually Tag the document if needed.

Emails

If the document is being sent as an email there is no need to take any further action as the email will be sent automatically. The email file is also stored in the Documents tab and you can optionally go to the Documents tab and add a Tag to the document to indicate what type of notification it is for ease of reference later.

Emails generated from dynamic workflow actions are sent from the IEG4 platform directly using the Sendgrid email relay. The from address can be set to be your Council's domain with a small amount of technical work.

Letters

If the document is being sent as a letter you will need to go to the Documents tab of the Case after it has been generated in the workflow and open the latest file saved there to open the letter and print it out locally to be sent by post. You are also able to add Tags to the document to indicate the type of correspondence.

In this case the document created will use a letter template as below:

Contact Details

Contact Details can be held on a Case alongside the applicant's own details.

If you wish to use the Contact Details for any notifications that are generated in the workflows then select "Yes" next to "Use Contact Details?"

Static notifications - GOV.Notify

In addition to the dynamic document templates it is also possible to use GOV.Notify to send out additional notifications throughout the workflows if required. An example could be an email sent to the applicant to notify them of a successful application.

Where GOV.Notify is being used the Authority creates the template on the Notify platform and the Template ID is added to an Action on the Workflow to trigger that notification through the GOV.Notify Connector (configured in Settings).

The following Illustrates how the system will trigger the email within GOV.UK Notify to be sent to the customer upon stage progression. GOV.UK Notify is not essential for the Concessionary Travel system, it is an option within the workflow if you decide you would like to use this in addition to the standard dynamic notifications outlined above.

The Notes tab contains all notes made within the system. Notes are mandatory at certain points within the Workflow as dictated by your processes. Notes can also be added at any time as long as you have the correct permissions (See 'Permission Groups' below).

To highlight an important note, select 'Yes' under “Highlight as important”, input the note, and Press 'Save'. Upon submission of the important note, the system will highlight the note itself, and a red circle notification will display on the NOTES tab indicating the number of important notes on the case.

Anyone who now views the Case will be able to see that a note of importance needs to be looked at.

Most cases are created automatically in the system when a digital form is received. However a case can also be created manually to cater for paper applications and for other occasions when a new case is required but is not going to be triggered by a digital form e.g. if a badge is going to be cancelled or amended or if a replacement is requested via the contact centre.

In order to create a case you first need to have a person record to associate it with. You should search for an existing record before creating a new one. If no matching Person is found then you can create a new one using the Create Person function. (Note: the same principle applies for Organisations).

Create Case

Click Create Case

Select the appropriate Case Type from the drop-down list

Pre-populate case details

When creating a new case for a person that already has cases recorded on the system there is a pre-populate option that automatically completes case details from previous applications.

In the example below a new case is created for Jillian Scott. The person is found using the Local Search and then the Create Case button is used.

There is the option to use a previous case to pre-populate the details of the new one. Clicking on one of the Pre-pop links will fill the Case details section as below:

Then use the Create button to create the new case. Documents can then be uploaded manually to the new Case and the relevant Workflow can be manually started from the Workflow tab.

Renewals are created through the 'Application' workflow which is started automatically once a renewal application arrives from the DfT for a Blue Badge, or through a manual request for a Freedom Pass or Taxi Card.

For a Blue Badge:

• The DfT passes a 'RENEWAL' indicator, but the workflow operates in just the same way as the 'Blue Badge Application'. The renewal indicator is set by the DfT when a person enters a badge number in the on-line application. You can see the Case Type of 'Renewal' in the bottom left hand corner of the Summary below. It also shown on the 'Work Items' screen (see previous chapter):

For a Freedom Pass or Taxi Card,

• The renewal is requested manually by the Customer. A renewal is actioned in the same workflow as the Freedom Pass or Taxi Card Application, but for Freedom Pass or Taxi Card, it is a top level outcome at 'Initial Checks'.

Selecting 'Renewal Requested' returns the decision screen as to what type of Renewal has been requested:

Once the decision above is made, the workflow operates in just the same way as the 'Blue Badge Application'.

In order to comply with data retention policies, which may differ between Authorities, the Data Anonymisation process is configurable.

Once the process has run, only the case reference and date of birth remain, as these are required for reporting purposes.

When accessing the record, no further personal information is displayed.

Selecting the Active case still drills into the details, but there is no personal information.

Workflow steps are also void of information.

Information requests/emails also cannot be seen.

If you would like this functionality enabling, please contact us.

Templates are a powerful method of communication with applicants during the progression of the workflow. They are pre-determined text, which can be created and modified by you, and are used to communicate with the applicant at pre-determined times within the workflow.

Templates are currenty designed using html, and a certain knowledge of html is needed to create and amend them. An example of a template is the 'missing items' template as shown below:

As you can see, html is prevalent within the template, and a small training session is included as part of the installation and integration process to help you understand the basic html commands needed.

Templates are intrinsically linked with Lists.

Certain stages within the workflow require correspondence with the applicant. As an example the above template is used when requesting missing informatiom from the applicant, but to customise the communication a selection from a drop-down list determines what will be shown as text in the communication.

The following shows an example of a drop down list for communicating with the applicant for missing items:

By making two selections, along with determining the Communication method and selecting 'Set content' as below:

The following screen will appear:

As you can see, the text displayed is only that which relates to the selected items from the drop-down list.

Templates come with a powerful text editor as can be seen at the top of the screen above. This allows you to add any personal text that you may deem neccessary for this applicant. Any additional text you add at this stage DOES NOT update the standard template, the addition of any text only applies to this instance.

By pressing 'Save' on the above, the the select screen is returned:

By pressing on the 'Continue' button the communication will be sent automatically to the applicant (if e-mail selected), or be available in the documents tab for view and printing if in letter format. All communication with the applicant is available for viewing in the 'Documents' Tab. Every document should be Tagged so that it is recognised for what it is when you are viewing the Documents Tab. See 'Document Tags' above.

Using GOV.UK Notify - if this available to you - SMS messages can also be sent as communication with the applicant at specific stsges within the worflow. Notify text is only added and modified in the GOV.UK Notify system.

The IEG4 Blue Badge system is securely cloud hosted in Microsoft Azure meaning that there are minimal technical tasks for your IT team to complete as part of the implementation.

User Access

User access is via a standard internet connection to the IEG4 hosted environment in MS Azure. There are no other technical requirements for enabling users to access the system.

Secure email

Dynamic workflow notifications are sent by email through the IEG4 email relay which uses SendGrid. As part of the implementation your IT team will be asked to add the IEG4 SendGrid details to your Council's network policy in order that emails can be sent securely on your behalf.

Customer Portal hostnames

The IEG4 Customer Portal will be hosted in our MS Azure environment but we can ensure that the website address that the portal uses reflects your council's own hostname. This will involve a small amount of work by your network team to add in the relevant DNS entries.

Integrations

Standard integration connectors are available as described in the Integrations section of this document. We only require relevant API credentials in order to set these up for you.

A 'Badge is no longer needed' arises usually in the case of a resident passing away or maybe if the resident is moving abroad. Knowledge of this is known either through a communication from a relative, or in most Councils, through a TUO notification. This workflow is created manually.

The first screen that appears when you have chosen the workflow is as follows:

Depending uopn the option chosen, different results will appear. For instance if you were to select TUO, the following screen displays, where all that is needed is the TUO Reference Number to progress:

However, if you were to select Contact from Informant, the following screen displays, where details of the informant is needed along with the date the Badge owner passed away.

The Organisations workflow is automatically started when a new application is received for an organisation from the DfT application form.

An organisation record will be created when the application form is received and the relevant details from the online application form are added including any vehicles registered. It is also possible to create an organisation manually in the system and to create a new case for instances where a paper application has been received.

Click on the “Work Items” option on the left-hand side of the screen. This will display a list of cases that you have access to according to their current stage. Filter on Organisations in the Workflow drop down list:

You can click on the briefcase icon and this will drill you down into full case details:

You can view the submitted Application data by clicking on the On line application tab:

Workflow Stages

Initial Checks

Once an application is received a Case is created and the Organisations Workflow is started. The first stage is Initial Checks.

This is a decision stage in the process where you can click on one of options:

Out of Area – Reject - if the application is out of area then select this outcome and generate the out of area notification. This is then the end of the process.

Validation Organisation - if the application is for an organisation in the council area select this outcome. This will progress to the Validate Organisation Stage.

Validate Organisation

From Initial Checks when Validate Organisation is selected the application progresses to the Validate Organisation Stage. The following outcomes are available:

New organisation - if the organisation is not known to the Council select New Organisation and complete the screening questions relating to the organisation.

Existing organisation - if the organisation is known to the Council select Existing Organisation and complete the screening questions relating to the organisation.

In both instances the application progresses to the Qualification stage.

Qualification

From Validate Organisation the application progresses to the Qualification Stage.

Incomplete application - this outcome is used when there is information missing from the application. The application progresses to the Missing Information Stage. See section 3 below.

Complete proceed to Badge Details – if the outcome of the qualification is to issue the badge select this option.

Complete – refuse application – if the organisation is not eligible select this outcome. A notification is generated and the template can be tailored to organisations with a relevant list of refusal reasons. This is then the end of the process.

Badge Details

Where the Qualification finds the organisation eligible the case progresses to the Badge Details Stage. From here the badge can either be ordered or the application marked as requiring further evidence before the badge is issued.

The Vehicle Selector displays any vehicles linked to the organisation (this can be through the online application form or by manually adding them in the Local Search).

Pressing the Validate button will make an integration call to the DVLA to check the details entered and to return the Vehicle Type and MOT status. If the details do not find a matching record an error is displayed:

The vehicle cannot be validated unless a matching record is found.

A vehicle can be added through the Local Search, find the Organisation and select Add Vehicle

In this example the vehicle has been matched and the Validate button is now Green to confirm this. The Vehicle Type and MOT Status has been populated by the DVLA check.

In Badge Details - tick the Suitable box next to any validated vehicle that you wish to issue a badge for:

Note: the invalid vehicle cannot be marked as suitable and therefore no badge can be ordered.

Check the remaining fields of information required for the badge request and click Continue.

Payment

The application progresses to the Payment Stage with the following outcomes:

Payment received – Order badge(s) – this will add the Payment received Tag to the application. Choose the Payment Method and add the Payment Reference. The application progresses to the Auto Progress & Awaiting Payment stage.

Payment not received – where payment is required select this outcome and then generate the notification requesting payment. The application progresses to the Auto Progress & Awaiting Payment stage.

Application rejected – to cater for instances where the application is to be rejected after the vehicle check select this outcome and generate the refusal notification.

Auto Progress & Awaiting Payment

This stage is used to record the outcome of the payment and will be automatically completed when a payment is marked as received in the workflow (Note: Organisations applications are currently not supported in the Customer Portal)

Order Badge Auto Progress – when a payment has been marked as received in the Payment Stage the Payment received Tag is applied to the Case and this outcome is automatically completed and the application progresses to the Issue Badge DfT stage. In order for this outcome to be progressed the Tag Payment received needs to be present on the application.

Update Payment Status – use this outcome to return to the Payment stage to mark whether the payment has been received or not. The application returns to the Payment stage.

Payment Not Received Close – use this outcome to record that the payment has not been received and to close the application. The application progresses to the Complete stage and closes. This is then the end of the process.

Issue Badge DfT

When payment has been received the application progresses to the Issue Badge DfT stage. The Stage will automatically progress and will order the badge with the DfT. An integration call will be made to the DfT to request the badge and the application will be closed. This is then the end of the process.

Missing Information Request

Selecting Incomplete Application from Initial Checks will progress the application to the Missing Information stage. This stage has a tick box list for the Missing Items that relate to the evidence required tailored for organisations .

These details are then pulled through to the notification to be sent to the applicant requesting the details be supplied. The application progresses to the Missing Information Result Stage.

Missing Information Result

The Missing Information Result Stage allows you to record the outcome of the missing information request.

Missing Information Complete – Proceed to Badge Details – select this outcome where the missing details have been provided and the application is progressing to the Badge Details stage for the vehicle check and the badge details to be confirmed.

Missing Information Still Incomplete – Request Again – if the details are still incomplete and a further notification is to be sent to the applicant choose this outcome. The application returns to the Missing Information Request stage.

Missing Information Not Provided – Close application – if the case is to be closed choose this outcome. This is then the end of the process.

Organisation records

Additional functions are available to support organisations within the system.

Create Organisation

It is possible to create an organisation manually as with a party record.

Vehicles can also be added at this stage

Local Search

The Local Search supports a separate search on Organisations

From the Local Search tab select Organisation Search

Search on Organisation Name, Site Name, Vehicle and Case Ref (wildcard search currently not available)

The Organisation details page is displayed

An organisation can have multiple Sites. Click on the Site Name to open Site details:

These details are automatically populated by an online application form being received. It is possible to add further vehicles

It is also possible to create a case manually and to use the Pre-pop feature to copy the address details to the application:

Using GOV.UK Notify - if this available to you - e-mails and SMS messages can also be sent as communication with the applicant, but requires these notifications to be added to the workflow at defined stages and outcomes. These can be agreed at integration time.

We need the Id of the notification for us to add it to the workflow.

Notify text is only added and modified in the GOV.UK Notify system.

The following screen shows where one instance of Notify is used within the workflow:

The following llustrates how the system will trigger the email within GOV.UK Notify to be sent to the customer upon stage progression.

Introduction

Self-Serve is a core part of the Concessionary Travel case management system, as it enables you to focus on your tasks with the application and assessment of Applications, whilst enabling citizens to take more control of their application. Self-Serve saves you significant time in processing, chasing information and eradicating unnecessary citizen contact with your customer service team. This is achieved by automating 3 key functions:

• Showing the applicant the current Application Status

• Allowing the applicant to upload Documents

• Allowing the applicant to make Payments (Blue Badge only and if an on-line payment system is available within your Authority)

For the Organisations workflow we have built-in integration to the DVLA vehicle registration checking API. This integration is enabled for you by IEG4.

Within the Blue Badge system it is possible to configure a template in GOV.Notify to be triggered when a new case is created. This can be used to pass the Case Reference number to the applicant as soon as the application is received and to signpost them to the Customer Portal.

Blue Badge Configuration

In the Settings module access: Configuration / General / Case created configuration

The configuration is held in json format

Example configuration:

The configuration is used as follows:

notifyConnectorId: this is the GUID from the Notify Connector in the Connectors screen:

Types: this is the case types where 1 = New, 2 = Replaced, 3 = Cancelled, 4 = Renew

Sources: this is the application source type where 2 = Paper and 5 = Online

smsTemplateId: this is the template ID from GOV.Notify (for sms)

emailTemplateID: this is the template ID from GOV.Notify (for email)

In the above example New and Renew Case types received either Online or Paper will trigger the email template in GOV.Notify

Placeholders to use in the GOV.Notify template

The following placeholders are available to use in the Notify template

case_ref

first_name

last_name

postcode

selfserve_prepop_link (only relevant to legacy version of Self Service not OneVu)

selfserve_link

for Organisation:

case_ref

organisation

postcode

Example Notify template

Subject

Your blue badge application ((case_ref)) has been received

Message

Dear ((first_name)) ((last_name))

We have received your Blue Badge application, and your reference number is ((case_ref))

Your application will now be assessed. The turnaround time is currently up to 12 weeks from receipt to decision, (this does not include any additional time for independent walking assessments).

We will be in touch if we need any further information.

If you are automatically eligible for a Blue Badge, then you are likely to receive your badge sooner because the assessment process is shorter.

You can check the status of your application by clicking on the link below:

((selfserve_link))

Log in to your Blue Badge account or follow the instructions on screen to create one. When logged in select the Blue Badge service, input your application reference which is shown above, your last name and Year of Birth to access this facility.

Regards,

Blue Badge Team

If GOV.UK PAY is not in use within your Council, then we have built in the ability to fully integrate to Pay360 Secure Card Portal.

Setting Pay360 integration up

The only technical element to this process is to add your council's access references as follows:

• Scp id

• Site id

• HMAC

• HMAC key id

• Localisation

This system can link directly to Pay360 (if it's available to you) but to have access to it we require the access references as above. Once you have supplied these, we can then enable payments to be taken through the Customer Portal using Pay360.

If a payment is not received by the application route through the DfT, and you can take payments by other methods (cheque, BACS, cash, card) these payments can also be accepted and inputted manually via the Payment stage within the associated workflow. The user can select a payment to view further information such as Payment status.

Important

Central Government is becoming smarter. It has recognised that there are common functions provided in local government and it makes sense for these to be commoditised to enable reuse across departments and across local government. To that end they've built dedicated functions to:

• Take payments

• Issue notifications (email/SMS/letters)

• Confirm someone's identity.

These are the , , , services respectively. In this , IEG4 has already integrated to both PAY and NOTIFY and our intention is to leverage these wherever logical across other of our products.

So, we've built in the ability to fully integrate to GOV.UK PAY.

Setting GOV.UK PAY up

The only technical element to this process is to add your council's API reference key as provided by GOV.UK PAY. You access these within your GOV.UK PAY account. You can create an account if your council has not already done so.

Important

Therefore, for Blue Badge only, this system links directly to GOV.UK Pay (if it's available to you) but to have access to it we require an access Id. Once you have supplied this, we can then take payments using GOV.UK PAY through our self-serve portal and directly from the DfT if the Badge has been paid for at the application stage.

Payments can be made via GOV.UK Pay or inputted manually via the Payment stage within the associated workflow. The user can select a payment to view further information such as Refund, & Payment status. Payments can be refunded by selecting refund.

Important

The Freedom Pass Application Dashboard is and the Taxi Card Overview are accessed by clicking on the relevant tile within the standard reporting platform:

All the reports have extensive filter capabilities. Each report can be filtered by one or many of the following combinations of filters:

• Date Range (all Reports)

• Eligibility

• Application Type

• Application Source

• Status

• Age Group

• Channel

• Pass/Card Status

• Gender

• Ward

• Missing Item

• Application Stage (Outstanding Workflows and Workflow States only)

• Officer Name

• Workflow (Workflows Completed only)

The Freedom Pass Dashboard and the Taxi Card Overview consist of the following reports:

• Summary

  • Active Passes/Cards by Eligibility

  • Active Passes/Cards by Application Type

  • Active Passes/Cards by Application Channel

The Blue Badge Application Dashboard is accessed by clicking on the “Blue Badge Dashboard” Tile within the standard reporting platform:

All the reports have extensive filter capabilities. Each report can be filtered by one or many of the following combinations of filters:

• Date Range (all Reports)

• Eligibility

Introduction

To further leverage the entire system data set recorded in the CMS, there is a report book to assist you in measuring and managing operational effectiveness across teams.

The Freedom Pass Performance report is accessed by clicking on the “Freedom Pass Performance Dashboard” Tile within the standard reporting platform.

The Taxi Card Performance report is accessed by clicking on the “Taxi Card Performance” Tile within the standard reporting platform.

The performance report contain two reports as follows:

Performance Data Report

With this report, you have the ability to view performance by user; based upon the time to complete the different stages of the processes. This includes the ability to understand the count of workflows completed within different SLA bands.

There is the ability to:

• View the count of stages selected, displaying the SUM total of combined stages

There is the ability to filter the report on:

• Created between workflow dates.

• Workflow Names

• Workflow stages

The report shows the time taking for the combined stage/s and is broken down in the following bandings:

• Within 5 working days

• Within 10 working days

• Within 15 working days

• Greater than 15 working days

Officers also have the ability to filter by:

• Groups

• Users

With the ability to further restrict the count to only show time taken for the following workflow statuses:

• Current workflows

• Completed workflows

• Abandoned workflows

The report below demonstrates how the officer might show the total count of workflows where the stages from Initial Checks to Refusal were involved over a period of 3 months:

In the above, the report was filtered to display only completed Freedom Pass/Taxi Card Application workflows.

This report shows the stages from Initial Checks to Desktop screening, filtered by user groups over a period of 3 months.

Also, it is possible to make the report full screen and also show the data in different formats at a glance. In the top right (of any report) you will see a 'three dot' icon when the chart is hovered over. When you click on the actual icon you'll see a menu pop out.

Export Data allows you to export the filtered data in two different formats from this report to Excel (the underlying data is not available) :

Depending upon your selection, you will see different outcomes in Excel. The following shows and example of the 'Data with current layout:

This shows 'Summarized data':

Performance Completed Report

With this report, you have the ability to view performance by user; based upon the time to complete the different stages of the processes. This only includes those workflows that have been completed.

There is the ability to filter the report on:

• Completed between workflow dates.

• Workflows Names

• Workflow stages

The report shows the time taking for the combined stage/s and is broken down in the following bandings:

• Within 5 working days

• Within 10 working days

• Within 15 working days

• Greater than 15 working days

Officers also have the ability to filter by:

• Groups

• Users

The following is an example where the report shows the time taken from 'Initial Checks' through to 'Pass Details/Card Details' for the User group 'Blue Badge Users' (this is a generic User Group for Blue Badge, Freedom Pass and Taxi Card) for all Users within that group:

Again, it is possible to make the report full screen and also show the data in different formats at a glance. In the top right (of any report) you will see a 'three dot' icon when the chart is hovered over. When you click on the actual icon you'll see a menu pop out. The same format of Excel data is displayed as per the screens shown for the Performance Data report above.

Introduction

Reporting is an integral part of the Concessionary Travel system and is supplied as part of the basic system installation.

It is designed and written using Microsoft Power BI, which is a powerful and flexible reporting tool.

The reports are updated on a nightly basis where all work completed during that day is included for the next days reports. There are two seperate sets of reports for each of the individual Concessions, plus a Combined set.

• Blue Badge Application Dashboard

• Blue Badge Performance Dashboard

• Freedom Pass Application Dashboard

• Freedom Pass Performance Dashboard

• Concessionary Travel Dashboard

• Taxi Card Application Dashboard

• Taxi Card Performance Dashboard

Activating Self-Service

Once the application is completed, the applicant has access to their self-serve portal to stay informed of where the application is in the process. Furthermore, during the process, automatic communications are sent to the applicant alerting them to login into to self-serve and take appropriate actions to further their applications.

The example below demonstrates how you select the information that has not been included in the initial application. The missing items are selected within the workflow stage and then an email is automatically created that includes text relating to the missing items and the URL self-serve link to the portal.

This is an example of the e-mail, showing the URL ink to the self-serve portal

Introduction

To further leverage the entire system data set recorded in the CMS, there is a report book to assist you in measuring and managing operational effectiveness across teams.

The Blue Badge Performance report is accessed by clicking on the “Blue Badge Performance” Tile within the standard reporting platform:

The performance dashboard contains two reports as follows:

Performance Data Report

With this report, you have the ability to view performance by user; based upon the time to complete the different stages of the processes. This includes the ability to understand the count of workflows completed within different SLA bands.

There is the ability to:

• View the count of stages selected, displaying the SUM total of combined stages

There is the ability to filter the report on:

• Created between workflow dates.

• Workflows Names

• Workflow stages

The report shows the time taking for the combined stage/s and is broken down in the following bandings:

• Within 5 working days

• Within 10 working days

• Within 15 working days

• Greater than 15 working days

Officers also have the ability to filter by:

• Groups

• Users

With the ability to further restrict the count to only show time taken for the following workflow statuses:

• Current workflows

• Completed workflows

• Abandoned workflows

The report below demonstrates how the officer might show the total count of workflows where the stages from Initial Checks to Refusal were involved over a period of 3 months:

In the above, the report was filtered to only display data within the Completed workflows. The data was also filtered to only show data that IMA administrators have completed or are currently working on.

This report shows the stages from Desktop screening to complete, filtered by user groups over a period of 3 months.

Also, it is possible to make the report full screen and also show the data in different formats at a glance. In the top right (of any report) you will see a 'three dot' icon when the chart is hovered over. When you click on the actual icon you'll see a menu pop out.

Export Data allows you to export the filtered data in two different formats from this report to Excel (the underlying data is not available) :

Depending upon your selection, you will see different outcomes in Excel. The following shows and example of the 'Data with current layout:

This shows 'Summarized data':

Performance Completed Report

With this report, you have the ability to view performance by user; based upon the time to complete the different stages of the processes. This only includes those workflows that have been completed.

There is the ability to filter the report on:

• Completed between workflow dates.

• Workflows Names

• Workflow stages

The report shows the time taking for the combined stage/s and is broken down in the following bandings:

• Within 5 working days

• Within 10 working days

• Within 15 working days

• Greater than 15 working days

Officers also have the ability to filter by:

• Groups

• Users

The following is an example where the report shows the time taken from 'Initial Checks' through to 'Completion' for the User group 'Blue Badge Users' for all Users within that group:

Again, it is possible to make the report full screen and also show the data in different formats at a glance. In the top right (of any report) you will see a 'three dot' icon when the chart is hovered over. When you click on the actual icon you'll see a menu pop out. The same format of Excel data is displayed as per the screens shown for the Performance Data report above.

Accessing Self-Service

Applicants can use the login details provided in the automated communication to login to their OneVu portal. This can be by smart phone, tablet computer or laptop.

If this is the first time that the applicant is viewing their Blue Badge on-line, they need to Register for an Account by clicking on the 'Email Address' at the bottom of the Sign-in screen. This step can be ignored if the applicant already has a OneVu account.

The applicant will be presented with a form to Register for an account.

They will complete the registration form and press Submit and the following screen will appear.

They will then be sent an e-mail in which they will be asked to confirm their e-mail address. Once they have confirmed, they will be re-presented with the original Login screen, into which they can enter the e-mail and password that they have just created.

On subsequent visits they will not have to Register again, but will be presented directly into the Login Screen where all they need to enter is their e-mail address and password.

Once they have logged in, their self-serve Portal 'Get answers fast' screen will be presented.

They will select the Accessible Transport service. As you can see there is the possibility of more than one tile at this stage depending upon whether another of your service directorates uses this self-serve system as well.

When presented with this screen, they need to input their Application reference which is shown above and their Year of birth - their Last Name will be propogated from their sign-in - then select 'Register'. The following screen will appear:

They will then be able to view the status of their application, upload documents or pay using GOV.UK Pay (if you use this method of payment), without having to contact you.

The Concessionary Travel Dashboard is two reports of combined Blue Badge, Freedom Pass and Taxi Card data, accessed by clicking on the “Concessionary Travel Dashboard” Tile within the standard reporting platform:

These reports have a number of filter capabilities. The reports can be filtered by one or many of the following combinations of filters:

• Date Range (all Reports)

• Eligibility

• Age Range

• Gender

The Concessionary Travel Dashboard consists of the following reports:

• Summary:

  • Total Concessionary Applications

  • Concessionary Applications by Month

  • Location of Concessionary Applications (heat map)

• Concessionary Passes/Cards and Blue Badges

  • List of Badge, Pass and Card owners, with Blue Badge Number, Freedom Pass Reference (if captured within your workflow) and Taxi Card Reference (if captured within your workflow). You can drill down on this.

You can drill down on this report by pressing the under either the BBUrl the FPUrl, or the TCUrl. This will take you the CMS showing you details about the Badge, Pass and/or Card owners.