2012-10-31

BT find new ways to rip us off!!!

When an engineer is booked to repair a fault, one of the options is a "co-op call".

This is where the engineer in question talks to our staff. It can be useful to confirm what we can see our end, and so can help the engineer do his job.

One of the rather odd things about this is the charging. Even though the term "co-op" seems to suggest a mutual benefit, or a two way thing, BT charge us £35 for the co-op call.

This makes no sense if we are helping the engineer do his job, surely it is mutually beneficial (so no charge) or we are providing consultancy (so we would charge BT).

What is stranger is the charge seems to apply even if it is found that the fault report and engineer visit was completely correct (i.e. a fault is found in the BT network and fixed). This especially makes no sense.

Even though this is rather odd, we have a specific field in the fault booking system to say if we are requesting a co-op call, and we always say "No".

Lately we have had the occasional call from an engineer, and helped them out, and to our surprise we have then had a bill from BT for co-op calls.

We explained that we did not request them, so "sod off", or words to that effect, but they are saying they have had a change of policy and now the engineer can request/make a co-op call whether we asked for one or not.

And, if the engineer makes a call, even when we said we do not want one, BT will charge us £35, even if the fault is found and fixed.

I'm sorry, but, basically, no way. This is so totally wrong it exceeds all of the other things that are wrong about BT engineer visits by orders of magnitude. It is quite unbelievable. It means BT can, if they wish, make £35 out of us for reporting a genuine fault in the service they provide and for which we pay. Even just calling to say "it seems to be working now" is £35. Actually making money from faults in their network.

So we have a plan, as always, and it is a voice warning on the contact number advising that the engineer should only proceed if he agrees to our terms for co-op calls, and to hang up otherwise. We'll record the call. The terms will be for BT plc to pay us for the call. I can't see that not standing up in court.

It does leave me wondering what the next cunning plan someone in BT will come up with to rip off its customers.

Lets be clear here - I really want to work with BT on fixing their systems. We need an attitude of working together to fix problems. Bullshit like this just alienates customers and makes it a battle with BT, when it should not be. Someone in BT needs to get some clue and stop the battle and actually think about providing a proper service and fixing it when it goes wrong. We have tried, and will continue to try and work with BT. I have personally joined in with an internal meeting with BT fault desk managers, given presentations, and spent the day with them. I really thought we were making progress, but once again it is all going downhill. Depressing.

2012-10-30

Special Billing Investigation

So, BT are being fun. Things like agreeing a £144.00 charge last December was not valid but only crediting £137.80. No explanation.

Several of the other short paid agreed disputes are odd. E.g. £61 under credited, and now saying £11 will be credit but "£50 charge is valid". WTF?

So here is my response:-

As Stuart said, why are those charges valid?
You need to explain!

e.g. "Charge of £50 is valid"
What is the £50 for exactly, and why is it valid exactly?

You can't resolve a dispute simply by stating that "it is valid".
You need to elaborate...

If such a response was all that was needed then lets play that game.
In reply, I state "Charge of £50 is NOT valid". That all you need?
Or would you expect us to elaborate and back up that assertion?

Bear in mind that we never order end user premises module or co-op call module, ever. We do not order extra modules. It is hard coded in the XML ordering system to exclude these modules, and we have copies of the signed XML requests as well as the BT signed XML confirmations.

So if your logic is that some extra module was completed and so the charge is valid, you need to state that. We can then prove that we did not order the module and therefore that the charge is not valid.

As of 1st Nov we will charge BT for such investigation. That means you will have to provide evidence of your assertion that the charge is valid, such as sending a copy of the XML signed order. In the absence of such evidence the charge remains in dispute with us simply stating it is not valid.

If you don't have evidence to back up your claim, you can request that we investigate and find evidence for you. For example, we could provide a copy of the signed XML order and BT signed XML acknowledgement. This would prove the matter either way. We provide this additional investigation as a chargeable service, but free if we were wrong. Sounds familiar?

