PDA

View Full Version : Promote in-game tickets to bug reports via GMs



voodoogroves
10-18-2010, 02:20 PM
One of the missing loops in the customer service cycle seems to be follow-through on part of the in-game support, espescially when dealing with application-specific bugs or errors one would think merit a more general fix.

In the past week I've submitted two tickets. Both were basically admitted to be bugs by the GM, neither were moved on to bug-reports and instead were closed promptly after me asking what the process was to do so.

"You need to submit a bug report" followed immedaitely by "Your GM can no longer receive messages from you".





One of the keys to customer loyalty and good customer service is to make the things you can easy on your customers. You have a ticket system. You have a bug system. When a user submits something as a ticket that they honestly don't know is a bug or not and you tell them it is a bug having the GM simply escalate the ticket to a bug report or copy/paste the description and chat log would not take much time and would likely improve your perceived customer service position.

As it is, after the quick "Submit a bug yourself ... closing ticket ... buh bye" I'm more inclined to come here and GRIPE than I am to figure out how to report a bug.

A bug for a problem that doesn't just concern me, that likely will help Turbine improve the experience for other players. A situation that would improve their product, improve their revenue stream, etc. yet I find myself dis-incented to do just that.



I'll get around to submitting a bug. As it is, I figured out a short-term workaround so that I can be less impacted. It doesn't help the dozens of others out there who are going to hit the same stumbling block but I'll get around to following up on that customer service cycle when I get some more free time and am generally less irritated.

TreknaQudane
10-18-2010, 02:27 PM
One of the missing loops in the customer service cycle seems to be follow-through on part of the in-game support, espescially when dealing with application-specific bugs or errors one would think merit a more general fix.

In the past week I've submitted two tickets. Both were basically admitted to be bugs by the GM, neither were moved on to bug-reports and instead were closed promptly after me asking what the process was to do so.

"You need to submit a bug report" followed immedaitely by "Your GM can no longer receive messages from you".





One of the keys to customer loyalty and good customer service is to make the things you can easy on your customers. You have a ticket system. You have a bug system. When a user submits something as a ticket that they honestly don't know is a bug or not and you tell them it is a bug having the GM simply escalate the ticket to a bug report or copy/paste the description and chat log would not take much time and would likely improve your perceived customer service position.

As it is, after the quick "Submit a bug yourself ... closing ticket ... buh bye" I'm more inclined to come here and GRIPE than I am to figure out how to report a bug.

A bug for a problem that doesn't just concern me, that likely will help Turbine improve the experience for other players. A situation that would improve their product, improve their revenue stream, etc. yet I find myself dis-incented to do just that.



I'll get around to submitting a bug. As it is, I figured out a short-term workaround so that I can be less impacted. It doesn't help the dozens of others out there who are going to hit the same stumbling block but I'll get around to following up on that customer service cycle when I get some more free time and am generally less irritated.

The problem with a GM filling in a Bug Report as opposed to the person that it happens to, is that you know everything you did. They don't. A bug without details is a waste of time. Only you can fill in those details.

voodoogroves
10-18-2010, 02:31 PM
That could be true, if when I submitted a ticket and discussed with the GM I didn't go through all the steps I had done. Then they'd have all the info I did (and in both these cases, did).

I'm not trying to be overly negative; I generally know the kinds of info any front-line support may want to have. I'm rather pointing out that the service model of "front line support tells you to go to second line support yourself" is kinda last-century and rightly so ... as it encourages people to skip front-line support and regards them as tragically useless. That creates poor customer sat / experience, poor downstream product and obfuscates the real issues with service delivery.


EDIT: To respond to your point differently ... should one either
(a) Open a ticket, tell a GM everything, get told to submit a bug then submit a bug with the same info
or
(b) Submit a bug and ignore the ticket / GM path completely

AyumiAmakusa
10-18-2010, 02:32 PM
Or how about we just implement an in-game bug report feature?

