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 3 Current »

Process General Details

S1 Process - Support

The S2 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 NameS2 Process - Support ver 1.0
Process DescriptionS2 process for support is defined to follow the structured approach in case any Severity 2 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 within 3 releases from the date the bug is prioritized as P2.
Process Scope

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

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

Process RolesL1 Support Team , L2 Support Team, Solution Circle Owners, Implementation Team, Engineering Team
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 (ETA on S2 to be communicated as "within the next three months")
5. Solution 
6. Closure of Issue

Process Diagram

S2 MAP (1).pdf

Appendix:


  1. Support Helpline Number - +91 7483957150 . 
  2. List of Solution Circles: https://docs.google.com/presentation/d/1s9S79apFlMvWvrS6AS3F_yDB4Bhoinklwfck1CLx0j4/edit#slide=id.p
  3. Support Email : support@teamdiksha.org
  4. ETA on S2 to be communicated as "within the next three months" by L1 Support



1. Issue Raised


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

Validate and verify the issue with a Severity of S2

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 S2

Refer S1 rubric to qualify that it is not a S1 ticket as per rubrics

Provide Workaround to the user (if available)

Resolve the issue (if applicable)

3. Severity Justification


InputL2 Lead to further check on Severity Classification
OutputA decision on Priority Justification
Role(s) InvolvedL2 Lead and Support OPS 
Stage Activities

Deliberating on the Severity of the Diksha Ticket

4. ETA Confirmation


InputJira Ticket assigned to Solution Owner for Priority
OutputPriority Validation along with roadmap to execution of the solution
Role(s) InvolvedSolution Circle owner, L2 Team Member, Support OPS and IMPL Team 
Stage Activities

Get the Final ETA from the respective Circle (ETA on S2/P2 to be communicated as "within the next three months")

Update the Jira ticket with the ETA

Responding to the user with the ETA

5. Solution


InputP2 Status on Jira Ticket
OutputDeployment of Solution
Role(s) InvolvedEngineering/Implementation Team, Release Manager, Circle owner for the track
Stage Activities

L2 Lead follows up on solution as per ETA

Engineering/Implementation or circle owner 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,  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. S3 tickets and S1 tickets
  2. If the Circle owner has not yet planned for the solution as per timelines yet, but will plan it within the 3 cycle ETA.
  3. This process does not capture the closure of the Jira Ticket
  4. Changes to the Circle composition basis time
  5. Change/deprecation of feature within the 3 cycles of deployment.

Process Metrics

The process metrics are as follows:

  1. % accuracy of the debugging efforts by L2 should be over 90%
  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