Zen, Premium Price, Plusnet Service

Open letter to Zen

Dear Zen

You tell us you're an amazing ISP. You tell us you're great, you command a premium price, you win all these awards. Your support people tell me that there is no script.

I spend several days calling you discussing a fault where a line has a regular issue where PPP - but not sync is being lost. We discuss the scenario, you suggest we try PPPoE, we do. You suggest we change to LLC, we do.

The problem remains.

The phone line is fine, it meets the relevant spec, it passes a copper line test.

The broadband service isn't working though, which you provide. You use your own DSLAMs from Zyxel. You don't use BT Wholesale on this line for the circuit - and you've already told us this (but we already knew).

We'd like you to investigate and find/fix the cause of our PPP loss issue. I'd like you to stop asking me to agree to engineer charges (eg for an SFI2 visit) I neither require nor need to get this fixed, which ultimately doesn't fix the PPP issue, and BT plc t/a Openreach won't be much help, nor will BT plc t/a BT Wholesale since you're using your own DSLAMs you'll need to fix it and investigate at your own expense. That is after all the deal we agreed to - I pay you for a service, you provide it.

It's a simple arrangement.

Therefore is there any chance you can stop me getting pretty annoyed (not ideal, but there are only so many times you can be fobbed off) and insisting I agree to the potential of charges (eg for SFI) when the problem has sod all to do with an SFI-fixable issue.

Yours,
The Paying Customer that won't agree to potential charges that are irrelevant and doesn't appreciate your refusal to investigate otherwise.

Edited by therioman (Wed 22-Feb-17 20:27:34)

Thank you for your message.

We are sorry to hear of the frustration that you have been experiencing with your connectivity.

We do take on board your feedback, and are working with you to rectify the issues with your current PPP performance.

In cases where a fault / issue is more severe, we may recommend that a BT / Openreach engineer makes a site visit, in this case we will then provide our customer with all of the necessary information.

We of course want to avoid our customers having to outlay unnecessary costs, and therefore always firstly advise customers to carry out a full diagnostics check � in most cases the reported issue can be resolved in this way, and an engineer visit will not be required.

In cases where the fault / issues cannot be resolved in this way, then we would recommend a site visit from an engineer. We will always advise our customer of any potential charges that could be incurred as a result of this. The customer would only be liable for this charge if the fault is found to be with the customer�s equipment or domain, which is standard practice regardless of the service provider you use for your internet connectivity.

We remain committed to helping you to resolve your issues as soon as possible. If you could please direct message your account details we will speak with the current issue owner and ensure everything is being done to progress your issue forward in the correct way. We will have them contact you to move this forward.

Regards,

Zen.

Ajays unless the op is also losing the DSL carrier or having a severe burst of noise that's so bad it's doping enough of the LCP packets for the session die (I'd argue the more likely outcome would be total loss of sync at that point) then I fail to see what purpose having openreach investigate the Metallic pair would be.


If this is indeed an LLU dslam you need to investigate it and your backhual network LAC, LNS and Radius rather than the OP's copper pair

Can you post dsl line stats from the router?

Edit to clarify: on a long line with no physical fault and otherwise stable sync ADSL2+ can cause errors and PPP drops, so worth looking at as next step

Edited by deleted (Fri 24-Feb-17 11:29:29)

In reply to a post by dragon2611:

Ajays unless the op is also losing the DSL carrier or having a severe burst of noise that's so bad it's doping enough of the LCP packets for the session die (I'd argue the more likely outcome would be total loss of sync at that point) then I fail to see what purpose having openreach investigate the Metallic pair would be.

If this is indeed an LLU dslam you need to investigate it and your backhual network LAC, LNS and Radius rather than the OP's copper pair

Incidentally, as I told Zen on my very first call, many weeks ago, the resolve was to get a Tie Pair Modify (eg Port Swap) done. This is something I would have expected Zen to identify in minutes, not weeks.

I've had to fart [censored] around with PPPoE over PPPoA "just in case", interleaving on, INP adjustments, and god knows what else, plus many many many phone calls and interactions with Zen.

Zen desperately needs a way to move support cases forward with more clue than I have seen with this case. It is at least now resolved, but after weeks rather than hours.

What is a Tie Pair Modify please?

Is this swapping over the copper pair to a new port at the DSLAM?

Jon

In reply to a post by cleeve555:

What is a Tie Pair Modify please?

Is this swapping over the copper pair to a new port at the DSLAM?

Jon

Pretty much.