[VoiceOps] some of my customers DID show as Possible Spam

[Carlos Alvarez]

Neither use predictive, but have live humans dialing.  Both leave a message
on VM if nobody is there so the calls are not short duration.  The one
calling for governments (and power companies, and such) are not calling for
politicians.  They are calling for the sitting body of government, or the
energy supplier, etc.  They also respect the DNC, but nobody puts
themselves on that any more.  They just hit "spam" on their call blocking
apps.

These chickens are being marked as ducks.  I get that consumers are fed up,
now they are creating their own new problem.

The only thing these customers have not tried is the five minute rolling
CLID.  And for the medical practice one, that's problematic since they are
trying to use a specific number that will get known.  So most patients do
answer it, some percentage instead consider it spam.


On Tue, Nov 16, 2021 at 9:33 AM Jay Hennigan <jay at west.net> wrote:

> On 11/15/21 16:01, Carlos Alvarez wrote:
> > You cut out the part where it was their city government calling, wanting
> > to know what the citizens would like "fixed" and focused on in the
> > communities.  You'd opt out of this?  Do you also not vote?
>
> I vote with a ballot at a polling place or by mail, not by engaging with
> random unsolicited call center workers. I've found that political
> polling calls and survey calls are often "push" polls, often rather
> invasive in terms of personal questions, lengthier than needed, and
> interrupt me at inopportune times. Politicians and survey companies
> lobbied to get themselves excluded from the TCPA and the result is that
> the only mass unsolicited calls that those on the DNC list get are from
> spammers/scammers and politicians/pollsters.
>
> In my opinion the politicians made a mistake with their lobbying. They
> should honor Do Not Call listings. They're making unsolicited bulk calls
> to those who specifically went through a process to say that they don't
> want them.
>
> > Also not a collection agency, it's the primary biller, and the customer
> > has opted into the calls in writing.  If they go to collections, my
> > customer actually sends them out.  They only do the gentle calls, which
> > also includes appointments.  So by marking them bad, they may also not
> > receive calls to set consultations with their doctor.
>
> I'm not disagreeing that it's a real problem for both your customer and
> in some cases those that they are trying to reach. Your problem is that
> your customer's operation passes the duck test. It looks like a duck,
> quacks like a duck, and swims like a duck.
>
> Multiple calls in succession and/or simultaneously from the same ANI, a
> high percentage of which disconnect within seconds with the BYE coming
> from the customer side (they are immediately getting hung-up on), some
> of which are to numbers on the Do Not Call list, as well as many
> customer flags as spam calls.
>
> Is your customer is using a predictive dialer? If so, the called parties
> have gotten very attuned to the dead silence for a second or two after
> answer and that at least in my case will pretty much assure an immediate
> disconnect from the called party side, a big red flag for the algorithm.
>
> It's a tough situation but from the carrier's perspective they are
> offering their paying subscribers a benefit that the subscribers want.
> Your customer needs to make their operation behave less like a duck. The
> video suggests several tweaks. Of course the spammers are also going to
> try to crack the algorithms, so it's a cat-and-mouse game. STIR-SHAKEN
> will help. An honest CNAM will help.
>
> --
> Jay Hennigan - jay at west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20211116/8e330fd8/attachment-0001.htm>