We call it a "Special Billing Investigation". It is a fixed cost of £144.00+VAT for all investigation relating to a single dispute item. It will involve work finding any supporting evidence relating to a dispute. The charge will be waived if we find that the BT charge being disputed is in fact valid (i.e. if we are wrong). You can order Special Billing Investigation from us by email, asking us to provide extra evidence relating to any disputed amount. I look forward to your order. The service starts on 1st November.

See the following web page for details of this service:-

Regards,
Adrian.

OSPF plodding on

Well, finally starting to get over my cold, and managed to get in early yesterday and today and spend a few hours on OSPF before the day starts.

I am still working on the database exchange process. I almost have it working (well, far end thinks we have done the exchange, so a start).

It is messy, but getting there. Once I have the database exchange sorted, I have to sort the "flooding" logic. This will then mean we have, and maintain, the OSPF link state advertisement database.

There are a few gotchas that I can see. The way entries are withdrawn is, err, fun. You mark them as old (a hour) and ensure everyone has seen that, then remove it. That is not too bad, but it is a problem if you want to change your mind and now announce the entry again. You sort of have to wait for it to all be removed before re-creating it. You are supposed to cater for a 32 bit sequence wrapping as well, in a similar way. There is another related gotcha in that you are not allowed to update an LSA more often that a certain rate. Well, what if you have changes faster than that? You are meant to delay them. That sort of means storing a current version, and a "new version" in the database and a process to pick up that we want to move to a new version after a delay. That sort of crap is horrid - who makes a protocol like that? Just saying in the text of the RFC "delay" sounds so simple doesn't it - but delay means storage and timers and tasks.

I suspect that I will have to have a pending "new version" for any LSA we originate, and a task to pick up when to move to it. Arrrrg!

So, next milestone is full database synchronisation, not just exchange and loading, but flooding (as designated router, backup router and other router).

Once the database synchronisation is sorted there are a couple more jobs to do.

The first is that we have to originate stuff. I am, for now, trying to just originate our own router LSA, which is a single, and relatively simple, LSA for us as a router. Even that is a pain as it has to update on any change to any links, even just designated router changing. We'll have to also originate a network LSA where we are the designated router for a subnet. That should not be a lot more complex.

Then we have to ensure we originate LSAs for external routing, e.g. connected networks like L2TP links, BGP routes, and so on, subject to various filtering logic. The current design makes it very easy for the OSPF subsystem to track any core routing changes, and effectively get events for adding, changing or removing external routing LSAs. Once again the issue of changes being too fast, and withdrawing routes, but that will have to be solved first.

So that is a milestone of maintaining LSAs that we originate.

Finally, after that, we have the simple job (!) of working out shortest path and injecting routes in to the core routing table. To be honest that is not too scary. We have a simple interface for injecting routes and removing them, which then ensures the routes propagate as needed (e.g. via BGP is required) and update the forwarding logic. There is a minor special case for equal path routing, but we have several systems for that in place already for bonding, so taking multiple OSPF targets an routing to them as a set is not a major change.

So, final milestone is working OSPF!

Once we have that we have a single area OSPF router and have loads of testing to do. Making it multi-area may come later, or may fall out of the database work anyway, not sure yet.

All good fun.

2012-10-28

Junk calls

As anyone reading my blog for a while will know, I really hate junk calls.

Much like junk emails, I am sure that once upon a time they were sufficient few and far between that they were not a major problem. Junk post is sort of bearable because it is relatively low in volume - but imagine if every morning your post was a large sack, somewhere in which was the couple of "real" letters you needed. We all know email has become like that, and junk calls are getting as bad.

There are several ways to tackle junk callers...

When the office started getting literally hundreds of calls a day I automated a system to play one-sided conversations to keep the callers on as long as possible. I managed calls lasting 5 minutes, and some were posted on my blog. The particular company making such calls no longer call any of our numbers - it was very effective. Oddly a honey trap of thousands of other numbers did not get the same level of calls - and we wonder if the fact we had notified the TPS of our whole office number block was the reason we got the calls. Hard to prove though. If I get a chance I may test this theory by listing specific numbers with TPS and not listing others and checking levels of calls.

