Working issues

This page documents the workflow for working issues in the Customer Support Operations team. It covers the stages an issue progresses through from creation to completion, including triage, planning, development, validation, and implementation.

Understanding this workflow helps team members know what to expect at each stage, who is responsible, and what actions are required to move issues forward.

Issue flowchart

A standard progression for an issue will look like this:

graph TD;
  Start--> Triage;
  Triage--> Type;
  Type-->|Bug| Bug
  Type-->|Administrative| Administrative
  Type-->|Feature| Feature
  Administrative--> AdministrativeScheduling
  AdministrativeScheduling--> AdministrativeIsItTime
  AdministrativeIsItTime-->|No| AdministrativeQueued
  AdministrativeIsItTime-->|Yes| AdministrativeDevelopment
  AdministrativeQueued--> AdministrativeIsItTime
  AdministrativeDevelopment--> Implementation
  Bug--> BugDevelopment
  BugDevelopment--> BugValidation
  BugValidation--> BugValidated
  BugValidated-->|No| BugDevelopment
  BugValidated-->|Yes| Implementation
  Feature--> FeaturePlanning
  FeaturePlanning--> FeatureScheduling
  FeatureScheduling--> FeatureIsItTime
  FeatureIsItTime-->|No| FeatureQueued
  FeatureIsItTime-->|Yes| FeatureDevelopment
  FeatureDevelopment--> FeatureValidation
  FeatureQueued--> FeatureIsItTime
  FeatureValidation--> FeatureValidated
  FeatureValidated-->|No| FeatureDevelopment
  FeatureValidated-->|Yes| Implementation
  Implementation--> Completion
  Completion--> End
  Start(Issue created)
  Triage(Triage stage)
  Type{Request type?}
  AdministrativeScheduling(Scheduling stage)
  AdministrativeIsItTime{Is it being worked in the current iteration?}
  AdministrativeQueued(Queued stage)
  AdministrativeDevelopment(Development stage)
  BugDevelopment(Development stage)
  BugValidation(Validation stage)
  BugValidated{Was it validated?}
  FeaturePlanning(Planning stage)
  FeatureScheduling(Scheduling stage)
  FeatureIsItTime{Is it being worked in the current iteration?}
  FeatureQueued(Queued stage)
  FeatureDevelopment(Development stage)
  FeatureValidation(Validation stage)
  FeatureValidated{Was it validated?}
  Implementation(Implementation stage)
  Completion(Completion stage)
  End(Issue closed)

Stages

The work to be done on an issue largely depends on the stage the issue is in. Please note the assignee on an issue will change frequently as it moves from stage to stage.

A quick reference to the stages used is:

Triage

Here the DRI will:

• gather the needed information from the request (if required)
• determine if we can move forward on the issue
• determine if the issue is valid (submitted by correct person, is feasible, etc.)

After doing so, the DRI needs to:

• ensure a priority label is present on the issue
• ensure a customer label is present on the issue
• ensure a roadmap label is present on the issue (if the issue is tied to a roadmap item)

With that in place, the DRI will then move the issue to the next stage depending the request type:

• For Administrative issues, it is moved to the Scheduling stage
• For Bug or Feature issues, it is moved to the Planning stage

This can be done in one comment using quickactions, like so:

/label ~"Customer::Support"
/label ~"Priority::3"
/label ~"RequestType::Feature"
/label ~"roadmap_item"
/label ~"Stage::Planning"

You can also use the following group comment templates to generate a quickactions comment to assist you:

• Triage -> Planning
• Triage -> Scheduling
• Triage -> Development

Closing a triage issue

If the DRI has determine we cannot proceed on an issue, the DRI should take the following actions:

• comment stating why we will not be proceeding
• set the issue status to Won't do
• close the issue

This can be done in one comment using quickactions, like so:

Greetings,

After review of this issue, we have determined we will not be able to proceed on this issue.

This is due to <insert reasons here>.

Due to this, we will be closing this out. Should the above mentioned reasons be resolved, please create a **new** issue.

/status "Won't do" 

Planning

Here the DRI will:

• write up a gameplan for the issue (and post it on the issue as a comment)
• determine technical feasibility of the request
• determine a rough estimate of the work timelines needed (excluding validation time)
• determine the RICE score

