Zero Outage compliance in Software Support Services

Software Support Services are generally technical support or software troubleshooting services delivered by different software providers. Support services may be delivered as long-term support contracts or incident-based support contracts.

Depending on the nature of the reported issue, software support services may be delivered on-site or remote such as: troubleshooting, installation, upgrade, migration, or different software usability support. All these services can be delivered either by the vendor support department or other third-party software consulting companies which for the end customer reporting the issue is, most of the time, irrelevant. All that matters is having the problem solved in a timely manner with zero additional costs.

To be able to offer Zero Outage software support services, companies need a highly professional, organized, and structured support procedure that ensures the technical team will be involved and will react very quickly to have the issue solved with zero downtime.

Zero Outage Software Support Procedure

Software providers (vendors) need to have an on duty, 24×7, Service Delivery Manager (SDM) which should be the vendor’s single point of contact (SPOC) for the customer.

As soon as a High Priority or Major Incident (called also EK1 class incident) is reported on the customer environment, the Manager on Duty (MoD) from the customer will initiate a “wake-up” call at a “red hotline” to inform the vendor SDM about the Major Incident.

Based on a pre-defined and mutually agreed Zero Outage Procedure, customers need to provide the vendors the first set of information to sort out the issue and be able to involve the right technical resources as quickly as possible. A brief description of the incident should include software, application, environment, and project name versions.

Business impact needs to be reported (e.g. # user impacted or hourly loss in Mio$) and the expected time-of-day for recovery of the impacted IT service (if not asap).

MoD will document contact details for all participants and vendors involved in the Major Incident and will send the participants the agreed time for the initial Management call as well as the frequency of the next Management Calls.

Collection of the technical data needed for the issue investigation needs to be send/uploaded via secure sites or other ways agreed by the parties.

During a Major Incident, both vendor’s and customer’s technical teams are advised to open a technical bridge to ensure effective troubleshooting and have a centralized communication.

Even tough service restoration is the highest priority during the incident management phase, the vendor’s SDM will ensure that there has been collected the appropriated diagnostics to support Root Cause Analysis (RCA) prior to the restoration step. This needs to be clearly documented in case the Action Plan is declined by the customer.

Escalation: If for any reason (lack of progress on the resolution, request for a service level not part of the service contract, etc.) the customer requests a VP escalation, the vendor’s SDM will inform the Company executive management team (upon procedure) of the pending escalation and provide all the details to help understand the escalation reason, the customer expectations and the action required from vendor management if any.

Major Incident closure: the incident will be closed only after the solution offered by the vendor’s technical team has been tested, implemented, and customers confirms the issue is solved but not before vendor provides the Root Cause Analysis (RCS) for the incident.

A last Management Call needs to take place to align and inform all parties about the solution and RCA and discuss the last details before announcing the Zero Outage Major Incident Closure.

Zero-Outage Technical Account Manager at Oracle ACS Global Expertise Center, Database & Systems