Do people use cards to mange work for Incident and/or Service Request Tickets?

Hello Bill,

From a Support perspective we notice clients are more often taking routes similar to your first option. This is because there is no automatic way to convert a ticket into a Card Wall card, so doing so would require extra steps. Since streamlining is the preferred option usually, leaving them as they are is normally the route taken.

Let me know if you are interested in any other opinions though and I can try to get our Implementation Specialists to comment on habits they've seen in other customers.

Sincerely,
Mark Sayers
TD Support

Hi Bill,

The problem I have converting a ticket to a card, I loose the workflow I have associated to the ticket.  Also, the ticket always stays "Converted to Task".

The following is from the ticket:

Because this Incident has been converted to a completed project task, statuses not in the "Completed" class will be reverted on an hourly basis by the automated processor. You may move between statuses with a "Completed" class.

Kathy
West Virginia University

Hello Bill,

I'd like to start by saying that the ticketing/Cardwall integration was desiged with operational work management and service request management in mind.  I agree with your positives.  I've elloborated on your potential negatives below.

1) The Service Desk would have to work in two user interfaces (Tickets and Cards)

This depends, you can set up a process where a manager converts a list of tickets (Changes,Service Requests, etc...) to tasks within a cardwall.  From there, technicians can take responsibility and manage the converted ticket without having to engage a ticketing queue elsewhere.  For example, once upcoming changes have been approved, the manager for that area would convert the changes to tasks and the technicians would update the change once they executed the activity.

2) We would need to create an "Operations Project" to capture all the cards that were created from Incident or Service Request tickets not related to an actual project.  This could skew our Project Portfolio Statistics (We do think there is a way to not have it show up in the stats, but need to check in to it further)

Your correct about having to create an "Operations Project" to capture the cards converted from tickets.  Schools who do this will either use the project classification  or project type field, both are configuarable, to designate if the project is operationally focused.  Having the "Operations Project" appropriately marked will allow you to filter them out when pulling together certain portfolio level reports.

Additionally, the "Operations Project" will still allow you to capture needed resource allocation information for more robust resource reporting and capacity planning.

3) Potential challenges on reporting ticket status.  It is our understanding that while you are working on a card, the information does not transfer back to the ticket until the card is completed/closed.

This is true.  The ticket's status will remain "converted to task" until the task has been completed.  You can however, set up task level reports to filter on just "converted tickets" then display their associated status (card wall list) for a better understanding of the ticket's status.  This report can be consumed via dashboard, email, or on demand.

Does this help Bill?

Mark,

Thans for your reply.  There is interest by some team members to try option 2, so I would be interested in hearing from implementation specialists.  My understanding (and I have not checked it out) is that you can easily convert a ticket to a card.  Here's what we see as the positive and negative by doing #2 - Start as a ticket and convert to a card to track the work.

Potential Positives

1) Visual display of a card wall makes it easier to view the work and status

2) Ability to move the cards up and down to identify priority.

3) Ability to move the cards from column to column to show where they are in relation to work progress - Backlog, Planned, In Progress, Awaiting Customer Response, etc.

Potential Negatives

1) The Service Desk would have to work in two user interfaces (Tickets and Cards)

2) We would need to create an "Operations Project" to capture all the cards that were created from Incident or Service Request tickets not related to an actual project.  This could skew our Project Portfolio Statistics (We do think there is a way to not have it show up in the stats, but need to check in to it further)

3) Potential challenges on reporting ticket status.  It is our understanding that while you are working on a card, the information does not transfer back to the ticket until the card is completed/closed.

We definitely can see some benefits, but we are concerned that we may be using the system in a way that it is not meant to be used.  If you or anyone else has thoughts on this, I would love to hear about them.  Thanks