MickeyD
RIP
Cable fault in area. No service for 3 days. Phoned Telkom and requested a refund. Refund appeared on next account.
-
Join the MyBroadband community
South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
-
Question of the Day: Do you bet on sports?
Shocking service from OpenWeb
- Thread starter fluffypony
- Start date
Ok, thats new. AFAIK that was near impossible. Do you have a SLA with them?
Exactly the sort of service that made me leavew OpenWeb a couple of years ago. I see Keoma hasn't changed.
Exactly. Why charge him for a service that he hasn't been able to use? So OW take a full month's cut for a few Mbs?
Exactly. Why charge him for a service that he hasn't been able to use? So OW take a full month's cut for a few Mbs?
I request a refund every time our business or home line goes down.
Mine was with Telkom as well. Recently. Just because other companies don't process refunds does not mean that it should apply across the board. Refunds, as any customer and business owner knows, need to be addressed on their unique merits, and not by a flat-batted, unfair policy that involves the consumer signing away their legally protected rights...
And they do it?!!?
:wtf: The fksers owe me a fortune then!
Thanks for correcting my ignorance on this. Bastards! Do you also get it for a flapping line and connectivity related issues?
I've also gotten a refund from Telkom when ADSL was down in the area for around 5 days.
Afrihost was always a good example of refunds if you weren't happy with the service, not sure if they still do it.
Afrihost was always a good example of refunds if you weren't happy with the service, not sure if they still do it.
fluffypony
Well-Known Member
- Joined
- Jul 3, 2009
- Messages
- 214
- Reaction score
- 7
Nookie - I appreciate that it happens. We had an issue recently where a heavy duty Juniper switch was acting up; after a lot of config tweaks someone had the bright idea to try swap out the switch with the exact same model (we had one in an unused rack just next to it), and voila - the same config worked. Here's the difference between this situation and that one: we placed one call to Juniper, and they sent a technician to the data center to swap the faulty hardware with brand new hardware, even though we'd had that unit in the store room for over a year. I would welcome it if OpenWeb said "sorry buddy, this is a Telkom issue and it can't be fixed, here's your money back", or "this is a Telkom issue, here is what you need to do to fix it." Despite their claims to the contrary, they provided no advice on resolving this, and I think their attitude in this thread speaks for itself.
It's a fine balancing act. You cannot simply cave to every public claim made and refund on the principle of being afraid of poor PR.
On the other hand, when a customer has a legitimate complaint, as fluffypony absolutely does, hiding behind your Ts&Cs is pathetic beyond belief and reflects incredibly poorly on OpenWeb's part.
I'm glad OpenWeb's test account ended up being slower than Axxess' vanilla uncapped account. I think I made the right move. When I questioned changing packages Axxess didn't bat an eyelid, they simply pro-rata's things for me. When I didn't receive my Telkom installation on time, even though the account had effectively begun, they agreed at no cost to me to delay it.
Companies will fail dismally when they hide behind Ts&Cs to justify no refund policies, which are in fact contrary to CPA regulations. It doesn't matter if the fault is yours or not - you have an unhappy customer who would have gladly stuck around had you met him half-way, but instead you lost him and twenty potential customers by being morons about it all, when addressing a matter that has zero bottom-line impact if you make allowances.
If you want to do business in the public domain and reap the rewards of being a noted service provider on these forums, then expect backlash as well when you act like imbeciles and demand that a customer pay for a service that he never received, and that appears to be an account-related issue, and where the customer has done everything you have asked of him...
I'm not saying cave to every claim.
This is what I was saying. OP has a legitimate problem here, and according to him has used very little OW bandwidth and has been charged a full month's fee.
Not fair imo, and OW's stance in this thread isn't doing them any favours.
Spot on. Nailed it.
Why would cause one account at an ISP flap and none of the others?
Normally with an ISP issue its a 1 or a 0. Either all the accounts are affected or none. So Im wondering how on earth this would work out and what to do when I come across it.
Normally with an ISP issue its a 1 or a 0. Either all the accounts are affected or none. So Im wondering how on earth this would work out and what to do when I come across it.
Last edited:
MickeyD
RIP
http://www.telkom.co.za/general/ter...complete_standard_telkom_terms&conditions.pdf
5.4.7 TELKOM AND THE CUSTOMER AND MORE IN PARTICULAR THE CONSUMER CONFIRM THAT THE PROVISIONS HOUSED UNDER CLAUSE 5.4 EXPRESSLY SET OUT THAT THE SELECTED SE AND THE TELKOM SERVICES ARE SOLD OR OFFERED IN A SPECIFIC CONDITION. IN LIGHT OF THE ABOVE DISCLOSURES, WHICH ARE PERMITTED UNDER SECTION 54(1)3 OR 554 (6) OF THE CPA, THE CUSTOMER AND MORE IN PARTICULAR THE CONSUMER, ACKNOWLEDGES THAT IT WILL NOT BE ALLOWED TO:
5.4.7.1 withhold any amounts due and owing to Telkom; or
5.4.7.2 deduct any monies,
in respect of "dropped" or discontinued calls and/or connections or any temporarily unavailability of the Telkom Services, the Connections or the Selected SE, including as an example, extra traffic on the Network, excessive use by users or technical problems which result in line congestion, fatigue and the general unavailability of the Network, except and to the degree that Telkom is solely responsible for any such unavailability, or failure and in such case the Customer’s remedies will be limited, at the Customer’s election, to either having the defect remedied by Telkom or the right to receive a refund from Telkom of any reasonable portion of the price paid for the Selected Telkom Services which have not been performed or which have not been available, having regard to the extent of the failure.
Last edited:
Bookmarked. Thanks. Ive just been educated.
fluffypony
Well-Known Member
- Joined
- Jul 3, 2009
- Messages
- 214
- Reaction score
- 7
This is why I was so confused when they indicated the problem was on my side (without going into any further detail). Had they been able to pinpoint a specific issue, I would gladly accept that the fault is mine and would see what can be done to fix it. Unfortunately, just saying "well it works on my side" isn't a specific problem, and doesn't help me resolve it.
Tinuva
The Magician
fluffypony, I am not a fan of OpenWeb, nor work for them, but I do find this problem interesting. The most interesting part being, 2 IS based accounts acting different. It is possible this issue is on the IS network, and somehow is only triggered with very specific conditions. The problem is finding those conditions.
Here is the tricky bit I am interested in. Please do a traceroute while the OpenWeb account drops packets.
Like so:
That way, the traceroute should start immediately by skipping dns lookups, and we should see where the failure start.
My suspicion is, its the QoS equipment on IS's side, but nothing can be proved until we see where the failure of the dropped packets start.
Here is the tricky bit I am interested in. Please do a traceroute while the OpenWeb account drops packets.
Like so:
Code:
C:\Users\Tinuva>tracert -d 8.8.8.8
Tracing route to 8.8.8.8 over a maximum of 30 hops
1 4 ms <1 ms <1 ms 10.0.0.1
2 5 ms 5 ms 5 ms 196.210.201.1
3 7 ms 7 ms 7 ms 196.38.72.125
4 6 ms 7 ms 7 ms 196.35.115.136
5 11 ms 9 ms 9 ms 168.209.6.5
6 30 ms 30 ms 29 ms 168.209.100.13
7 30 ms 30 ms 30 ms 196.26.0.130
8 31 ms 31 ms 31 ms 74.125.49.66
9 185 ms 185 ms 185 ms 72.14.232.102
10 213 ms 197 ms 190 ms 209.85.253.10
11 190 ms 189 ms 191 ms 72.14.232.76
12 190 ms 190 ms 190 ms 209.85.254.116
13 * * * Request timed out.
14 190 ms 190 ms 190 ms 8.8.8.8
Trace complete.That way, the traceroute should start immediately by skipping dns lookups, and we should see where the failure start.
My suspicion is, its the QoS equipment on IS's side, but nothing can be proved until we see where the failure of the dropped packets start.
Im just wondering how his location would impact the QoS. Cause they say they tested the account elsewhere and it worked fine. The problem can only be replicated at the clients home.
Tinuva
The Magician
They haven't tested on his line, they also probably haven't tested on a line on the same ESR and/or DSLAM.
fluffypony
Well-Known Member
- Joined
- Jul 3, 2009
- Messages
- 214
- Reaction score
- 7
You're absolutely right - and had their support been proactive, I have no doubt that we would have truly isolated the problem and, most likely, solved it. Here is an example of what it's like to deal with someone who is (supposedly) the right person to solve your problem (ie. I'm past first line support and dealing with a technician) -
Then I sent the traceroutes, and received acknowledgement of receipt. And then I waited until nearly midday the next day.
To which the reply was basically that it's not their fault it's mine, and they'll try and help me find the cause and the solution - which help was not forthcoming. I am not in a position where I can wait for them to come back to me days later - this is a situation that you persist with till you've resolved it.
pompomJuice
Active Member
Fluffy!
I believe you have made a huge mistake. You cannot use something like tracert or traceroute to troubleshoot connectivity issues. Download pingplotter instead.
You will most likely quickly realize that the problem with your latency is on your first hop. The issues you describe and the traceroute posted look exactly like the kind of problems I am having. I have looked at so many of this by now that I am almost certain that you are experiencing some form of telkom exchange screwup.
The reason I say this is I have not come across any explanations about what exactly is going on in these exchanges. How are they set up? OpenWeb came after those other ISPs, so maybe the way that they implement it causes the last one to lose out.
Also, I am convinced that whoever is running these telkom exchanges don't know what they are doing.
Go run that proggy and check. You will notice crazy random lag on your first hop that is worse at certain times of the day.
PS - Ashara! Is Trath organizing a reunion?
I believe you have made a huge mistake. You cannot use something like tracert or traceroute to troubleshoot connectivity issues. Download pingplotter instead.
You will most likely quickly realize that the problem with your latency is on your first hop. The issues you describe and the traceroute posted look exactly like the kind of problems I am having. I have looked at so many of this by now that I am almost certain that you are experiencing some form of telkom exchange screwup.
The reason I say this is I have not come across any explanations about what exactly is going on in these exchanges. How are they set up? OpenWeb came after those other ISPs, so maybe the way that they implement it causes the last one to lose out.
Also, I am convinced that whoever is running these telkom exchanges don't know what they are doing.
Go run that proggy and check. You will notice crazy random lag on your first hop that is worse at certain times of the day.
PS - Ashara! Is Trath organizing a reunion?