Procedures, Processes and Systems for Problem Resolution
Effective Resolution of ProblemsAn ASPSP should create documentation to clearly outline the policies, processes and systems it has in place for problem resolution and its respective service level objectives. This framework should enable the effective resolution of TPP issues and therefore cater for problems that relate specifically to a TPP’s use of an ASPSP’s dedicated interface and test facility. When a TPP encounters a problem with an ASPSP’s dedicated interface, it could have a direct impact on a TPP’s ability to provide its service, which in turn has the potential to cause:
- loss of business;
- reputational risk;
- additional resource requirement; and
- negative outcomes for customers.
Online SupportASPSPs should provide FAQs, which address areas that may be specific to TPPs such as technical advice or test facility guidance. They should also consider a means of identifying recurring questions or user-error issues so these can be collated into FAQs to support the early resolution of problems. Problem resolution documentation, FAQs, contact details, opening times and out of hours support should be published and easily accessible in one collective area on the ASPSP’s website.
Ticket Management ProcessASPSPs must ensure they have a functioning ticket management system which enables them to respond to issues and problems raised within clearly defined service level targets. A successful problem resolution framework will enable the efficient identification and resolution of problems which specifically impact TPPs. The system for raising and reporting on tickets should be transparent in order to fully inform users and engender trust across the ecosystem. The ticket management process should categorise problems as and when they are reported and track the progress of each ticket until the point of closure. It should also enable an ASPSP to identify which problems relate to the operational use of the dedicated interface and the test facility. Where test facility problems have been raised by AISPs, PISPs and CBPIIs and resolved, this can be provided to the dedicated interface has been designed and tested to the satisfaction of TPPs.
TicketsAll tickets should be given priority ratings and these ratings should factor in the severity of the impact on the TPP. We recommend that ASPSPs consider incorporating the following impact assessment into their ASPSPs ticket management process.
Business critical issue – represents a complete loss of service or a significant feature that is completely unavailable, and no workaround exists (first response SLA – one hour).
Degraded service issue – includes intermittent issues and reduced quality of service. A workaround may be available (first response SLA – four hours).
General issue – cosmetic issues which include product questions, feature requests and development issues in staging environments (first response SLA – 24 hours).
Ticket fields should include mandatory and drop down options to assist in efficiently identifying which level of support a TPP requires. This should include a field to allow the TPP to select an initial priority rating. The tickets should be detailed and structured so that they contain sufficient granularity that the ASPSP is able to allocate appropriate priority level.
When considering and reporting problems related to testing, ASPSPs must take into account the categories, set out in the EBA Guideline 6.5 as well as, problems raised in functional testing (RTS. Article 30(5)) and ensure problems raised within these categories are resolved within the relevant service level targets, as well as, record any problems which are not resolved within those targets. ASPSP should also the use this process to identify problems raised in live use of the dedicated interface. OBIE recommended ticket fields include:
- Name of reporting organisation.
- Name and contact details of contact at the reporting organisation.
- Date ticket raised.
- Problem type/category.
- Details of the problem, including an indication of the likely impact for the TPP.
- Name of ASPSP and brand (if applicable).
- ASPSP environment impacted (test or production).
- Severity, as defined by TPP (if applicable).
- Severity, as defined by ASPSP.
- Log of all updates from TPP and ASPSP.
- Start time/date the change/fix is anticipated to take effect and the end date/time (if applicable).
- Date closed.