Cellular Phone Forum / Providers / Sprint PCS / December 2003
Your thoughts on another Sprint Blunder
|
|
Thread rating:  |
MTG - 30 Dec 2003 20:56 GMT A few weeks ago, on the phone, Sprint said my contract expired in March of 2004.
Online it says it expired October 12, 2003.
If I callback and they insist March of 2004, but it still says October 12, 2003 online, what next????
I still don't see how a company the size of Sprint can have an issue like this...Someone did a poor job of desiging their relational database system.
I don't see how CSRs can pull data from one table and report information, then the web site pulls data from another table that reports different data.
Basic relational database design WOULD NEVER allow for this!!!!!!!!!
And the fact that the wrong info has been on the web for sometime now means nobody seems to care about checking data integrity...
Sprint prolly went the way of most companies in America looking to save a buck -- Hire IT folks overseas in India and pay them $20/hour instead of $150/hour.
See where cutting corners gets ya ;)
Steven J Sobol - 30 Nov 2003 21:13 GMT
> I don't see how CSRs can pull data from one table and report information, > then the web site pulls data from another table that reports different data. > > Basic relational database design WOULD NEVER allow for this!!!!!!!!! You're assuming they're using the same copy of the database. But I agree with you.
 Signature JustThe.net Internet & New Media Services 22674 Motnocab Road * Apple Valley, CA 92307-1950 Steve Sobol, Proprietor 888.480.4NET (4638) * 248.724.4NET * sjsobol@JustThe.net