Tarrant
10-18-2010, 02:35 PM
Hi voodoogroves, sorry to hear about this issue.

As Trekna said, the biggest problem with your suggestion is that the GM does not have all of the information that you do about the bug. A crucial part of bug reports are the steps required to reproduce the issue. The time you spend telling the GM is time you could be writing the bug report, while the GM is helping someone else.

voodoogroves
10-18-2010, 02:40 PM
There is, and I can resubmit there I using the excellent cut/paste options to pull all the data from the chat I had with the GM, or I could retype it all. I can probably figure out how to cut/paste the ticket info too.


Again, the fact that there are two places I can put stuff isn't the issue - it's the fact that I basically have to double-report the same problem. A problem for which I have a personal workaround. A fix for which will make their product better and everyone else's experience better.

The only reason I'm going to submit a bug is because I don't want my fellow gamers to get bit and hopefully improve their experience. I'm just shocked that for something recognized as an actual issue there's no desire at all to address it as a means of self-improvement.

voodoogroves
10-18-2010, 02:53 PM
Hi voodoogroves, sorry to hear about this issue.

As Trekna said, the biggest problem with your suggestion is that the GM does not have all of the information that you do about the bug. A crucial part of bug reports are the steps required to reproduce the issue. The time you spend telling the GM is time you could be writing the bug report, while the GM is helping someone else.

Yeah Tarrant, I hear you.

Short version though (paraphrased) ...

Me: Submit ticket w/ overview
GM: Hey let's talk, it might be something like this
Me: Ok lemme try ... alright, when I do X, Y and Z it happens and I can reproduce it
GM: Great, submit a bug - sounds like a real bug
Me: Is there no way you can promote a ticket to a bug, maybe capture this chat log where I highlighted all the steps?
GM: Submit a bug. I'm closing your ticket, bye



Why should I ever bother to submit a ticket again?

Don't get me wrong - I love the game, love the forum support and community but the in-game support is pretty tragic. The idea that two people with the same info (GM and player) in order to fix a product bug it should be the player (who is a paying customer) who should drive the issue as opposed to the GM (who is presumably compensated somehow) is a little bit backwards to me.



I'm suggesting a feature that would allow the GM, who likely has much better info and capability to work tickets than I do, to turn a ticket into a bug where appropriate and attach the chat log.

As I said, I have my workaround. I don't need it to be fixed. I can live with it like it is, but I'll report something because I'm not a jerk.

Presumably it will get spotted by others, reported by others and be a drain on GM resources. If one more person submits it in the time we've spent discussing this here because the customer experience made me cranky, was that more or less costly than a system to let a GM promote a ticket to a bug?

jwdaniels
10-18-2010, 03:01 PM
Hi voodoogroves, sorry to hear about this issue.

As Trekna said, the biggest problem with your suggestion is that the GM does not have all of the information that you do about the bug. A crucial part of bug reports are the steps required to reproduce the issue. The time you spend telling the GM is time you could be writing the bug report, while the GM is helping someone else.

I think he already spent time telling the GM, which is how he found out it was a bug in the first place. At which point, leaving the game and typing everything out again is time he could have spent playing DDO and enjoying it...

You really can't /bug in game to do a bug report?

Ducaster
10-18-2010, 03:47 PM
Why should I ever bother to submit a ticket again?

Don't get me wrong - I love the game, love the forum support and community but the in-game support is pretty tragic. The idea that two people with the same info (GM and player) in order to fix a product bug it should be the player (who is a paying customer) who should drive the issue as opposed to the GM (who is presumably compensated somehow) is a little bit backwards to me.

I completely get where your coming from. All that was needed was for the in game GM to hit a control and a bug report window to open for the dialog to be pasted in.

Seriously Tarrant your joking right? What was it you said? "the time the GM would spend reporting the Bug would have been better off helping another customer" Thats a quote from memory and I apologize if its slightly off.

