Laddawn.com : Help Desk Bug Ticketing

Opening tickets

Managing tickets

1 - Set status and priority

Be sure you have selected the "Website Development" template.
Priority - use your best judgment; when in doubt select priority 2.
Status: Leave as unassigned.
Technician: Leave unselected.
Group: Leave as "Web Development"

2 - End user details

The name in end user details is the reporter of the bug, and the person who should test the fix. Remaining fields should auto-fill.

3 - Bug details

Subject should be a concise summary of issue. Include terms that indicate the focus of your test - for example, "Godzilla" or "owner ID"
Section menu - use this to indicate where you encountered the issue. If you encounter the issue on multiple screens or going from screen to screen, select global/multiple and explain in your summary or description.
Browser/Version 1, 2, 3, etc. - we're working to streamline these menus. Skip if you know issue is not browser dependent. Otherwise, please just use the first browser menu to indicate which one you're using, then the version. Fill in the other browser/version menus only if you're actually testing in multiple browsers.
Site - disregard.
Description field will be used for the details of the bug, and screenshots if appropriate. As always, please provide sufficient detail for technicians to recreate the issue.

1 - Bug assignment

Cathy, John and Judy will monitor help desk throughout the day for all unassigned bugs as they are opened and assign them to developers, or put them into other statuses (see key to statuses below). Help desk automatically generates an email to the assignee every time a bug is assigned/reassigned. When John, Judy or Cathy assign bugs to developers (aka technicians), they will set the status to "in process."

2 - Communications while bug is in process

For the sake of transparency and continuity, avoid having substantive discussions about bugs completely outside of the ticketing system, via regular email.
Use "conversations" (from within the help desk or via email replies to ticket-specific help desk emails) to keep track of substantive questions and answers between you and the end user (reporter) or others, while the bug is being worked on.
Alternatively you could use the discussion notes feature, but they don't "ping" the end user (only end users can "ping" technicians with these notes). Until we gain more experience with the system, it's hard to say which method of communication is best.
We do not discourage you from having real face-to-face conversations, but if you do have them, please memorialize them with notes in the ticket, using either the conversations or discussion notes feature.

3 - When you've resolved the issue

And the end user IS in the technician group

And the end user is NOT in the technician group (for example, Cliff Ammann)

Put the ticket into edit mode -

Change status to "resolution pending" (or other status if appropriate).
Reassign the issue to the end user (changing to this status does not automatically reassign the issue, nor does it generate a notification).
While still in edit mode, open the resolution box and type a brief description of your solution. Do not use conversations or discussion notes for this purpose.
Save your changes; the issue is ready to be tested by the end user.

Put the ticket into edit mode -

Change status to "resolution pending" (or other status if appropriate).
Keep the issue assigned to yourself.
While still in edit mode, open the resolution box and type a brief description of your solution. Do not use conversations or discussion notes for this purpose.
Save your changes.
Use the conversations feature to shoot the user an email letting them know you've resolved the issue, and asking them to confirm by testing.

4 - Closing the issue

The end user IS in the technician group

The end user is NOT in the technician group

When the end user is satisfied the bug is resolved, he/she will change the status of the bug to "resolved/closed."
If the issue is not resolved, he/she will change status back to "in process" and reassign back to the developer.
- Immediately after reassigning ticket and changing status to in process, the end user should log the reason using the "discussion notes" feature, and check the "email this note to technician" box. These date- and name-stamped notes accumulate at the bottom of tickets in reverse chronological order.
- You can access the notes feature at the top of the ticket screen...

...or at the bottom of the ticket...

After the end user has tested the fix, he/she will reply to the help desk email from step 3-5 above. This will ping the technician still assigned to the ticket. If the end user thinks the issue is not resolved, they should include a detailed explanation in the email.
If the end user says the issue is resolved, you can close the issue.
If the issue is not resolved, you should reopen the issue by setting it to "in process."

Key to statuses

Unassigned - default status; to be left at this status when the issue is opened. The ticket has not been reviewed.

NOTE: This is an issue status, which is easy to confuse in Help Desk ticketing displays with the "Assigned to" column:
Open - the issue has been reviewed by Cathy, Judy and John, but not assigned to a technician. Bug is slated to be fixed before launch, but action is deferred for a couple of rounds of bug fixes.
On hold - the issue has been reviewed by Cathy, Judy and John, but not assigned to a technician. It is given priority to be assigned as soon as current batch of "in process" tickets are closed.
In process - the issue has been assigned to a technician, and the technician is actively working on the issue.
Resolution pending - the technician believes he/she has resolved the issue, and reassigns the issue back to the "end user" (issue reporter) to test.
Resolved/closed - the issue reporter has tested the resolution and is satisfied.
Unresolved/closed - this is for bugs that we will not resolve or new features that we will not provide. It is also for bugs that cannot be recreated.
Deferred to phase 2 - These are bugs that turn out to be new, desired functionality, or functionality that isn't working as designed - it's still desirable, but we decided to defer to after launch. This status effectively puts the ticket into a closed status, keeping it from appearing in filters that include open or pending tickets.

Note - pending resolutions and their tests can be things that aren't actual software fixes or software tests - for instance - the solution is "This is how it was designed" or "We can't do that because of X" and the issue reporter "test" can be "Oh yeah, that's right." or "Oh, I see."