Quality Checks

Currently, there are 0 users and 1 guest visiting this topic.
Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #21010

    I would be interested to know how other LAs report errors back to their benefit teams following QA checks.

    Do you identify the user who is responsible for the error and how do you monitor if the correction has been actioned?

    Also, do you seperate errors that are not going to affect benefit from errors that are going to affect benefit?

    Any comments would be appreciated.


    the site I am currently working for is looking closely at error checking.

    We have a database set up which enables the recording of the error and this is fed back to the teams via the team leaders and is then reviewed at quarterly supervision meetings. We are currently looking to beef up the process so that specific training needs can be easily identified from an individual perspective and as refreshers for all assessors. As usual the big factor is the extra time and resources needed!


    Thanks for your reply. We check each claim and send an error sheet back with the benefit file to the relevant team for correction which must be sent back to us by the end of the month after the correction has been made. However, we also inlcude errors on the sheet that don’t require to be corrected (i.e. the FI date being incorrect as they are unable to amend this) and also admin errors i.e. spelling mistakes etc.

    I am really looking to improve this process so that it causes the least amount of disruption to the benefit processors as possible. (you can imagine how frustrating it is for them to have piles of claims to key and then have QA error sheets handed to them asking them to do lower priority tasks such as putting the claimants telephone number on the system).

    We normally askt that it is the person who made the last calculation on the claim that corrects the errors, but this is not always possible and I’m not sure it’s entirely fair.

    Do you have a procedure for who corrects your errors?


    I have worked at several sites where the option is simply to return the checking sheet to the assessor who is named on the last calculation, if the checking is done before the payment run then it is unusual for another assessor to be responsible for the error, as for minor admin errors such as spelling etc – this is a simple housekeeping exercise that all assessors should be responsible for.

    I think the key is in showing that all assessors are treated fairly and those who repeatedly have errors are dealt with as part of the training needs process.

    Ian Sharratt

    If you use a DIP system (we use Comino) you can set up the process maps to pick up the quality checking and then return the case to the user to correct the error who having done that sends it back to the QC section tyo comple the process. It works well here.


    We return individual checking sheets to the assessor who has done the assessment, but have just introduced a monthly workshop where we go through the ‘top ten’ errors of the previous month, and follow up with specific training sessions on those areas if needed.

    Once the corrections have been done the form goes to a team leader for confirmation that the correction has been done.

    No suprises that dates are the biggest area for errors!


    Our QA carries out the 10% statutory daily check. Our checks are categorised as either ‘financial, non financial or comments’. The checking sheets are then split into three sections – errors for the current check, errors in the current financial year and errors created prior to the current financial year.

    Each checking sheet with an error on is sent back via email. If the error is in section 1 (current check) it is returned to the last assessor. If the error/s are in either of the other two sections it is returned to a central email and the hb teamleaders allocated to the appropriate assessor.

    We keep a record of the daily checks in spreadsheet which calculates the weekly, monthly and cummulative errors. It splits them into the three categories mentioned above. We also analyse the errors made for each assessor monthly (financial and non financial) based on the 10% check. (this does expand if we carry out further checks on assessors)

    If you want to know more by all means email me.




    We have developed a fairly sophisticated database specifically for recording, reporting and monitoring of Quality Assurance. It enables the details of quality checks to be quickly and easily recorded, individual feedback sheets to be automatically produced to assessors, and enables a wide range of stats and data analysis to be generated.

    The database identifies errors which will directly affect benefit and those that are non financial, and also enables Checkers to monitor the action taken with reported errors.

    We have sold our datebase to a number of other local authorities (approximately 10 I think at the latest count) at a very reasonable price 😆

    Feel free to drop me any email if anyone want anymore details.


    I would be interested in your database (LA Higgins)
    Here we notify errors directly to the assessor by memo – in three ways using our document imaging system:
    Impact – where entitlement is affected (to be corrected the same day)
    Impact2 – where the assessor processing a current change failed to notice an error on the claim made by someone else (the latest assessor has to correct the error the same day, but it is noted and recorded on both files)
    Memo – spelling, general omissions that do not affect entitlement – these have to be corrected within 10 working days.
    When the errors have been corrected, the assessor appends the memo to say it has been done.
    This works quite well, and the way we record it is quite good, but I would appreciate a more sophisticated method.


    I have seen Telford’s database system and can vouch for the fact that it is a very useful tool

    (Does this earn me some commission on sales?)

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.