Appalling service on tech support - failed twice because you didn't check your logs in time

[#1]

I've decided to post this into the Feedback forum because I'm getting nowhere with technical support, and I'd welcome someone from PN who can see the underlying issue to look at it.

In January this year I got a few emails sent from multiple mailboxes to my home PN mailbox bounced by the PN Avast servers, marked as spam. The connecting theme seemed to be that they all originated from Office365 accounts. Despite spending a lot of time in chat, on the phone and by email to get it resolved, PN failed completely to look at the problem in time. This meant the log files they needed to check were overwritten.

On 9th May the same thing happened again. I spent a lot of time again in chat explaining to one of the PN agents what had happened this time and what happened in January with a failure to look at their log files in time, and he assured me this would be looked at by the Net Admin team within a couple of days. This has now sat in the call stack despite me chasing it until - once again - it's missed its deadline for the logs being overwritten.

When an issue is known to have a time criticality to it, surely it's not beyond the wit of someone in technical support to spot this and at least extract the required logs for future review? I'm now in the position of feeling distinctly uncomfortable about whether other emails are simply going missing (without me ever knowing) because they're being bounced unnecessarily by the PN Avast servers.

[#2]

Hi @inkymortar, thanks for your post.

We're sincerely sorry to hear that this has happened.

With regards Tech Support - Our advisors don't have the facility to manually pull email logs, they have to send a request of to our NetOps team and unfortunately there is sometimes a delay in them receiving a response, which is of course less than ideal.The process is much the same for the Social Media staff operating on the forum.

By all means, we can re-raise the relevant task with NetOps to try and find out why this keeps happening and I will ensure that feedback on this process is left, to avoid vital logs being overwritten in future.

[#3]

I wasn't expecting the advisor to pull the email log - if you look at my original post you'll see the advisor stated in the chat that it would need to be referred to NetOps (referred to as Net Admin in the chat). If you're unable to join different parts of your support team together how are customers expected to get a reasonable response?

This still leaves me in the position of reaching a dead end again, and absolutely no confidence that when it happens next time you'll be capable of investigating in time.

[#4]

Hi @inkymortar,

The pool that the issue was raised to isn't maintained and prioritised as much as raising a task will be. When the issue re-occurs, let us know as soon as possible and we will raise a NetOps task. I'm sorry that this hasn't been raised in the correct way previously and I have added a note to the ticket confirming to raise a task should the issue re-occur.
 

Thank you.

[#5]

Lewis/Jubby;

I appreciate your efforts are well meaning, but they don't help to resolve this issue.

Your advisor team won't want to keep the existing call open indefinitely until this intermittent issue happens again. Putting "INTERNAL - raise infops task if the issue re-occurs" will be of no use once the call is closed; it will just disappear with the rest of the call history. We will return back to the beginning, and (based on previous experience) I'll raise a call the day it happens and no-one from PN will look at it until after the log files are overwritten. I was assured this time that the call would be investigated in time, but it wasn't.

For issues where there is a time-critical element, your processes need to change to ensure they don't fall through the cracks. I appreciate you deal with a high volume of calls and everything needs to take its turn, but if necessary information isn't collected at appropriate points the call can't be investigated properly.

[#6]

Hi @inkymortar 

Our process tells us to raise a NetOps(Network Operations) task, I'm sorry that this was not done when you got in touch with a live chat adviser. I've arranged for feedback to be passed on to the adviser.

When/if the issue occurs again feel free to let us know over here (we can ask you to provide the logs via PM) and we'll be happy to raise the task ourselves.

Hope this helps.

[#7]

In that case please investigate this particular live issue further. The chat adviser said he'd raise a task on NetOps. So either:

• The task wasn't raised
• The task was raised but your processes don't reflect the need for some issues to have a time-critical element explored within timescales your team will be aware of (deletion of log files)

[#8]

As per my previous response, the task was not raised and feedback has been passed on.

I do sincerely apologise for the experience you've had on this occasion.

[#9]

This has occured again yesterday and today. How do I raise a support call with you so you're able to deal with it inside your own NetOps timescales?

[#10]

Thanks for getting back to us @inkymortar 

Could you PM me the email address you're sending from, the email address you're sending to, the bounce-back message you get as well as a copy of the full headers if possible so I can raise a NetOps task to investigate further?

[#11]

This has been sent in PM to you

[#12]

Cheers, I'm picking it up now

[#13]

@inkymortar Just as a heads up I've added a reply to your ticket Here and PM'd you regarding this. We need a copy of the message in a txt format that's bouncing back. Could you add this to the ticket when you get a chance? Cheers

[#14]

I've added that to the ticket in text-readable PDF format. Let me know if you need anything else

[#15]

Cheers, I passed that on and I'm just waiting to hear back