# Software Support

# Definition of software support

Software support is provided to users after software has been deployed to Production and users have started using it. Support is usually provided by an internal support team but may also include support from the vendor of the software system if its third party software. It involves resolving arising issues or challenges that hamper effective use of software. It also includes guidance provided to users on correct use of software.

# Channels for user support

The support process is initiated by users reporting issues or faults found in software systems or requests for software changes based on ongoing needs. It is therefore important for Government institutions to provide users with convenient channels for reporting issues and required changes. Below are some of the channels used for software support. Government institutions may provide a combination of one or more of these channels:

- Telephone. The software support team can provide a help desk telephone line where users can call to report issues. This requires a dedicated resource(s) to man the telephone to ensure user calls are responded to on a timely basis.
- Live Chat. Some organisations provide a live chat where users can chat with the software support time on a real time basis. This also requires dedicated resources who can respond to chat requests on a timely basis. Some organisations provide automated chatbots that can respond to common issues.
- Email. The software support team can provide an email address where users can call to report issues.
- Self-Service portal. Users can also report issues through a self service online ticketing system.

Whatever channels are adopted, it is important to have a ticketing system for recording and tracking issues to ensure no issues are lost or forgotten. A ticketing system is a help desk software program used to process, manage, and track user issues from submission to resolution. Ticketing systems automatically organise and prioritise support requests in a central dashboard. Issues can be categorised, prioritised and assigned on the tracking system.

# Procedures for issue prioritization and escalation

##### **Issue prioritisation**

Once issues are received from users and recorded as tickets, they should be analysed and prioritized based on their impact to the operations of the user departments. For example they can be classified as High, Medium or Low priority based on their criticality.

Prioritisation helps to ensure that the most critical issues affecting operations of the institute are handled first and also ensure efficient use of the available support resources. Reports can be obtained from the system and analysed on a periodic basis to provide visibility on the number of issues raised per system, nature of commonly reported issues, their criticality and how long it takes to close issues. This can inform decisions such as the need for additional support resources to improve user support as well overall health of the software. A system with a consistent high number of critical issues may be and indication of software that required to be upgraded or replaced.

#####  **Issue escalation**

Ticket escalation is the process followed to move a user issue to a higher-level support agent or manager. The goal of escalating a ticket is to achieve a faster resolution for an issue that may have taken longer to resolve based on its level of priority. There are several steps you can take to improve the ticket escalation process:

1. Understand which issues require escalation.
2. Define clear roles and responsibilities in the support process.
3. Automate your ticket escalation process. This can be through defining timelines for various status of tickets. For example new issues that have not been responded to within a specific timeline can be escalated.
4. Allow the support team to escalate their issues from multiple channels.
5. Keep users informed about the ticket progress.

The escalation process clarifies the boundaries and channels of decision-making throughout an organization in order to solve the problem quickly and with clarity.

Escalation management is also a process put in place to deal with incidents and problem management within a system, ensuring problems get resolved and issues are addressed at the right level.

# Communication and response time expectations

The response time is simply the amount of time it takes for the support staff to respond to an issue raised by a user. It is the most important metric when it comes to delivering great user support service. Response times and issue resolution times can be defined through a software Services Level Agreement (SLA). The SLA is a contract between your business and your IT supplier who can be an external vendor or inhouse IT team. The SLA outlines acceptable levels of service as well as compensation you would receive if the supplier fails to provide those services.

Government institutions should develop software Service Level Agreements (SLAs) that inform users on what timelines they should expect for response time as well as issue resolution times. This is regardless of whether the software is internally supported or supported by an external software vendor. In the case of support provided by an external vendor the SLAs should be part of their support contract.

There should be communication to users on expectations for key SLA metrics such as response times. This ensures users understand what to expect and can provide a basis for escalation when the SLAs are not met.

# Approach for troubleshooting and resolving software-related problems.

Resolution of software related problems typically follows the following steps:

- Identify and record the issue. Issues are typically reported by users and recorded in a support register or online help desk system.
- Assign the issue to someone with the skills to resolve it.
- The issue is assessed to understand the root cause and to determine how it will be fixed. This may require gathering more information about the issue.
- Fix the issue based on the root cause. In some cases where it is not possible to provide a fix in a timely manner a workaround may be provided.
- Track the progress of resolution of the issue and keep users informed.
- Test the issue after it has been resolved. The users should also test and confirm that it works as expected.
- Deploy the fix in Production after they have been tested and inform users of the change