Frontier and CLEC service problems

Frontier and CLEC service problems

Last week I was given the task of canceling the remaining 70 fictitious loops that SandyNet once used for DSL service. Of course not having any background on how the heck to do, I go about trying to complete this task. I had little information besides some pre-orders of customers and their ATN numbers and zero experience. This was going to be a lot fun. I started away on trying to cancel some lines.

Day 1 – Having only used the Frontier VFO system one other time in my life, I had no idea what to do and what fields and forms did what. Out of probably a hundred different fields for information I had to fill out maybe 10. They are all abbreviation’s and provided very little detail on what the actual purpose was. I spent close to four hours that day trying to find where information went and belonged.

Day 2 – I spent about 7 hours attempting and correcting orders. Looking through every manual, and every spreadsheet that Frontier proved on their VFO system , I had a vauge idea on where the information was needed. Vague. One field was the ECCKT, or the circuit ID field, only 15 or so customers had that information on the records I pulled. Using that field with the circuit ID, I got my first order to confirm. I had 15 completed by the time I went home that night.

Day 3– Upon completeing those 15 orders, I was back at square one. I could not get any new orders to verify and pass through since I had no ECCKT. The error message simply outputted INVALID TN / INVALID TN 000/000-0000 . TN… What does TN mean? Oh, Telephone Number? But after trying every field that required a telephone number, the problem did not resolve. Having gotten 15 orders to successfully go through, it must be something with the circuit ID. Logic would suggest  that orders that had, had an ID passed and the ones that didn’t, didn’t. Having replaced the ECCKT with the ATN(I had reasons….) I fired off many more orders. All returned with a non-fatal error. Just invalid TN. So why doesn’t it throw an exception,  oh I don’t know maybe “INVALID ECCKT” or something useful, or tell me what page the error is on so I don’t waste my time on every page and every field looking for a problem. Having gotten frustrated I called support for CLEC’s on Frontier and soon was talking to a live person. After getting all the background information out of the way, it turned out that I was using some wrong data in some fields, and I had messed up this number with another one, and oh… I had just canceled some people’s circuits. Not their DSL line, but their whole circuit, so both voice and data. The tech started to get upset over what had happened, as I explained that this task was thrown at me and I was told to get it done. I was merely throwing information at the wall and hoping it stuck.

Our customers use to have DSL, but canceled or were switched to WiFi long ago, and we never canceled the lines, so they have been unused, so they either still have voice through Frontier, or DSL as well, so when I am told that the circuit is cancelled, I immediately think… How on Earth do I have access to cancel circuits when we never touched them in the first place? Knowing that I could go in at any time with the proper information and cancel any line anywhere does not make me feel secure about using their system or using their system for phone service. We may have a DSL line on that circuit, but why do I have the permission to remove the circuit. It took an hour to straighten out the issues, but once that was completed, I could finally get started on finishing this annoying project.

Day 4 – I spent a few hours canceling lines, and finally completing my project. Having spent much time fussing around with the constant issues of Visual Front Office and filling out pages of information, I vowed that I will never work for a company that is a Frontier CLEC again. I understand that their system works, and they have a huge database to maintain, but I can’t see how it works when I went in and accidentally canceled some peoples phone service (It was not disconnected because the date for disconnect was two weeks out, and I canceled the order before it was sent to tech) .  I am not a teleco guy, I know TCP IP stack and not this whole old school system.

After spending hours of messing up and fixing orders, I am glad to see the orders are confirmed and should be canceled. I learned a lot on this project. Not so much technical, but I learned my passion to dislike DSL ordering and just DSL in general.

Comments are closed.