In game Gm's and all front line support staff can't go around shutting off folks trying to help like that, "just in case" there is another soul dieing for their help. Fully help ONE person at a time not **** off one and then (presumably) go **** off a second, paying customer, thats all we ask here.

If the In game GM's are so stressed they can't do that then you need to hire some more of them methinks...

zorander6
10-18-2010, 04:29 PM
No offense but there should be a way for a GM to pass something like this along to higher tiers. Most people won't report a problem twice.

Junts
10-18-2010, 05:16 PM
That could be true, if when I submitted a ticket and discussed with the GM I didn't go through all the steps I had done. Then they'd have all the info I did (and in both these cases, did).

I'm not trying to be overly negative; I generally know the kinds of info any front-line support may want to have. I'm rather pointing out that the service model of "front line support tells you to go to second line support yourself" is kinda last-century and rightly so ... as it encourages people to skip front-line support and regards them as tragically useless. That creates poor customer sat / experience, poor downstream product and obfuscates the real issues with service delivery.


EDIT: To respond to your point differently ... should one either
(a) Open a ticket, tell a GM everything, get told to submit a bug then submit a bug with the same info
or
(b) Submit a bug and ignore the ticket / GM path completely

While this is true in your case, systemically it can't be assuemd to be true.

voodoogroves
10-18-2010, 05:32 PM
Completely agree Junts. I'm a fairly savvy person when it comes to support issues. I'm pretty capable on a PC, w/ various levels of software/hardware/network/etc. diagnosis. I've got a better than average grasp (I think) on how customer service orgs work, would like to work, etc. the ins-and-outs. I've got a pretty healthy fix-it-first myself attitude. Absolutely, I'd like to think that the info I'm giving the person I talk to is better than they get on average and I'm more inclined to go through whatever steps suggested, try whatever, cooperate, etc. to get a resolution.

And I'm a realist. It could be the answer is "those two systems are so completely different and separate that it is really a huge time sink and big integration effort". It could be that they aren't staffed to handle it. I hope it isn't that a GM's valuable time is spent better improving someone else's play experience than potentially improving mine; that sends a bad message.

It could be that because in most cases the GM does NOT have the info and it really is better for the player to submit it and that's simply a policy Turbine enforces on the GMs.

(1) I'm still suggesting / asking for a way the GMs can promote those cases that are like mine. This may or may not be possible. I haven't heard that yet.
(2) I'm still cranky from the "can you ... er ... where'd he go" kind of response ... the IM/tell equivalent of kthxbybye hang-up.




Either way, that's fine. I'm an informed consumer; I'll just never submit a ticket again and go straight to the bug report instead. I'm fairly confident I can do my own traige. Kinda like calling an IVR and mashing zeros and pound signs to talk to someone because you don't want to waste your time on the menu.



I can imagine the back office conversation when I submit my next bug-report/non-ticket.

"Who is this jerk? Didn't he submit a ticket? A GM can handle this ... good grief, doesn't he have a clue? Doesn't he know he'll get better support that way and that he's wasting all of our time this way?"

No, I don't know that. I know that submitting the ticket just to have to redo everything for a bug report is wasting my time, and I'm not likely to repeat that.

Bozone
10-18-2010, 05:47 PM
Seems to me that a GM would be better able to make sure the bug report contains all of the information needed. Rather than relying on a user to provide all of the information properly, they could ask a few questions to make sure it is a good bug report.

Missing_Minds
10-18-2010, 06:41 PM
Seems to me that a GM would be better able to make sure the bug report contains all of the information needed. Rather than relying on a user to provide all of the information properly, they could ask a few questions to make sure it is a good bug report.

*smirk.. snicker... LAUGH* Work help desk and TRY to get users to actually tell you the information you need.

Pugsley
10-18-2010, 07:59 PM
They have to pay GMs for the time it takes them to fill out a bug report.

You pay them for the time it takes you to fill out a bug report.