Of course the TPS should be the answer - tell them you don't want to be called. My experience is that it is not that helpful. I still get junk calls. When I mention the TPS they may apologise, etc, but usually hang up when I explain that they are criminals now.

This is a key point - such calls are criminally illegal if they are to numbers in the TPS. Its the law! It is also the law that you can make a civil claim for damages if you get such calls - so not just breach of law (and hence the only action would be taken by CPS or DPC), you can make a county court claim!

So cudos to this man:-
http://news.sky.com/story/1003497/victory-for-man-who-took-cold-caller-to-court

He told the junk caller that he would charge them. They still called. He charged them. He did not even rely on the legislation for junk calls for this - he relied on the making of a contractual offer (offering his time for a fee) which they accepted (by continuing to call).

The real shame is that it was not tested in court, but makes it well worth a try for anyone else similarly annoyed by them. Submitting a county court claim is quick and easy and relatively cheap. You can do it on-line.

The big problem I find is that you cannot find out who is behind the call. Well, you can, if you buy what they are selling, I suppose, but not just by asking. They typically have no clue who they are. They may know a brand name but can't say if a limited company or registered office address, etc. They are useless.

2012-10-25

Most complete?

You can tell I have been sat here all afternoon with a cup of soup and paracetamol watching daytime TV. Ug... But I note that BT sell what they claim is the "most complete broadband package"...

I always try and pick adverts apart at the best of times, but I am not sure what "most complete" means, or what it means to have a "complete broadband package".

We can probably put to one side the fact that "broadband" is a technical term that relates to the multiple frequency bands / carriers used on DSL lines (ADSL and VSDL). It has started to become a term for "Internet access", annoyingly.

But to my view, even "Internet access" simply means the ability to send and receive IP packets. In order to make the package "complete" I would say you want caching DNS resolvers. But you have a "complete" internet access package if you can send and receive IP packets. Everything else is extra.

If you want a TV package, that is part of a TV package, not a broadband package. A "broadband package" is "complete" if (calling it an "internet access package") it provides internet access. How can it be "more complete" or "most complete"?

Obviously, to be even vaguely "complete" as an "internet access package" you have to include the current IP protocol, IPv6. Does it I wonder? If another ISP also allows IPv4 packets, and DNS, and so on, but also IPv6, does that ISP not have a more complete broadband package that BT? If that is the case, then BT's package is not the "most complete" is it?

Hmm. Who is it that one complains to about adverts these days?

Taking a stand?

This one is aimed at other ISPs using BT services.

All of you spend a lot of time on disputes, I am sure, not just SFI charges but mistakes, though I suspect SFI charges are the main one. It is very time consuming.

So, we are taking a stand (what a surprise).

We have told them that we will check the bill and advise them of errors (i.e. what the error is and why), but only the once. We will then withhold the payment of the disputed charges, as per the contract. We believe that this is all we have to do as per the contract.

When they come back later asking why the invoice was under paid (even though we told them), we will only reply if they agree to pay a consultancy fee, probably £75/hour or part.

We might reply confirming once again our offer of consultancy to help them identify their mistakes, and that the withheld amount is "as per previously advised disputes" but no more work than that.

We might even make an automated reply stating that, and stating an alternative email address for "purchase of consultancy services" specifically. If they email that, we help them our and invoice for our time.

To be quite frank I am sick and tired of having staff spend hours and hours fixing BT errors on their bill. They should have no errors. It is simply not acceptable.

Any other ISPs got similar approaches? Please do post a follow up...

P.S. Examples :-

I just looked at a small batch of SFI charge disputes BT resolved, 9 of them, totalling £1,500. They are all cases of an SFI or SFI2 charge often with extra modules, disputed because BT did in fact find and fix a fault on the network, so should have been free. Simple disputes, usually quoting the BT engineer notes back at BT.

With no explanation BT have chosen to only partly credit 4 of then, fully crediting the remaining 5. This means we still have £214 in dispute.

