Oh please, I've worked on the anti-fraud/abuse system of a large hosting/internet provider in Europe.
It was a flexible "if then scoring escalation/ticketing rules".
I'm not saying my knowledge applies to all customer support cases, but what happened here would never have happened with our system.
Just very simple tricks go a loooong way dealing with malicious people:
how old is the account of the "reporter" ?
is the "reporters" id verified?
how long has the account we're taking action against been our customer?
whitelists/blacklists -- temporary or permanent
are all complaints against a customer of the same type grouped to the same ticket type/ticket?
Just based on those simple facts, we would mmediately lock functionality/content for unverified, new customers we received complaints about, while delaying, notifying and giving verified, aged customers the chance to respond/fix issues.
I'm not saying this is easy, for the system I worked, our agents designing the rules had about 80 individual ticket types(in a hierarchy, with rule re-use for ticket category), but they used their brains and did not take any "lock X functionality of the customer" lightly.
You could be right, in 2008 we handled about 10^5 complaints per day, and the volume seemed to double every year(most of those were automated complaints from external systems complaining about our customers spamming/phishing/etc), I don't know what the figures are now.
My point was we had automated rules in place that worked really well and there was nothing really clever about those rules.
It was a game of cat and mouse between our rule designers and adversaries who always tried to probe our thresholds and evade us while we tried to find new useful facts about customers, new probes, new actions, react proactively, but not screwing our legitimate customers was always our number 1 concern.
I'm not familiar with osTicket, is your point that osTicket could have been used instead of custom-made software in 2006 or that I'm overglorifying the system I worked on?
I'm not saying my knowledge applies to all customer support cases, but what happened here would never have happened with our system.
Just very simple tricks go a loooong way dealing with malicious people:
how old is the account of the "reporter" ?
is the "reporters" id verified?
how long has the account we're taking action against been our customer?
whitelists/blacklists -- temporary or permanent
are all complaints against a customer of the same type grouped to the same ticket type/ticket?
Just based on those simple facts, we would mmediately lock functionality/content for unverified, new customers we received complaints about, while delaying, notifying and giving verified, aged customers the chance to respond/fix issues.
I'm not saying this is easy, for the system I worked, our agents designing the rules had about 80 individual ticket types(in a hierarchy, with rule re-use for ticket category), but they used their brains and did not take any "lock X functionality of the customer" lightly.