MTG - 30 Dec 2003 21:22 GMT Dude...LOL...If they are using two DBs for the same data , that is a prime example of how redundancy, when not setup properly, can bite you in the a.s.
I wish I could see their entire DB Schema.
Anybody inside Sprint got a copy?? (If it exists...lol)
> > I don't see how CSRs can pull data from one table and report information, > > then the web site pulls data from another table that reports different data. [quoted text clipped - 9 lines] > Steve Sobol, Proprietor > 888.480.4NET (4638) * 248.724.4NET * sjsobol@JustThe.net Scott Stephenson - 30 Nov 2003 21:29 GMT > Dude...LOL...If they are using two DBs for the same data , that is a prime > example of how redundancy, when not setup properly, can bite you in the a.s. [quoted text clipped - 18 lines] > > Steve Sobol, Proprietor > > 888.480.4NET (4638) * 248.724.4NET * sjsobol@JustThe.net Not two databases- two views of the database. If you're the type that thinks that any company is going to give you a direct view of production billing tables, I've got some nice land to sell you. Chances are that the website has a static table that is refreshed on a given schedule.
MTG - 30 Nov 2003 22:02 GMT > > Dude...LOL...If they are using two DBs for the same data , that is a prime > > example of how redundancy, when not setup properly, can bite you in the [quoted text clipped - 24 lines] > billing tables, I've got some nice land to sell you. Chances are that the > website has a static table that is refreshed on a given schedule. Of course I know Sprint itself isn't going to give that to me...But maybe someone inside IT could...lol
And even worse if the table is static!!!!!!!! That could create so many problems...That would create a case of poor data integrity.
A company like Sprint should easily be able to have a system that once you verifiy over the phone, or sign up in a store, or whatever, that contract date propogates to some table instantly, then any other tables that need that date can draw from the main table the date is housed in...seems like since there are two dates, one on CSR cpus and one on the web site, there are two distinct fields somewhere in the DB scheme that allow for independant insert operations...
or maybe Sprint is being unprofessional as usual and the contract end date online is part of some sort of beta testing that is visible to the public
MTG - 30 Nov 2003 22:03 GMT > Chances are that the > website has a static table that is refreshed on a given schedule. oh yeah, if that is the case Sprint needs to hit the refresh button 'cause the dates have been off for a long time!!!
Scott Stephenson - 30 Nov 2003 22:25 GMT > > Chances are that the > > website has a static table that is refreshed on a given schedule. > > oh yeah, if that is the case Sprint needs to hit the refresh button 'cause > the dates have been off for a long time!!! Now you're talking about something totally different- cointract dates won't be in the billing table.
MTG - 30 Nov 2003 22:40 GMT > > > Chances are that the > > > website has a static table that is refreshed on a given schedule. [quoted text clipped - 4 lines] > Now you're talking about something totally different- cointract dates won't > be in the billing table. And what makes you think that?
contract dates could be in any amount of tables.
and considering that billing and contract dates have a relation, i could see a table with billing having a contract date attribute...especially if determing a bill may depend at some point, may include someone who terminated their contract before it was up which would warrant a cancellation fee...
Scott Stephenson - 30 Nov 2003 23:56 GMT > > Now you're talking about something totally different- cointract dates > won't [quoted text clipped - 9 lines] > terminated their contract before it was up which would warrant a > cancellation fee... Why are you going to put a number of static values on the busiest table , and then have to call to that table every time you need that value? Not only would it bog the system down horribly, but it would present a myriad of data integrity issues. This is not the way billing systems are designed. Static values reside on static tables, making them easily available to any number of calls, without affecting table performance on the most important table in the system. The ONLY identifier on the billing table will be the account number- everything else resides elsewhere.
MTG - 01 Dec 2003 00:19 GMT > > > Now you're talking about something totally different- cointract dates > > won't [quoted text clipped - 19 lines] > table in the system. The ONLY identifier on the billing table will be the > account number- everything else resides elsewhere. ok i see where you are coming from. and i agree. i'm still just confused on why there are two contract date values...
tom ronson - 01 Dec 2003 01:15 GMT >i'm still just confused on why there are two contract date values... Obfuscation? Can you name any other industry that has such problems with billing systems? (Sprint's not alone in this) ---- and making it more surprising is that all of these company's wireled side cousins don't appear to have these problems.
While it takes the truly cynical to think that these systems are sloppy for a reason (which is what I believe to be the case) it does make one wonder if you screw a million folks out of a $1 here or there a month and only 75,000 of them catch it and get it corrected you're still looking at a pretty good piece of change in "mistakes".
I don't believe for a minute these systems need to be this FUBAR, but without an incentive to fix them why bother? To stop a few carps on a NG? Get serious.
The best tip that I can offer is make your deal with Sprint, in a store so you have a written record (or record the order yourself over the phone --- stating the date and time at the beginning of the call and end of the call) and stick to it. Then when they have a problem you've got history and evidence on your side. That way any "errors" are glaring when the bill arrives monthly.
In your case make them prove it beyond "because we said so" --- they say they've got a recording of all transactions (which I don't believe for a second) --- make them present it to you. It shouldn't matte how long it takes --- make them cough up a transaction that puts you at either of the dates they've got on record for you --- both of which are probably wrong anyway.
Really, preparing a bill and maintaining a customer folder isn't rocket science --- lots of industries do it every day and none of them seem to have the problems that cell co's have with it. And while I hate the government being involved in any business maybe this industry is begging for the attitude adjustment that would come with minimal regulation on what's expected for a real billing system.
I say this even though my bill fluctuates a buck a month --- for a fixed price service. Go figure, huh?
--tr
Scott Stephenson - 01 Dec 2003 01:17 GMT > ok i see where you are coming from. and i agree. i'm still just confused > on why there are two contract date values... My guess is that the website is calling up some other date- basically calling from the wrong field. If Customer Care is giving one date (the right one) then this would seem to be the case.
MTG - 01 Dec 2003 01:54 GMT > > ok i see where you are coming from. and i agree. i'm still just confused > > on why there are two contract date values... > > My guess is that the website is calling up some other date- basically > calling from the wrong field. If Customer Care is giving one date (the > right one) then this would seem to be the case. Not saying that isn't the issue, but one would think someone has called it to Sprint's attention and changing the code would be done instantly...
Scott Stephenson - 01 Dec 2003 02:02 GMT > Not saying that isn't the issue, but one would think someone has called it > to Sprint's attention and changing the code would be done instantly... Agreed.
dkar - 09 Dec 2003 05:31 GMT > > > ok i see where you are coming from. and i agree. i'm still just > confused [quoted text clipped - 6 lines] > Not saying that isn't the issue, but one would think someone has called it > to Sprint's attention and changing the code would be done instantly... Instantly! What IT organization does anything instantly. Not that this isn't something that needs fixed,...but its probably low on the totem pole as far as critical stuff.
As for the other dudes comments about "all the wireless providers have crappy billing systems and their wireline cousins do not"...its because wireless companies exploded in the 90's and didn't have time to do it right. Wireline companies have had 20, 30, 40+ years to do and redo their systems. Not to mention their business is pretty damn boring..how many "new plans" have you seen from your local telco provider in the last year? Free minutes?, extended calling hours?, local number portability!!!, nope. ...the wireless industry is thrashing.
my $0.02
Steven J Sobol - 09 Dec 2003 06:13 GMT
> As for the other dudes comments about "all the wireless providers have > crappy billing systems and their wireline cousins do not"...its because [quoted text clipped - 4 lines] > minutes?, extended calling hours?, local number portability!!!, nope. > ...the wireless industry is thrashing. I don't believe "all wireless providers have crappy billing systems." Some of them work properly.
 Signature JustThe.net Internet & New Media Services 22674 Motnocab Road * Apple Valley, CA 92307-1950 Steve Sobol, Proprietor 888.480.4NET (4638) * 248.724.4NET * sjsobol@JustThe.net
