| th3razzer |
Let me preface: I've been viewing the threads for quite a while now since the temporary suspension of the phone lines.
Why is it that more recent threads are being resolved, but threads like mine are slowly moving towards the bottom with no resolution? Supposedly it's going from bottom-up, meaning that older threads will receive their resolutions first (makes sense, clear the back-log and all), but more recent threads are reaching their resolution, whereas I've sent multiple emails (spaced apart by many business days) with only an automated response to the email after maybe the 4th email?
I then decided to post here, since it seems resolutions are coming faster than email, and yes, I did bump my own thread, but before reading the above linked post. However, even then, newer threads are being resolved within hours of posting, and they're for roughly the same thing that I need help with.
How does this make sense? I wouldn't imagine reactivating suspended subscriptions is all that difficult? Why do threads above and below mine have resolutions, but I'm all but ignored?
| Anguish |
Why do threads above and below mine have resolutions, but I'm all but ignored?
I absolutely don't represent Paizo, but I'd like to try to at least speculate.
My best guess is that you're looking at triage. I imagine given a backlog of customer-service issues, there most likely is a more nuanced approach to closing issues than a simple FIFO (first-in, first-out) queue.
What I mean is, imagine if there's an issue which is a week old and will require eight man-hours to resolve. Then there are eight issues which are six days old, but will only require one man-hour each to resolve. It becomes sensible to at least consider spending a day clearing out the eight issues that are only slightly less aged. While neglecting the time-intensive task indefinitely isn't acceptable, deviating from strict FIFO has the best overall results.
Similarly, imagine a case where the warehouse is in the process of sending out a month's regular subscriptions over the next three business days. In the support queue are twenty requests which is are a week old, asking for reactivation of a subscription. There are also ten requests which are only six days old, which ask for cancellation of subscriptions. In this case, it is urgent to handle the cancellation requests first. The consequence of failing to cancel within the crucial next three days is that a customer is billed after logging a cancellation, resulting in lost product because Paizo would likely have to refund the shipment and probably wouldn't request it be returned. The consequence of failing to process the activations within the next three days is that those customers will get their brand new shipments after the existing subscriptions are handled... likely on day 4. The activations can realistically be processed any time in the next three weeks without impact beyond "I wanted this product sooner".
There are also some issues which aren't possible to complete immediately. There could be database problems or other blocking causes which make tasks normally completed by single keypresses impossible to complete until some other team addresses the blocking causes. Customer Service would need to defer those issues while waiting for other teams to fix those causes, or the causes are otherwise resolved. While waiting for that, they would move on to other issues which might be newer, but can be completed during the wait.
Your request is probably "handled" in the sense that the CSRs are aware of it and have triaged it into a category to be acted on at a time "appropriate" to its severity, feasibility, and other factors I haven't thought about.
These are only a few examples of possibilities I can imagine behind out-of-queue issue resolution. I can't possibly know the specific answer for your case, and I know this doesn't change your circumstance, but hopefully it at least illuminates how logistics can be more complicated than it seems, and how a post saying "don't bump threads" likely shouldn't be taken as indicating issues are closed solely based on time.
Bumping a thread moves it to the top, which ensures it won't be handled next. Not bumping a thread leaves it at the bottom, which keeps it where the CSRs will be looking for issues to triage... if not actually immediately close.
In closing, I wouldn't normally post general logistics commentary and speculation, but I know that I have the time on my hands, that Paizo is closed for the weekend, that frustrations are building, and that time is extremely precious for the CSRs these days, so if this is even slightly helpful to you, or them, or both, it's worth it.
Best wishes and stay well.
| th3razzer |
th3razzer wrote:Why do threads above and below mine have resolutions, but I'm all but ignored?I absolutely don't represent Paizo, but I'd like to try to at least speculate.
My best guess is that you're looking at triage. I imagine given a backlog of customer-service issues, there most likely is a more nuanced approach to closing issues than a simple FIFO (first-in, first-out) queue.
What I mean is, imagine if there's an issue which is a week old and will require eight man-hours to resolve. Then there are eight issues which are six days old, but will only require one man-hour each to resolve. It becomes sensible to at least consider spending a day clearing out the eight issues that are only slightly less aged. While neglecting the time-intensive task indefinitely isn't acceptable, deviating from strict FIFO has the best overall results.
Similarly, imagine a case where the warehouse is in the process of sending out a month's regular subscriptions over the next three business days. In the support queue are twenty requests which is are a week old, asking for reactivation of a subscription. There are also ten requests which are only six days old, which ask for cancellation of subscriptions. In this case, it is urgent to handle the cancellation requests first. The consequence of failing to cancel within the crucial next three days is that a customer is billed after logging a cancellation, resulting in lost product because Paizo would likely have to refund the shipment and probably wouldn't request it be returned. The consequence of failing to process the activations within the next three days is that those customers will get their brand new shipments after the existing subscriptions are handled... likely on day 4. The activations can realistically be processed any time in the next three weeks without impact beyond "I wanted this product sooner".
There are also some issues which aren't possible to complete immediately. There could be database problems...
While illuminating, your briefing is not a topic I am wholly unaware of. I understand that there is much more "under the hood" than is immediately visible or apparent.
That being said, the reason that I posted this was to get CSR eyes-on, as I'm watching orders that share the lack of "time-sensitivity" being addressed and solved, all inside of a mere hour of it being posted. I mean to point out the threads/posts that request minor research into the current status of an order, a modification to an order (such as adding/subtracting items), and the like. Cancellations are time-sensitive and overall I don't consider it abnormal that they would be resolved as soon as humanly possible, for the very reasons you listed above.
It would make the world of difference for a CSR to simply respond to it and notify me that, yes, my thread/post has been seen. It's a very anxiety-filled experience to watch your thread "tick" its way to the bottom little by little, all the while similar threads are resolved at the top almost "instantly." This also has *no* guarantee that it's been seen whatsoever - hence why I added the linked text to use the words of CSRs themselves to ask the fundamental question to my problem: if calls, emails, and posts can't get my issue seen, what will? I can't imagine it is very difficult to reactivate a subscription, since that's taking it out of suspension. As Paizo reps have explained to me, all of the products during the suspension stack-up and are all shipped upon reactivation, so it really sounds like a database is handling this "queue." Wouldn't it be a pretty fair assumption to make that hitting "reactivate" (or similar 'button') would... reactivate it? Send all those products on their way?
| Joan H. Customer Service Representative |
Hi th3razzer,
Thanks so much for your patience. In the past few days I have been the primary person to reply on the forums so I thought I'd take a minute to reply as I know that you are not the only person here who has been waiting quite a while for a response from our team.
Our intent is never to make anyone feel overlooked and I'm sorry that our forum triage implied this. We currently only have a team of 4 working through an inbox with over 600 emails dating back to February 26, as well as the CS forums. We're doing our best to get to each request as quickly and efficiently as possible.
March subscriptions have begun shipping so I've been prioritizing cancellations as well as some orders that seem to have been placed in early-to-mid February. Around that time, we rolled new code that caused some hiccups in shipping. I'm investigating any orders I believe may be outstanding February subscriptions and having those combine and ship out with March subscriptions. While our warehouse was able to get the vast majority of them shipped, I'm making sure these are taken care of out of an abundance of caution. I apologize that this made it seem like I was ignoring your request.
Those specific instances aside, I'm currently working through forum threads posted at the beginning of last week. I anticipate getting through the queue today or tomorrow. Since I'm here and have already looked through your request, I have gone ahead and unsuspended your subscriptions. I'll detail the products and order number directly in your original post. Thank you!
| th3razzer |
Hi th3razzer,
Thanks so much for your patience. In the past few days I have been the primary person to reply on the forums so I thought I'd take a minute to reply as I know that you are not the only person here who has been waiting quite a while for a response from our team.
Our intent is never to make anyone feel overlooked and I'm sorry that our forum triage implied this. We currently only have a team of 4 working through an inbox with over 600 emails dating back to February 26, as well as the CS forums. We're doing our best to get to each request as quickly and efficiently as possible.
March subscriptions have begun shipping so I've been prioritizing cancellations as well as some orders that seem to have been placed in early-to-mid February. Around that time, we rolled new code that caused some hiccups in shipping. I'm investigating any orders I believe may be outstanding February subscriptions and having those combine and ship out with March subscriptions. While our warehouse was able to get the vast majority of them shipped, I'm making sure these are taken care of out of an abundance of caution. I apologize that this made it seem like I was ignoring your request.
Those specific instances aside, I'm currently working through forum threads posted at the beginning of last week. I anticipate getting through the queue today or tomorrow. Since I'm here and have already looked through your request, I have gone ahead and unsuspended your subscriptions. I'll detail the products and order number directly in your original post. Thank you!
Thank you for your reply. My intent was never to bash or speak ill of any CSR, and I can imagine a team of 4 is not quite the force you need to handle hundreds of backog inquiries, not to mention the ones appearing by the numbers.
Unforunately, sometimes the addage of the squeaky wheel and grease holds true, and so if I didn't speak out my personal belief is I don't have much of a right to have "hurt feelings" or opinions. I usually try to wait several business days before asking for any sort of spotlight.
I hope I've caused no offense or bad taste in the mouth, since I know you and your team are doing all you can and I'm very appreciative to your response.