Production Support Issue

Owned by gagnier
Last updated: Jun 21, 2022
4 min read

Production support issues arise when clients identify an issue with myTC account portal, API within a production environment. Public users may identify an issue with the production environment that is affecting a service (sometimes tickets are opened in ORION).

Scenario

<Client>

Client accesses the MyTC webportal [does not exist] and locates the “Submit Request” link.  Client clicks the link.  MS Form is launched that prompts the client with a series of questions regarding their request.  The client indicates the request is for a support issue they are having with a production environment. The client completes the details of what is required within the form and submits the form [A Request is Generated in DevOPs].

<Client>

Receives confirmation of request via email that includes the DevOps ticket #

<Holly>

Receives email indicating a new request has been received that includes the DevOps ticket #

Holly clicks on the ticket # link within the email to open the DevOps Ticket.  Holly can see who created the request and the pertinent details. It is obvious from the request type that this is issue is being identified as a production issue.

Holly moves the state of the request from “New” to “In Planning” and Holly creates a discussion comment and includes @client email and indicates – “we will triage this request and reach out as soon as we have an assessment”. Holly saves the request update.

<Client>

Receives an email that Holly and team will triage the request. (Includes a link to the request)

 <Holly>

Creates a message thread in myTC Account Teams Support group. “Urgent: can someone please have a look at the Production Support ticket # XXXXXX and let me know what we should do with this one. Thanks Holly”

<myTC Account Staff>

Receives a message in myTC Account Teams Support Channel regarding a support ticket.  Each staff should open and read the ticket so they are aware of the issue. Any staff that can respond  on what to do about the issue should do so.  The triage discussion should try to decide what to do with the request <Not our Problem> <Bug or Feature request><Proceed>

<myTC Account Staff>

Respond to Holly in the Teams channel that this issue is not the responsibility of myTC Account.

<Holly>

Holly moves the state of the request to “Done” and Holly creates a discussion comment and includes @client email and indicates – “this issue is not under the myTC Account control please reach out to…”. Holly saves the request update.

<Client>

Receives update from the DevOps ticket indicating this issue is not an issue myTC Account can attend to.

</Not Our Problem>

<myTC Scrum Master>

Respond to Holly that this is most likely a bug or feature request and that a triage session will be required.  (follow the service blueprints for either of those request types)

<Holly>

Updates the discussion comments and includes @client email and indicates – “This request relates to a feature request or Bug.” Holly saves the request update.

<Client>

Receives an email that the request has been updated.

</Bug or Feature Request>

<Proceed>

<myTC Account Scrum Master>

Creates an initial PBI/Tasks in the DevOPs development backlog and creates a discussion comment and includes @Holly email and indicate – “This dev support issue will proceed”. Scrum Master saves the request update.

Is there enough urgency to inject this issue directly into the sprint? <Urgent><Handle during the Sprint>

<myTC Account Scrum Master>

Who is the “right” person to take on this issue?  Assign the PBI/Task to the appropriate myTC Dev Staff.

<myTC Account Dev Staff>

Receives an email that a PBI/Task has been assigned to them.

<myTC Account Dev Staff>

Completes the PBI/Task work and corresponds with the client directly (if required). Closes the PBI/Task when the work is completed and includes @Holly @myTC Account Scrum Master in the comments so that Holly is informed that the task is “done”.

<Holly>

Receives the email that the PBI/Task has been completed.  Holly marks the Request as “Done” and include a message @client “ The request is considered completed at this time”

<Client>

Receives the email that request has been completed.

<myTC Account Scrum Master>

Receives the email that the PBI/Task has been completed. 

</Urgent>

<myTC Account Scrum Master>

Schedules a sprint planning session and invites Holly, Pat and all myTC Account Staff

<myTC Account Staff & Holly & Pat>

Receives an invitation to sprint planning

<myTC Account Scrum Master>

Hosts a sprint planning session.

During the session it is decided the request is a priority and it is assigned to a staff member.

<myTC Account Scrum Master>

Who is the “right” person to take on this issue?  Assign the PBI/Task to the appropriate myTC Dev Staff.

<myTC Account Dev Staff>

Receives an email that a PBI/Task has been assigned to them.

<myTC Account Dev Staff>

Completes the PBI/Task work and corresponds with the client directly (if required). Closes the PBI/Task when the work is completed and includes @Holly @myTC Account Scrum Master in the comments so that Holly is informed that the task is “done”.

<Holly>

Receives the email that the PBI/Task has been completed.  Holly marks the Request as “Done” and include a message @client “ The request is considered completed at this time”

<Client>

Receives the email that request has been completed.

<myTC Account Scrum Master>

Receives the email that the PBI/Task has been completed. 

</Handle during the Sprint>

</Proceed>