voodoogroves
10-18-2010, 08:05 PM
They have to pay GMs for the time it takes them to fill out a bug report.

You pay them for the time it takes you to fill out a bug report.

I pay them either way; I'm not F2P. One increases customer satisfaction, loyalty and retention rates ... one does not.

EricZanzibar
10-19-2010, 03:24 AM
in the words of chopper "harden the f..." I better not :-S

Voodoo, the GM's are busy. Stop being so soft. Rest of you whineing about this as well! Fill in the damn ticket. Man up. They are very busy people. If THEY did a ticket every single time as opposed to the individual doing the ticket it would take AAAGES for them to get around and help people.
So submit the ticket, stop whining and enjoy the game! Gah!

voodoogroves
10-19-2010, 07:39 AM
in the words of chopper "harden the f..." I better not :-S

Voodoo, the GM's are busy. Stop being so soft. Rest of you whineing about this as well! Fill in the damn ticket. Man up. They are very busy people. If THEY did a ticket every single time as opposed to the individual doing the ticket it would take AAAGES for them to get around and help people.
So submit the ticket, stop whining and enjoy the game! Gah!

No doubt the GMs are busy Eric. So am I. As it happens, through a variety of means, I am paying for their time. I hope they are busy doing what is best for my dollar.

You are actually saying exactly what I'm suggesting is the expected behavior of this kind of CS policy - that the customer ignores the GMs and just submits bugs. You are providing a perfect example - I'm not sure you intended to be the straight-man, but your "ignore it" reaction plays just the way I described above.

I am suggesting a policy change that simplifies the process, saves some time and improves customer sat.

If you feel that is a whine, you are entitled to your opinion. Thanks for sharing it here.

Drina
10-19-2010, 09:54 AM
I agree with the OP. If I just spent time filling in an in-game support ticket and was just told to submit a bug ticket I would be less then trilled to redo what I had just done.

I think a good suggestion would be to have the GM take my ticket and turn it into a bug report. Something along these lines.

GM: Yes this is a bug...I have changed this ticket into a Bug Report. Please use the following Bug Report number (123456) to finish filling out information not in you original ticket and submit the bug report. Thank you.

Now I have the information I already typed out in there and I don't need to redo everything. I just need to fill in what information was missing and submit it. If I don't submit this report it gets closed out and doesn't become a bad bug report cluttering up their email.

Feeling like the company is working with me will get me to finish a bug report than just ignoring it.

systemstate
10-19-2010, 10:14 AM
I agree with OP as well on this. The customer should not have to fill out another form with redundant information simply because the trouble ticketing system does not have the correct format or distribution path for the developers.

This is a back-end problem that should be taken care of by Turbine. The customer does not need to be the work-around for information dissemination to Turbine employees.

EricZanzibar
10-19-2010, 11:39 AM
No doubt the GMs are busy Eric. So am I. As it happens, through a variety of means, I am paying for their time. I hope they are busy doing what is best for my dollar.

You are actually saying exactly what I'm suggesting is the expected behavior of this kind of CS policy - that the customer ignores the GMs and just submits bugs. You are providing a perfect example - I'm not sure you intended to be the straight-man, but your "ignore it" reaction plays just the way I described above.

I am suggesting a policy change that simplifies the process, saves some time and improves customer sat.

If you feel that is a whine, you are entitled to your opinion. Thanks for sharing it here.


