South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
Jannie please bear with me and my following statement in spite of the fact that the system should be changed to "real-time" data metering to mitigate the OOB business anyway.
Jannie please bear with me and my following statement in spite of the fact that the system should be changed to "real-time" data metering to mitigate the OOB business anyway.
On the other hand the customer has no real excuse for being billed for OOB if I use all the known prevention tools provided by Vodacom.
Making use of these prevention tools on a regular daily bases combined with checking all download sizes etc.
- The 31050 Short Code System
- The USSD *111# Commands
- The USSD *111*500# Commands
- Lastly the Vodacom website
- Taking note of Vodacom usage SMS's received.
Just my 2cents worth
Noted but are all South African consumers oblivious when entering into ANY contract not applying "Caveat Emptor" or applying their minds to the T&C, if so then this indicates a great degree of irresponsibility. Similarly to a person driving and colliding with the rear end of the vehicle ahead when this vehicle was stopping for a red traffic and asking the driver as to why he stopped receiving the reply statement that the traffic light was red. Has the average consumer in 2013 become that irresponsible?
What is missing from that list is the ability to "lock" data access. You cannot dial *111*500*009# or whatever to disallow\ allow data access. Nor is there a tool to dial *111*500*019*500# or whatever to state "When the data usage on this line reaches 500 Megabytes lock data access". You cannot go online and set such a lock - and at the same portal purchase bundles.
Smart people on the problem costs them money to introduce mechanisms that hurt their revenue when they would rather have smart people working on ways to make them money. The stupid thing is that in the long term not introducing proper mechanisms concerning the OOBShark is to the detriment of Vodacom. The dilemma which they evidently often face is between different system trade offs - the prepaid system is evidently adequate for a lot of consumer purposes, and therefore actually advisable, but there are some serious restrictions.
Yep one of the big problems with the whole thing. Out of the different OOBSharks VC postpaid is by almost all measures the most vicious.
I don't think its a case of the systems being polar opposites but rather starting on different premises.
That is exactly what I am arguing for. A system is needed for a user to set their own cap in data size (and there isn't any real technical reason why it can't distinguish between different times of day) which means that many users will buy more bundles and happily consume rather than seeing the OOBShark threat. Now a user could even set in a cap size that is less than the size of loaded bundle - and a consequence is having spare capacity to unlock on the portal. Now it must be all user initiated - give the user the tools.
I believe in fighting large corporate stupidity. Did quite a bit on the OOBShark last week am busy with MWeb this week. Telkom has changed for the better and I'd like to think that this forum has played some role.
- - what I do believe very strongly is that when a problem is properly identified and the thinking is outside of the box a solution to a seemingly intractable problem is usually pretty damn simple. You don't need to invent a space pen to write in space you can use a pencil or go out and buy a Fischer.
The proposal I am making is that they introduce a separate system that receives notification data from the monitoring system (which they have been working on) which then processes a check against a user subscribed conditional for locking access and if the conditions are met using whatever disabling mechanism applies (because as far as I understand the situation your APN is the path for GPRS to a gateway to a network and you may actually want to refuse authentication earlier although I may be mistaken and RADIUS may be used for all authentication, but even if it is some GSM special authentication system in play the thing must be able to be interacted with by a system telling it to revoke or reinstate access).
The limitation of the various systems are obviously there and, believe it or not, a lot of work is being done to make things better, including the suggestions above.
But, in all fairness, we've done a lot to try and work around the limitations and to put various options on the table to be used, the first being on the right product in the first place. For MBB it's for sure Top Up for most though we have subs who insist on the contract options exactly because they WANT to go OOB, clearly with proper notification.
As someone posted above (DJ or Bern, I think), the issue is largely with education. If we can get customers AND sales agents across the various Service Providers to understand the pros and cons, a lot of the OOB problems would never occur.
1. Pick the right product.
2. Use the tools.
But as the technologies allow, we're implementing them. It's just not 3 week projects, however simple it seems on paper. Building and implementing a rating & billing system that serves millions of subs takes years. And we've been at it for a few already. Of course a few forumites who've set up a MySQL server on Linux believe it's easy.
If that is fully the case it makes things a lot easier. Because I don't have all of the documentation and I know that the move to all IP is not complete I simply don't want to assume that there isn't a hitch particularly because of the fact that we don't put "login details" for cellular access - it certainly is the case that RADIUS can be used on the gateway accessed by any particular APN but I always worry about legacy systems and how WAP featured and all sorts of other things.
