I'd avoid the use of a multiplier system e.g. 1x, 2x as this value can
inadvertantly change if the customer upgrades their service and forgets to
adjust the multiplier (obviously depending on whether it's based on base
payment or committed bandwidth) which could result in tears. Also it would
make it harder for you to compare overage between customers as 1x is
meaningless on its own.
The way I would handle it would be to..
- By default, allow no overage at all and just pull the plug once the limit
is reached until contact is made or the billing period ends.
- During the sign-up process, ask the customer if they would like to enable
overage, and explicitly set a limit in GB or £s (e.g. using some JS to
calculate the other depending on which is entered).
- Optionally, if overage is requested, force entry of an 'immediate'
contact number e.g. using text message verification with a code, or you can
manually verify by calling the number at your leisure.
- Anything above a certain threshold (or just any overage at all, depending
on your credit policies) can be sent to you, subject to approval. You could
choose to only grant requests where there is a verified contact number.
- Send out an email to your existing customers with a link to a control
panel page allowing them to follow the same process, once again defaulting
to no overage unless a request is made.
- You can continue to make suggestions to repeat offenders, so long they
are paying the overage bills and ignoring your suggestions just enjoy the
extra income, ultimately it's their choice to pay more.
This way there is a process to ensure a valid contact number, you're
keeping tighter control of lines of credit you are offering, and any
overage is explicitly agreed in clear £ liability figures between both
parties so there should be fewer or no surprises / disputes later on.
Cheers,
Luke T
On 19 June 2018 at 16:59, Andy Smith <andy@???> wrote:
> Hello,
>
> Recently we had a rather unfortunate situation where a customer ran
> up a very large (4 figure) unexpected overage bill.
>
> The current systems of BitFolk behaved how they are currently meant
> to, in that the customer received an email warning and then very
> quickly an email notification that limits had been passed and
> further data transfer would incur a charge.
>
> In addition to the automated process, on the day where the limits
> were exceeded I also opened a support ticket with the customer to
> warn them that all further data transfer would incur a charge.
>
> Sadly the customer did not read any of the emails, so the level of
> use continued for the remainder of the 30 day period, then at the
> end a huge bill was presented.
>
> I am not looking to discuss the way in which the customer here was
> in the wrong. The outcome is undesirable to BitFolk because it is
> always going to be difficult to get an unexpected overage bill paid
> when it's approximately 300 times the size of the regular monthly
> charge. Any customer presented with such a bill is likely to be
> extremely upset, and we don't want upset customers.
>
> So, how can we improve the process?
>
> The problem with the existing procedure here is that after the
> notification of exceeding limits has been sent, there is no
> follow-up until the end of the measuring period. In a case such as
> this where usage is very high, the data transfer quota can be
> exhausted quickly and then you've got several weeks where it can
> continue at the same rate, building up a huge overage bill.
>
> In my view what should have happened is that once some level of
> outstanding bill was reached without any response by the customer to
> say that this was expected and should continue, BitFolk should have
> turned off their network to limit further expense. At least until
> they respond to discuss what they want to do about it.
>
> Assuming you agree with that, it becomes a question of what that
> limit should actually be. I brought this matter up a long time ago
> when it was a hypothetical situation and the majority of respondents
> at the time were very against the idea of service being interrupted
> without an instruction from them to do so.
>
> For the following 10 years we've done things that way and not
> interrupted anyone's service purely for transferring more data than
> their plan covers, but now that the potential for running up very
> large bills has been demonstrated, it is a risk to BitFolk and is
> something we have to revisit. So when considering this issue, please
> try to consider it not as hypothetical, but as if it were yourself
> running up a bill.
>
> Please also bear in mind that because we are talking about what
> should happen in the case where there is no communication, whatever
> we decide has to be the default for all customers. To deviate from
> the default will require a setting being changed in the Panel or a
> support ticket ahead of time.
>
> So, at what level of overage would you consider it desirable for
> BitFolk to temporarily suspend your network access rather than cost
> you more money?
>
> Should the amount actually be zero, i.e. as soon as you go over the
> limit (despite warnings etc) your network is suspended until you
> acknowledge that you will pay your overage bill?
>
> It may be possible to use traffic shaping to limit the liability.
> This is not really an area I want to get into because:
>
> - It would only be one-way: data you send out. We can't necessarily
> control data that is sent *to* you, especially if it is not TCP.
>
> - By interfering with your data flow in my view it makes us *more*
> liable for your behaviour. A customer could always argue that they
> aren't paying their bill because we should have done a *better*
> job of shaping their traffic to prevent/reduce the bill. Fully
> specifying how the shaping would work might help, but people who
> are facing a bill they don't want to pay can always find fault
> with that, and those aren't conversations I particularly want to
> deal with.
>
> Therefore, the only form of traffic shaping that I really want to
> consider is the most extreme kind: no traffic is allowed at all!
>
> Something must be put in place to try to avoid this ever happening
> again, so I would appreciate your thoughts on how it should work.
>
> Again, rather than just saying it is the customer's fault (no one is
> arguing that it is not the customer's responsibility), please try
> to imagine yourself in the situation where your VPS is running up an
> overage bill and you haven't seen any of the emails or seen the
> Cacti graphs etc. It is a risk to BitFolk. What would you want done
> about it?
>
> Finally, I should mention that there are currently two customers who
> almost every month run up overage bills that are 10 to 20 times
> their monthly regular bill. They have done so for a long time; they
> have already been advised to commit to more in order to reduce their
> bills, but they keep paying the overage bills. So while overage is
> quite rare across the customer base, for a few customers it is the
> norm. Whatever is decided may involve me forcing those customers to
> change the way they do things.
>
> Cheers,
> Andy
>
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
>
> _______________________________________________
> users mailing list
> users@???
> https://lists.bitfolk.com/mailman/listinfo/users
>
>