After doing so, the DRI needs to:

• Add a weight value to the issue (use the RICE score)
• Add an iteration and milestone to the issue (for Bug issues only)

With that in place, the DRI will then move the issue to the next stage depending the request type:

• For Bug issues, it is moved to the Development stage
• For Feature issues, it is moved to the Scheduling stage

You can also use the following group comment templates to generate a quickactions comment to assist you:

• Planning -> Development
• Planning -> Scheduling

RICE score

Customer Support Operations uses a modified version of the RICE Framework on our Feature issues.

A breakdown of possible values for our modified version is:

We take the scores from the above values and use the following equation to calculate a RICE score:

(Reach × Impact × Confidence) / Effort

You can use this calculator (requires GitLab Google account access) to quickly generate a RICE score.

Closing a planning issue

If the DRI has determine we cannot proceed on an issue, the DRI should take the following actions:

• comment stating why we will not be proceeding
• set the issue status to Won't do
• close the issue

This can be done in one comment using quickactions, like so:

Greetings,

After review of this issue, we have determined we will not be able to proceed on this issue.

This is due to <insert reasons here>.

Due to this, we will be closing this out. Should the above mentioned reasons be resolved, please create a **new** issue.

/status "Won't do" 

Scheduling

Here the DRIs will discuss development timelines for the changes. This is done on a weekly cadence.

Once determined, the DRIs will do the following on the issue:

• set an iteration on the issue
• set a milestone on the issue
• set the DRI for the issue moving forward

After doing so, the DRIs will move the issue to the next stage depending on the timeline for work to begin:

• if the timeline for work to begin is the current iteration, the issue is moved to the Development stage
• if the timeline for work to begin is a future iteration, the issue is moved to the Queued stage

You can also use the following group comment templates to generate a quickactions comment to assist you:

• Scheduling -> Development
• Scheduling -> Queued

Queued

Issues will sit here until their iteration has begun. Once the iteration has begun, the DRIs should move the issue to the Development stage.

You can also use the following group comment template to generate a quickactions comment to assist you:

• Queued -> Development

Development

In this stage the DRI will perform any needed setup to enable testing and validation (normally in sandboxes). As the DRI makes changes for the setup, they should add comments indicating what has been done. While there is not a set format that has to be used, the general recommendation would look like:

## Development notes

- Zendesk Global Sandbox
  - Triggers
    - Modified [Example trigger](LINK_TO_TRIGGER)
  - Ticket forms
    - Renamed form [Example form](LINK_TO_FORM) to `Modified Example form`
  - Webhooks
    - Created [New webhook](LINK_TO_WEBHOOK)

Once you have done all the need setup, you need to perform a test suite based on what you have changed. The exact contents of the test suite is going to vary from issue to issue. While there is not a set format that has to be used, the general recommendation would look like:

## Test Suite

- Summary
  - Test done: xxx
  - Tests passed: xxx/xxx
  - Tests failed: xxx/xxx

<details>
<summary>Tests</summary>

- Description of test 1 to do
  - Ticket or artifact used: LINK_TO_ITEM
  - Expected results:
    - List
    - Of
    - Expectations
  - Status: :white_check_mark: :x:
- Description of test 2 to do
  - Ticket or artifact used: LINK_TO_ITEM
  - Expected results:
    - List
    - Of
    - Expectations
  - Status: :white_check_mark: :x:

</details>

As tests are performed, update the comment to indicate the results and state of the test. If tests fail, add notes or comments on what you noticed and if any changes need to be made.

Once all testing and development have been completed, you will need to move the issue to the next stage. The exact stage to use depends on the type of issue being worked:

• for Administrative issues, move to the Implementation stage
  • If doing this manually, make sure to add the label Validation::Skipped when moving to the new stage
• for Bug and Feature issues, move to the Validation stage

You can also use the following group comment templates to generate a quickactions comment to assist you in moving to the new stage:

• Development -> Validation
• Development -> Implementation

Validation

Here, the DRI will ask the requester of the issue to validate what has been setup aligns with expectations.

You should do this by making a comment asking the request for validation, making sure to include all information the requester might need to validate the changes.

You can use the Request validation group comment template to generate a quickactions comment to assist you in this.