Chris McFarland - 09 Dec 2003 11:36 GMT > As for the other dudes comments about "all the wireless providers have > crappy billing systems and their wireline cousins do not"...its because [quoted text clipped - 4 lines] > minutes?, extended calling hours?, local number portability!!!, nope. > ...the wireless industry is thrashing. Not true. One can change Local and/or Long Distance landline providers and kleep their phone number. And most landline companies now have many long distance plans with bundles of minutes.
I would suggest the difference is Landline is profitable, while for many companies (like SprintPCS) wireless is not profitable yet, so they cut corners on IT.
Scott Stephenson - 11 Dec 2003 00:27 GMT > Not true. One can change Local and/or Long Distance landline providers > and kleep their phone number. And most landline companies now have many [quoted text clipped - 3 lines] > companies (like SprintPCS) wireless is not profitable yet, so they cut > corners on IT. I tend to think it is more a case of too much technology to handle. All of the cellular companies are throwing a ton of money at new technologies. Unfortunately, they outsource almost all of the application development and design, which makes making changes both expensive and not timely. And the software developer will always fight tooth and nail when something is identified as a defect (which has to be fixed for free), and try to classify it as an enhancement (which they get paid extra for). The difference always comes down to whether or not the issue at hand was spelled out in the requirements for the application. All of this does take time and money.
And we have to remember that we are talking about a product the size of a pack of cigarettes that has more functionality built in than third-generation PC's had, and with no hardline connection to operate. In the current competitive environment, survival is based on IT dollars. That doesn't mean they are spending it wisely- AT&T and Sprint are both showing signs of this currently.
Steven J Sobol - 01 Dec 2003 01:04 GMT
> Not two databases- two views of the database. Objection, Your Honor - assumes intelligence not in evidence.
I know plenty of companies that hire people stupid enough that they'd do something like that.
> If you're the type that > thinks that any company is going to give you a direct view of production > billing tables, I've got some nice land to sell you. Chances are that the > website has a static table that is refreshed on a given schedule. Perhaps. Probably. I haven't, as a customer, seen much that convinces me that the billing software was designed or deployed rationally...
 Signature JustThe.net Internet & New Media Services 22674 Motnocab Road * Apple Valley, CA 92307-1950 Steve Sobol, Proprietor 888.480.4NET (4638) * 248.724.4NET * sjsobol@JustThe.net
Scott Stephenson - 01 Dec 2003 01:27 GMT > > Not two databases- two views of the database. > > Objection, Your Honor - assumes intelligence not in evidence. Don't we do that every time we post?
> I know plenty of companies that hire people stupid enough that they'd do > something like that. True- without starting a true flamewar, I think we can both think of an alt.sprint.pcs resident who is employed by someone.
> > If you're the type that > > thinks that any company is going to give you a direct view of production [quoted text clipped - 3 lines] > Perhaps. Probably. I haven't, as a customer, seen much that convinces me > that the billing software was designed or deployed rationally... One thing to keep in mind- Sprint did not design or write any code for the billing software they use. It was purchased elsewhere, and while they had a great deal of input into some of the functionality and design, they are totally in the dark when it comes to the inner workings of the application- most application vendors have taken the Microsoft approach and closed most of the code to the end user. This is not unique to Sprint- all cellular companies (as well as most of the free world corporations) are in the same boat. And the billing software is a living, breathing application- constantly being modified and updated. And while these changes get tested in a test environment, a lot can happen in the real world that can't be replicated or anticipated in a test.
One more thing- as part of the pruchase agreement, Sprint is more than likely at the mercy of their vendor to provide support for the application. Again, not unusual to Sprint.
Steven J Sobol - 01 Dec 2003 01:03 GMT > Dude...LOL...If they are using two DBs for the same data , that is a prime > example of how redundancy, when not setup properly, can bite you in the a.s. Yup. :)
 Signature JustThe.net Internet & New Media Services 22674 Motnocab Road * Apple Valley, CA 92307-1950 Steve Sobol, Proprietor 888.480.4NET (4638) * 248.724.4NET * sjsobol@JustThe.net
norelpref - 08 Dec 2003 15:41 GMT >Sprint prolly went the way of most companies in America looking to save a >buck -- Hire IT folks overseas in India and pay them $20/hour instead of >$150/hour. $20? HAHAHA, I'd guess about $10. I've read that programmers get about $4/hr. Of course that amount is relative to the area involved.
|
|
|