Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Process General Details

S1 Process - Support

The S1 process outlines the basis of Severity Classification done at the Support Level on Freshdesk and Jira Interfaces and the efforts to drive closure of the ticket.

Process NameS1 Process - Support ver 1.0
Process DescriptionS1 process for support is defined to follow the structured approach in case any Severity 1 issue is reported via the Freshdesk Tool. It documents the action between various functions in order to address and close the issue reported by the user.
Process Scope

Scope of this process is limited to the tickets raised via the freshdesk tool for severity 1 classified by the L2 Support Team.

This S1 process is for DIKSHA only. Not for issues faced by any other adopter(s).

Process RolesL1 Support Team , L2 Support Team, S1- Coordinator (from Support), Engineering Coordinator, Implementation Team, Engineering Team, Business Representative (ETB, EQB, TPD)
Process BoundaryFreshdesk Ticket initiated on the Freshdesk Tool triggers the process and the closure of the Freshdesk Ticket ends the process.
Process Stages1. Issue Raised
2. Severity Classification by L2 Support
3. Priority Justification
4. ETA confirmation
5. Solution 
6. Closure of Issue

Process Diagram

Appendix:


  1. PM-Architect Alignment - This is the spreadsheet to capture the PM & Architect associated with the respective workflow
  2. List of email address for PMU Team - sarthak@teamdiksha.org, pranshul@teamdiksha.org, chinmay@teamdiksha.org
  3. Support Helpline Number - +91 7483957150 (S1 Coordinator)
  4. List of Major Workflows - (images attached below):


 L2 S1 Rubric:




1. Issue Raised


InputFreshdesk Ticket
OutputDiksha Jira Ticket
Role(s) InvolvedL1 Support Team and S1 Coordinator
Stage Activities

Validate and verify the issue with a Severity of S1

Gather Qualifying information from the user

Replication of issue

Resolve the issue (if applicable)

2. Severity Classification by L2 Support


InputDiksha Jira Ticket
OutputDiksha Jira Ticket Updated / Sunbird Jira Ticket
Role(s) InvolvedL2 Support Team and L2 Support Lead
Stage Activities

Validate and verify the issue with a Severity of S1,

Refer S1 rubric to qualify for S1 and update the Jira Ticket

Provide Workaround to the user (if available)

Resolve the issue (if applicable)

3. Priority Justification


InputTriage Call Invite from S1 Coordinator Support
OutputA decision on Priority Justification
Role(s) InvolvedTriage Party 
Stage Activities

Initiating the Triage call based on the L2 S1 Severity justification

Getting the Triage Party to conclude the Priority Justification

Updating the Jira Ticket with the Priority Agreed by S1 Coordinator

4. ETA Confirmation


InputMinutes of the Triage Discussion
OutputETA from respective function (Engineering or Implementation)
Role(s) InvolvedS1 Coordinator, Engineering Coordinator/ Implementation Coordinator
Stage Activities

Get the Final ETA from the respective Function

Update the Jira ticket with the ETA

Responding to the user with the ETA

5. Solution


InputP1 status on Jira Ticket
OutputDeployment of Solution
Role(s) InvolvedS1 Coordinator, Engineering/Implementation Coordinator
Stage Activities

S1 coordinator follows up on solution as per ETA

Engineering/Implementation Coordinator updated the status and follows up internally for closure on the Deployment

6. Closure of Issue


InputJira Ticket Updated with resolution
OutputUser informed and confirmation is taken on the resolution
Role(s) InvolvedL1 Support Team, S1 Coordinator, L2 Lead, Engineering/Implementation Coordinator
Stage Activities

Validate and verify the issue resolution by L2 Lead

Updating the Diksha Jira Ticket by L2 Lead


Informing the user of the resolution by L1 Team

Closure of the Freshdesk Ticket by L1 Team

Exceptions 

The Exceptions to this process is outlined below:

  1. Triage calls will happen during the working hour over the weekdays and the next morning if the issue is identified post working hours.
  2. Triage calls over the weekend will be subject to availability of the participants else the call will be conducted on the next working day for all.
  3. This process does not capture the closure of the Jira Ticket (It is subject to RCA done on the issue)
  4. The S1 coordinator, L2 Support Lead and Engineering Coordinator have no votes during the Triage Call. They will just provide the qualifying information and gather inputs.
  5. There will be a max of 5 folks on the triage group(excluding the coordinators). It is only their vote that will count in deciding whether the S1 ticket is indeed an S1. The representation will be from:
    • Minimum of 3 participants required to attain a quorum.
    • Business Solution, Architecture/Design Council, Implementation, Engineering.

Process Metrics

The process metrics are as follows:

  1. % accuracy on the rubric followed by L2 Support (% of instances NOT moved down from a S1 to S2 bucket post triage)- Should be greater than 80% (L2 Metric)
  2. % variance on ETA provided during the Triage process. Variance should not be greater than 10% (L3 Metric)

Escalation:

For all Support Related breakdowns:

Noel - noel@ekstep.org

For all Engineering/Implementation Related breakdowns:

Madhu - Madhu@ekstep.org

For all Solutions related breakdown:

Alok - alok@ekstep.org


  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.