Actually I'm sorry for speaking that way voodoo. It was a tad rude. I'm normally abrupt with people but it went too far. So, sorry. :-(
Back on track though I'm not saying ignore the issue and carry on I am saying submit a bug report, don't leave it for the DM who I'm sure has a cue of other people to see.
Modern society is one where people 'expect' to served by someone. Take some responsibilty and make the effort to improve the game yourself as opposed to expect others to do it for you. I'm a paid member too.
So, Devs, i say just carry on this policy. People will moan and whinge but it does not detract from the mass of good work that is done.

voodoogroves
10-19-2010, 12:26 PM
Actually I'm sorry for speaking that way voodoo. It was a tad rude. I'm normally abrupt with people but it went too far. So, sorry. :-(
Back on track though I'm not saying ignore the issue and carry on I am saying submit a bug report, don't leave it for the DM who I'm sure has a cue of other people to see.
Modern society is one where people 'expect' to served by someone. Take some responsibilty and make the effort to improve the game yourself as opposed to expect others to do it for you. I'm a paid member too.
So, Devs, i say just carry on this policy. People will moan and whinge but it does not detract from the mass of good work that is done.

No worries mate, I've got a pretty thick skin.

I'm not sure my expectation is to be served, but a multi-step process with no-handoff and repeat steps turns into a single step process in a very Pavlovian way.

1. Open Ticket
2. Work through w/ GM
3. Told to Open Bug
4. Open Bug

Can be simplified from a customer perspective to:

1. Open Bug

It's unfortunate, it diminishes the value of the GMs and it encourages people to open a bug report first. This means the diag which may need to be performed will be done by a dev instead of a GM. I'm not sure what the compensation structure is there or the availability of the different resources, but I'd wager that the dev is a more constrained resource ... as it adds:

2. Work through w/ Dev




If we assume I'm awesome and the Dev has all the info they need, this saves everyone time. If instead we assume 90% of the time this won't be the case then the Dev has additional work. It only takes a few iterations of the troublesome first process to make provide incentive for the customer to use the 2nd. Then what you've done is shifted work from your GM to your Dev.

smokeyser
10-19-2010, 03:46 PM
It's unfortunate, it diminishes the value of the GMs and it encourages people to open a bug report first.


But you're assuming that it's a GM's job to take bug reports. They're more like the ref at a football game. Their job is to watch the players. The QA team and devs are the ones who handle bugs. Totally different groups of people. If you had a problem with your bank account, you wouldn't demand that the security guard watching the door do something about it, would you?

voodoogroves
10-19-2010, 05:03 PM
No, but to use your analogy the flip-side is to incent people to report all problems to the tellers because the customer service process is cumbersome. I'm not demanding anything of anyone.


What you're suggesting is that there are two paths, and the person must choose: (a) ticket or (b) bug. This could be valid, completely. It assumes, however, that GMs do no triage and the onus is on the player/consumer. It would also assume that it should be very easy for the common player to determine which should be which.

In reality, many people view the process as 2-step. (1) Ticket first, then possibly (2) bug report. I suspect (1) includes some knowledge of known issues to help prevent unwanted bug reports ... some sort of filtering.

I'd be moderately interested to see how Turbine imagines it.



Your analogy assumes that after being told by the security guard a few times that he really really can't help me and I need to talk to a teller, that me or any of the other average customers out there are going to keep talking to him. If the security guard can never help me, I'll go to the teller first ... so no longer an A/B but instead a 2 step process where I'm basically skipping step 1. My opinion of the security guard is that he's nice and always says hello, but really and honestly can't do anything to help me. Skip.

Again, this is very similar to the classic customer support IVR menu problem. The menu on that phone is there to help collect information and triage your problem to the right person. If you select parts, you go to parts. If you select service, you go to service. If you select parts but are repeatedly told that you need to hang up and call back and choose the service number your likelihood of selecting parts ever again EVEN IF IT IS A PARTS ISSUE diminishes. If no matter what choice you pick you find you are always being transferred, the customer is likely to choose options at random to get to a person and that eventual transfer faster.




So again, spot on. Your advice is to stop asking the security guard. Fair enough, though that leads to the teller (but report) getting things that I'm sure they'd likely have triaged by the man at the door first.



I'll go with your logic though for fairness sake ... what are the steps the players should do anytime they see something so they know to submit a ticket or a bug report as their first step? How should they know? What criteria should we use?

smokeyser
10-19-2010, 05:29 PM
Simple. If you're reporting inappropriate actions by other players, tell a GM. If you're reporting a bug, submit a bug report. No matter what logic is given and no matter how badly we want it to be otherwise, GMs and the QA staff are two completely separate teams. They don't do each other's jobs. If management wants GMs to start filtering bug reports then they'll pass bug reports along to GMs. Going back to the previous analogy, do you really think that a well reasoned arguement presented in a convincing way is suddenly going to turn a security guard into a teller? Coming up with a good reason why you think GMs should be part of the QA team doesn't make them part of the QA team.

GMs are like referees. They know all of the rules that we're expected to follow, and how to enforce company policies. But they're not programmers and they don't have anything to do with finding/fixing problems with the code. Even if they wanted to help, most don't have the training needed to do so. All they can do when you're having a problem with bugs is point you in the right direction.

Think about what you're asking for... You want GMs to stop doing their job every time you have a problem and go do someone else's job for a few minutes instead. If everyone submitted their bug reports through GMs, who would do their job while they're busy filling out those reports? I'm not saying that it wouldn't be better that way. It would be convenient for us. But it's not the way their support system is structured.

voodoogroves
10-19-2010, 08:07 PM
Awesome. I'll bite. I'll ignore the QA<>bugs thing.

Either the GM / Ticket system serves as a filter/triage or it doesn't.

If it is meant to do so I would kindly ask that:
(a) when the GM has the same info as I do and a bug report is required, I'm still requesting a process/tool change to allow them to do so
(b) when the GM is at a total loss and it needs more detailed focus, I'd still ask they submit the but report with a note to follow up for more info and I'd be happy to provide it.


If it is not meant to do so please ... educate all customers so they know when to use the system or not. Also please remove any and all problem categorization that might be misleading. If I need to make the distinction between in-game support and a bug report, just tell me what criteria to use and I'll follow it.



Honestly, it sounds like you have some sort of tribal-knowledge, once-bitten concept of what GMs are supposed to do and not. I envy you, in that you have a clarity I lack. Can we get that distilled on a loading screen? Otherwise, I'm running blind based on the interfaces in "create a ticket" ... and that means something different to a new-ish person to the support process than someone who's been through the ringer a few times. Maybe "submit a ticket" means something specific that I, the unwitting consumer, don't quite comprehend yet. I see it as more general, yet it is really specific to only language abuse, stealth-jumping and other ******baggery.

If that is true (and there are some unwritten understandings about what GMs do and not) and after I've been through the pain a few times I'll figure it out ... well, we're back to my point after all. Stop talking to the security guard.




I don't care who's job it is. You can tell me I'm foolish for not knowing who's job it is - that's fine. Educate me. Tell me how I was supposed to know that ahead of time. Let's not perpetuate the problem. I'll go with that.




But if GMs do provide some sort of filter / triage for the devs ... well ... not sure where your point sits then.





(Please understand, I'm done with this - I have my workaround. In pursuing this I'm trying to make DDO and every person's experience better. I'm not trying to whine, but I am addressing each person who replies to my thread with what I see as a response to their commentary).

Chaosprism
10-19-2010, 08:23 PM
When somebody uses the /stuck command, does the location get logged somewhere so somebody can check it out and fix it later? If not thats a must do.


If a g.m fixes a problem umpteen times, surely they themselves would submit a bug report. A particular quest fails to complete in the same way many times, a crucial plot item doesnt drop or a kill isnt counted in a required kill tally. Sometimes a plot creature dies without it being counted, so a g.m has to respawn it.

Juppstein
10-20-2010, 05:55 AM
When somebody uses the /stuck command, does the location get logged somewhere so somebody can check it out and fix it later? If not thats a must do.

If it is as with other games then the location where /stuck was triggered will be logged but there is probably no message being sent to anyone. It will just be an entry in a database. I could imagine that once per week or month (or even more regular just after a new update came out) someone will query the database and create a report about all /stuck and their location. From there on it should go through the regular procedures for bugs/issues/problems.