At this juncture, the issue waits for a comment from the validator indicating the status of their validation. Your actions depend on what they come back with:

• If the requester validate the change(s):
  • Add the label Validation::Received
  • Move the issue to the Implementation stage
• If the requester rejects the change(s):
  • Add the label Validation::Rejected
  • Move the issue to the Development stage

You can also use the following group comment templates to generate a quickactions comment to assist you in moving to the new stage:

• Validation received
• Validation rejected

Implementation

Here you will generate a technical blueprint and implement the changes (either by merging MRs or making changes directly in systems).

A technical blueprint should go over, in detail, everything that was changed. Anyone looking at the blueprint should be able to perfectly reproduce what you did. This means linking to all created MRs, detailing any non-MR changes made, etc.

Once all implementation tasks are completed (for items using deployments, merging the MR is sufficient), change the issue to the Completed stage.

Completed

The DRI will add a comment indicating all work is completed (and what date it will be live if part of a deployment cycle) and then close out the issue.

When closing out the issue, make sure to set the status of the issue to Complete.

This can be done in one comment using quickactions, like so:

The work on this issue has been completed at this time.

As components of the changes are tied to scheduled deployments, it will be fully live 2026-02-01.

/label ~"Stage::Completed"
/status "Complete" 

You can also use the following group comment templates to generate a quickactions comment to assist you:

• Close out a completed issue

Blocked

This is a special stage that is used when something has blocked all movement on an issue. This could be related to missing approvals, waiting on a tool to be procured, etc.

The DRIs will review these issues weekly (during planning cadences) to determine if they need an update or can be “unblocked”.

• If all unblocked criteria have been met, the DRI will then move the issue back to the stage it was originally in.
• If it has been a week since the last update and the issue is still not able to be unblocked, the DRIs will follow the escalation protocol:
  • 1 week without it being unblocked: Ping the blocking party for an update
  • 2 weeks without it being unblocked: Ping the leadership of the previous person pinged for an update
  • 3 weeks without it being unblocked: Ping the leadership of the previous person pinged for an update
  • 4 weeks without it being unblocked:
    • Add a comment stating this has been blocked for 4 weeks without an update
    • Close the issue

Examples of escalation protocols:

• Example 1: Requester is a Support Engineer
  • 1st week without an update, we ping the requester
  • 2nd week without an update, we ping a Support Manager
  • 3rd week without an update, we ping a Support Director
  • 4th week without an update, the issue is closed
• Example 2: Requester is a Support Manager
  • 1st week without an update, we ping the requester
  • 2nd week without an update, we ping a Support Director
  • 3rd week without an update, we ping a VP of Support
  • 4th week without an update, the issue is closed
• Example 3: Requester is a Support Director
  • 1st week without an update, we ping the requester
  • 2nd week without an update, we ping a VP of Support
  • 3rd week without an update, we ping the CTO
  • 4th week without an update, the issue is closed

Note: These escalation paths assume the standard organizational hierarchy. Adjust as needed based on the specific blocking party’s reporting structure.

Moving an issue to the Blocked stage

To move an issue to the Blocked stage, do the following:

• indicate the issue is being moved to blocked
• note the current stage the issue is in (so it can be moved back)
• note the criteria needed to unblock the issue
• indicate what actions should be taken when the criteria is met

You can also use the following group comment templates to generate a quickactions comment to assist you:

• Move issue to blocked stage

Backlogged

This is a special stage that is used when an issue is backlogged. This normally means that while there is a desire to work it, it is to be handled in the far future (beyond the next 10 iterations) or at an unknown future date.

The DRIs will review these issues weekly (during planning cadences) to determine if they can be scheduled.

• If they can be scheduled, it is moved to the Scheduling stage
• If they cannot be scheduled, they stay in the Backlogged stage

Troubleshooting

Issue is not appearing on issue boards

That indicates the issue itself is missing required labels for the board (such as a stage label, customer label, etc.).

Add the label Stage::Triage and assign it to Dylan so the issue can be properly triaged.

Missing required information

If you realize required information is missing mid-workflow:

1. Add a comment requesting the information
2. Consider moving to Blocked stage if the delay will exceed 1 week
3. Tag the requester and any relevant stakeholders

View page source - Edit this page - please contribute.