So, we now have another round of "why is this invoice under paid" where we have to explain the dispute again, and that they only partly credited us, and that the balance remains in dispute.

Just an example of the total stupidity here - one of the disputes resolved this month dates back to last December. The charge was the standard cost for an SFI, £144.00. The credit we have received is £137.80, so £6.20 still in dispute. Why do that? How do they do that? It makes no sense at all - but it means more work for us in handling the disputes.

Update: Apparently this has got as far as Ian Livingstone!

Have you paid us yet?

Just as in social interactions, there are, in business, some things that are bad form, even taboo. They create bad will and causes disproportionate annoyance. One of these taboos is chasing people to pay a bill before the due date. Obviously people can pay before the due date, but most people do not for simple business reasons.

It is a tricky one. As a supplier we have a few people who will not quite pay on time, or need some sort of nudge to convince them to pay on time, and it is very tempting to chase them in advance of being late - i.e. before the due date. When you do that people get quite annoyed - "Of course we will be paying on time". The annoyance is usually because chasing the payment in advance is seen as untrusting and suggesting the customer will pay late. I can't guarantee that our accounts dept have done this, but it is something we try not to do, and would normally only be someone that we really do not trust to pay on time based on a long history of such. Even so, we would have to expect that sort of reaction.

We don't usually have much of a problem because we do charge the statutory late payment penalties that apply when a business customer pays us late. We usually credit the first time, but this is a fully automated process. People learn that at the very least, if they pay late, they get the hassle (trying to get a late payment credited, etc). So they pay on time, or change to direct debit (and so pay on time). It works well.

One trick we did was send a statement mid month if a payment is due. Not a chasing letter or a call, just a statement, what invoices there are and when due and how much. That seems not to cause annoyance, thankfully. It also helps sort any cases where someone has, for some reason, not seen an invoice.

But as a customer, we pay suppliers on time. We are very careful to pay people on time, even the likes of BT where the payment is a very large amount. We plan cash flow carefully to make sure we never pay late. If ever, by mistake, we pay late, we offer to pay the statutory late payment penalties even if the supplier did not know about them. It would be somewhat hypercritical if we did anything different.

Our friends at BT have, however, started getting a tad annoying of late. Some of the BT accounts are complicated because every single month there are a long list of disputes, and also a list of credits where they have agreed previous disputes and deductions are in fact valid. We advise BT clearly of what we dispute and pay the balance on the due date, not a day later. Some of the BT accounts are not a problem, and paid on time, every month, the full amount.

What has got annoying is BT chasing us asking have we paid an invoice, before it is due. This is when the invoice is not due for a week. We always pay on time, but they still ask, every damn month, on several of the BT accounts. And it is starting to wind me up now!

So, am I right? Is it a taboo to chase people for payment before it is due? It is fair that this annoys me?

FYI we asked BT why, and they said that they need to know when we will pay for their forecasts (cash flow, I assume). As the contract does not require us to provide this, I have told them an hourly rate for any future queries of this nature - we'll see what happens.

Of course, to add to the fun, BT have a odd idea on when payment is due. We have 28 days terms, so an invoice issued on 1st is due on 29th. Oddly they state "due on" not "to arrive by" as we would, but when they chase us for payment like this they say that they are expecting payment by 28th. Thankfully the invoice does not say "28 days" but actually states "due on 29th" so not ambiguous at all, but it does just add to the annoyance.

Ironically, whilst it is normal for 28 days from 1st to be 29th, (1+28=29), when we issue invoices we base payment terms on time as well as date, so an invoice issued 09:00:00 on 1st would be due by 09:00:00 on 29th, if on 28 calendar days terms. However, an invoice issued 00:00:00 on 1st (as most are) would be due on or before 23:59:59 on 28th (and we state the date and time clearly). In practice you have to be more than a day late to get penalties, so that is academic, but amused me how something as simple as this can have ambiguities :-)

Tick Tock

I am pleased to say that my new time servers are in the UK NTP pool now. Dave has done a nice report on how well they are performing, here ....