fault ticket script dead end if a speed issue

[#1]

Trying to use the Report a Broadband Fault for my speed issue this morning, but it dead ends after confirming my connection works in the test socket, of course it does I am reporting a speed issue not a connection issue.

[#2]

Hmm, apologies for the daft question but you did choose speed issue when you chose the fault type? If so then I'd mark it down as not working in the test socket (i.e. it's still slow) - unless it isn't, in which case unlikely as it seems the speed issue is probably caused by your internal wiring 😕

[#3]

yes speed fault, with the amount of loss on my line at the moment it took me 20mins just to get through the script

[#4]

I strongly suspect the faults troubleshooter is seeing the recent connection drops on your line (it queries our RADIUS tables) and is forcing you down the intermittent connection route.

Session Started	Session Ended	Session Duration
10:25 07/Nov/2012	N/A	 One Day, 6:12:2 (on going)
12:40 06/Nov/2012	10:24 07/Nov/2012	  21:44:8
12:37 06/Nov/2012	12:39 06/Nov/2012	  0:1:53
12:35 06/Nov/2012	12:35 06/Nov/2012	  0:0:18
12:31 06/Nov/2012	12:35 06/Nov/2012	  0:4:0
10:53 06/Nov/2012	12:30 06/Nov/2012	  1:37:23
10:45 06/Nov/2012	10:51 06/Nov/2012	  0:6:41
10:36 06/Nov/2012	10:44 06/Nov/2012	  0:7:56
13:47 05/Nov/2012	10:35 06/Nov/2012	  20:47:51
11:46 05/Nov/2012	13:45 05/Nov/2012	  1:59:35 

[#5]

Most of those were manual, only had 2 lost syncs recently I had no control over, but I did do some gateway hopping to see if it was a overloaded one.

[#6]

That wouldn't matter Gus. If the RADIUS tables show drops then the faults troubleshooter does that, irrespective as to what caused them.

[#7]

Then the fault troubleshooter is wrong - it should ask something along the lines "Your line has had a lot of disconnections recently, have you been initiating reconnects or restarting your router?"

[#8]

That was considered in the early drafts but we wanted to keep things as simple as possible, and that would have entailed a whole raft of explanations and new routes for further questions 😕

[#9]

Quote from: Matt

That was considered in the early drafts but we wanted to keep things as simple as possible, and that would have entailed a whole raft of explanations and new routes for further questions 😕

As a consequence it causes customer confusion - as in this case?
Maurice

[#10]

Yes, indeed - the first time this has happened to my knowledge since the wizard was introduced around two years ago (iirc)? I don't think that's a bad record.

[#11]

Rule of thumb if it can happen it will.

[#12]

Gus,
Sometimes you just have to tell white lies to the wizard and leave Plusnet to take the consequences.
It doesn't work in the test socket because you still have a speed issue when using the test socket!

[#13]

I doubt it's the first time it's happened, it's probably just the first time it's been raised on here because someone who knows better has encountered it.
The checker should ask, possibly the last question for the user to confirm that the type of fault is what the checker has decided, and given the option to change it when wrong eg. in this case it should ask -
"Please confirm this is a 'Disconnection' problem you are raising Yes/No."  and when "No" then present the question -
"Please confirm this is a 'Speed' problem you are raising Yes/No."  because that is what the user chose first!! If they answer No again then -
"Please type here what you think the problem is"

[#14]

The logic was introduced based on the volume of intermittent connectivity faults that were raised incorrectly by customers thinking they had a speed fault (because that's how they perceived the symptoms).
The system hasn't always worked this way, the logic was introduced to aid automation, minimise the potential for confusion and avoid the need to bounce tickets unnecessarily between internal ticket pools.
Asking the customer to confirm whether or not the problem is disconnection-related removes benefit of this behaviour entirely.
There will be instances like this one where the situation isn't ideal but that's countered by the reduction in intermittent connectivity faults that are incorrectly raised as speed faults.