Tech Support Process V 1

Technical Support Function Intra and Inter-Departmental Process Description

Version 1.1 Lall Ashok Shahdeo Revision History Date 2/12/2004

Version 1.1

Description Modified Draft

Spikesource Confidential 1

Author Lall Ashok Shahdeo

TABLE OF CONTENTS Intra and Inter-Departmental Process Description...............................................1 Lall Ashok Shahdeo.............................................................................................1 1.Introduction.......................................................................................................................3 1.1.Purpose.......................................................................................................................3 1.2.Goal ...........................................................................................................................3 2.Unification of Issue Criticality Indicators.........................................................................3 2.1.Priority & Severity Levels.........................................................................................3 3.Technical Support Incident Management Process............................................................7 3.1.Incidents with Severity Level: Critical / Major:........................................................7 3.2.Incidents with Severity Level: Minor /Enhancement:...............................................8 3.3.Slip / Backlog Management:......................................................................................8 4.Technical Support BugZilla Ticket Management Process................................................9 4.1.Tickets with Severity Level: Critical / Major:...........................................................9 4.2.Tickets with Severity Level: Minor/ Enhancement:................................................10

Spikesource Confidential 2

1. Introduction 1.1.Purpose To define processes and procedures relating to the Technical Support function, including logging and management of incidents, Tech-SupportSpikenet interaction and customer interface performance monitoring. 1.2.Goal The goal of defining these procedures is to establish a structure that: 1. Offers a reliable and consistent Technical Support interface to the customer. 2. Provides an efficient channel for customer issue resolution by Spikenet. 3. Balances customer’s expectations with resource availability. 4. Performs self-monitoring and generates reliable performance metrics. . 2. Unification of Issue Criticality Indicators 2.1. Priority & Severity Levels It is important to maintain a consistent and clearly interpretable set of indicators of issue criticality between Spikenet and Technical Support. Four distinct levels are identified for this purpose together with associated Tech Support and Spikenet role expectations in Table 1 (on the next page). There are actually two sets of indicators with a one-to-one correspondence between them regarding their meaning. The first set (Critical – Severity 1, Major – Severity 2, Normal – Severity 3 and Enhancement– Severity 4 is referred to as the Severity Level set and is controlled by Tech Support within the BugZilla and Call Log.

Spikesource Confidential 3

The second set (Immediate, High, Medium, Low) is equivalent to but is controlled by Spikenet. Any discrepancy between these levels indicates a failure in managing customer expectation. The processes described in the subsequent sections provide a way of re-balancing that expectation and address the goals enumerated in Section 1.2.

Table 1. Tech Support / Spikenet Issue Criticality Indicators

Severity Level (For Support) Critical Severity 1

Priority Level For R & D Immedi ate

Issue Classification Guidelines

Technical Support Role

Development Role - Only if required

System is not collecting any data.

Respond within 30 Minutes if it’s inbound or Web – Email Request.

As far as possible: respond with a patch or hot-fix by the next business day.

Customers business severely impacted as a result of complete or partial system outage.

Investigate if software patch is required and follow up with development, establish Partial outage defined: - delivery time frame of Partial Outage of any fix not more than two system functions business days ( Please resulting in a Major specify the exact day financial or business and time of the loss for the customer resolution) and we don’t have a workaround for the If problem requires a issue. software fix that can’t be executed in 2 business Demanding Customer days, communicate wants to fix the issue clearly to the customer immediately, failure to the resolution plan and do so may result in a time frame major financial or business loss for Spikesource and we

Spikesource Confidential 4

Severity Level (For Support)

Priority Level For R & D

Issue Classification Guidelines

Technical Support Role

Development Role - Only if required

Respond within 2 hours if it’s inbound or Web – Email Request.

Respond with a patch or hot-fix within 5 business days.

don’t have a workaround for the issue. Major Severity 2

High

Any system Outage that results in financial or business loss for the customer and we do have a workaround for the issue. Demanding Customer wants to fix the issue immediately, failure to do so may result in a major financial or business loss for Spikesource and we do have a workaround for the issue.

Investigate if software patch is required and follow up with development, establish delivery time frame of fix not more than 4 business days. ( Please specify the exact day and time of the resolution) Implement any possible workaround till the fix is implemented in four business days If problem requires a software fix that can’t be executed in 4 business days, communicate clearly to the customer the resolution plan and time frame

Normal Severity 3

Medium

System working as intended.

Respond within 4 hours.

Routine daily issues – Databases, Application

Investigate if software patch is required and follow up with

Spikesource Confidential 5

Address in next scheduled patch or schedule a new patch to fix problem.

Severity Level (For Support)

Priority Level For R & D

Issue Classification Guidelines

Technical Support Role

and Configuration issue.

development, establish delivery time frame of fix not more than 10 business days. ( Please specify the exact day and time of the resolution)

Any system Outage that doesn’t result in financial or business loss for the customer.

Development Role - Only if required

Implement any possible workaround till the fix is implemented in 10 business days. If problem requires a software fix that can’t be executed in 10 business days, communicate clearly to the customer the resolution plan and time frame Enhancement Low Severity 4

New feature requests. Embellishments to existing features. Cosmetic improvements. Misspellings, Grammatical errors. Language Semantics. Adding Value to the existing Product Line.

Respond within 1 Business day. Notify development of the suggestion or correction requested. follow up with development; establish delivery time frame of fix not more than 20 business days. (Please specify the exact day and time of the resolution. If enhancement request

Spikesource Confidential 6

Investigate feasibility. Roll viable suggestions into minor or major releases as appropriate. Apprise Technical Support of resolution plan.

Severity Level (For Support)

Priority Level For R & D

Issue Classification Guidelines

Technical Support Role

Development Role - Only if required

can’t be made in 20 business days, communicate clearly to the customer the resolution plan and time frame 3. Technical Support Incident Management Process Technical Support logs each new incident into CRM assigning it a Severity Level to one of four levels Critical – Severity 1, Major – Severity 2, Normal – Severity 3 and Enhancement– Severity 4as per Table 1 after assessing the customer impact and turnaround time required. Subsequent actions depend on the assigned severity levels as described below: 3.1. Incidents with Severity Level: Critical / Major: 1. A Tech Support rep responds within the mandated time and closes the ticket once the issue is resolved to the customer’s satisfaction. 2. If Tech Support identifies that Spikenet support or a software patch will be necessary, then Tech Support creates and processes a BugZilla ticket for the issue as described in Sec 4. 3. If the Tech Support rep needs assistance of any nature to resolve the incident within the stipulated time he/she immediately escalates the issue to the Tech Support manager Via Bugzilla 4. The Tech Support rep creating the incident in Call Log is responsible for closing such incidents the same day the following conditions are met: α. He/she is able to close the corresponding BugZilla ticket. β. No BugZilla ticket exists for this incident, but the issue is resolved to the customer’s satisfaction.

Spikesource Confidential 7

3.2. Incidents with Severity Level: Minor /Enhancement: 1. If Tech Support identifies that Spikenet support or a software patch will be necessary, then Tech Support creates and processes a BugZilla ticket for the issue as described in Sec 4. 2. Technical Support reviews all open CRM incidents and corresponding BugZilla tickets on a weekly basis. 3.

If a patch/ release available from Spikenet address any such incidents, the patch/release supplied to the customer and the incident closed after the customer reports satisfaction with the fix.

3.3. Slip / Backlog Management: Technical Support reviews all open Call Log incidents on a weekly basis. The following actions are performed every week -: 1. All incidents open beyond the time committed to the customer for identified resolution. 2. For incidents identified in (1) above, the cause of the delay is identified: a. If the delay occurs due to Technical Support is waiting for an event to happen from the customer side then Tech Support calls the customer ASAP, schedules a new resolution plan and progresses that over the next week. b.

If the customer proves uncooperative or has lost interest in having the issue resolved, or the incident is “dead” due to any other reason for 15 days the incident is closed in Call log. However if the incident has a corresponding Ticket in TTPro, the ticket is not closed until the issue is actually resolved and the fix tested inhouse.

c. If the delay is due to an event that needs to happen on Spikesource ’s end- then a new resolution date is forecast ed based on revisions to the resolution plan, newly identified need for Spikenet

Spikesource Confidential 8

involvement etc. If software modification is required then a BugZilla ticket created with the appropriate severity level and tracked. The customer is notified of the revision to the previously communicated resolution date.

Such incidents are recorded as a metric (with delay cause) and tracked to monitor Technical Support performance. 4. Technical Support BugZilla Ticket Management Process Whenever required, Tech Support creates a BugZilla ticket, assigning a Severity Level identical to that assigned to the corresponding Call Log. At the time of creation of the ticket, Tech Support sets the Priority Level to TBD. Subsequent actions depend on the assigned severity levels as described below:

4.1. Tickets with Severity Level: Critical / Major: 1. If the ticket severity level is either Critical or Major, Tech Support sends an email to the Spikenet manager immediately after creating the ticket, with the Ticket number and Title in the email subject header. 2. Every business day, Spikenet identifies all newly created “Critical” or “Major” tickets via email notification from Tech Support, and edits the ticket to correctly reflect all the following fields: α. Priority Level β. Target Release/ Date χ. Assigned to 3. After modifying the ticket, Spikenet immediately notifies the Tech Support originating the “critical” or “major” ticket via email if: α. more information / data is needed

Spikesource Confidential 9

β. the assigned priority level is not consistent with the assigned severity level 4. In the case of (a) the concerned Tech Support rep gathers the requested information asap and sends it to Spikenet. 5. In the case of (b), Tech Support works to match the customer’s expectations with the bandwidth that Spikenet can allocate to the resolution of the issue, escalating the issue if necessary. At the end of the process a consistent priority-severity level is mutually agreed to. Corresponding entries in CRM and BugZilla are modified to reflect that compromise. 6. Spikenet plans overlap support for Tech Support and allocates resources accordingly to facilitate issue resolution, emailing the overflow support plan details to the concerned Tech Support rep. 7. Tech support tests the patch sent by Spikenet to resolve the issue and closes the ticket if performance is as expected and the issue is resolved to the customer’s satisfaction.

4.2. Tickets with Severity Level: Minor/ Enhancement: 1. Spikenet uses the All Tech Support Tickets Open report created in BugZilla to review all such issues on a weekly basis using a predetermined day of the week for this activity, preferably two days before the weekly Product Meeting. 2. On the predetermined day Spikenet edits the ticket to correctly reflect all the following fields: a. Priority Level b. Target Release/ date c. Assigned to 3. Tech Support reviews such tickets the following day, every week. Any conflicts of understanding are resolved using the weekly product meeting with Spikenet.

Spikesource Confidential 10

4. When a fix is available, notification is sent by Spikenet to the concerned Tech Support rep., clearly identifying the BugZilla ticket number. 5. Tech support tests the fix and closes the ticket if performance is as expected and the issue is resolved. In the interests of process management, it is recommended that no functional entity other than Tech Support closes a ticket created by Tech Support.

Spikesource Confidential 11