Re: the police was dispatched to ... the wrong house

["Robert L Bass" <RobertLBass@xxxxxxxxxxx>]

>> Uh, no.  It is not.  They could try actually capturing
>> and ptocessing Caller ID.  They could offer daily
>> tests and o/c reports like we have been discussing.
>> They could take the trouble to check when a test
>> signal has the wrong Caller ID so that people like
>> the OP don't have to pay fines due to alarm company
>> stupidity.
>
> That works, maybe, if you are monitoring a handful
> of alarm systems from your garage...

O wouldn't know.  Do you work from your garage?

> But matching up account numbers and Caller ID info is a
> complete non-starter for a large central station...

It's amazing how long you've been in the business and
yet you have no idea how CS automation software
functions.

> There are just too many things that can go wrong...

We've already seen what goes wrong when alarm
companies are too cheap to bother comparing Caller
ID data.  The fact is that the *only* reason most CS'
dpn't bother is they don't want the added cost of more
phone lines, line cards, etc.  If the alarms only send
emergency signals they generate far less CS traffic
and more accounts can be assigned to a given line.
Doing it right costs the central station a little more --
a few cents per account per month.  It's a tiny fraction
of the revenue that a large CS can generate but most
are too greedy to part even with that small amount.
The result is that problems like the OP's are fairly
common.

> It would be irresponsible not to dispatch
> because of a Caller ID - account number mismatch.

It is even more irresponsible not to even check the
Caller ID nor to run daily tests.  Doing so ensures
that more of these problems will arise.  Doing it right
would cost a few extra cents a month but that would
have alerted the CS *before* the alarm came in.
Keep explaining why it's so "responsible" of the CS
to cheap out on service.  It's amusing.

> I'd also point out that in many cases, you would
> be talking about ANI rather than Caller ID, if the
> central station is using 800 numbers for its receivers.
> ANI data is not transmitted in the same way as
> Caller ID data, further complicating the matching
> process.

It makes no difference.  The data is availabvle in real
time and computers running standard CS automation
software can easily solve the problem.  The real issue
is cost saving vs. customer service.  Feel free to continue
arguing against responsible service.

> Consider the following scenarios which could affect
> ANI/Caller ID info after a system is installed:
>
> 1.  Customer decides he doesn't like Caller ID, and
> orders per-line blocking, where available.

Upon receipt of the next test signal, CS contacts the
alarm company to notify them of the change.  The
alarm company, in turn, contacts the client to let verify
the reason for the loss of ICLID data.  Client may
decide to reinstate the feature.  If he does not, the
CS can edit the account so the CSA software looks
for the "blocked data" signal.  The client is made
aware of the reduced level of security.  If he keeps it
that way he is explicitly accepting the situation.

> 2.  Customer changes his phone number and
> doesn't tell the central station...

That night the test signal comes in with the "wrong"
Caller ID.  A call to the client produces updated
information which is entered into the account file.
Fringe benefit: The customer notices how carefully
the alarm company is watching out for his security.
He won't soon switch providers.  In places where
people think about such things this is considered
a win/win situation.

> 3.  Customer gets a PBX system that generates a
> preprogrammed ANI regardless of which line actually
> placed the call...

This affects nothing.  Once the proper number is
entered into the account there will be a match.

> 4.  The Caller ID data gets garbled during transmission.
> Unlike alarm data, it isn't sent again and again until it's
> acknowledged...

Yep. That happens.  If the system gets unreadable data
the CSA software will flag it.  It's a snap to differentiate
between garbled data and clean data from another phone
number.  I've written software to do this.  I discussed it at
length here some years ago.  My app ran on the THEOS
OS which Bradley used way back then.  I wrote it because
at the time BOLD didn't offer ICLID processing.  TTBOMK,
the feature is now standard.

> You want to generate service calls when you have a
> data mismatch or no data on a timer test?  Who pays
> for that?

Wrong.  If the data on a test signal indicates a change,
it should only generate a phone call or two.  The customer
is already paying too much for lousy service with most of
these large, national CS' anyway.  When you get a changed
phone number you make a phone call.  If that's going to
break your bank you belong in a different business.

> You can think up more scenarios for yourself...

Your imagination is already prolific enough, thanks.

> The key question is this: [when will these "professiona"
alarm companies begin to give responsible service?]

The answer is this:  Not until police departments stop
responding to calls, thereby rendering their services
unsalable.  From the discussion here it is apparent that
too many alarm companies would rather come up with
excuses than properly service their customers.

> What does a central station do if it receives a signal
> with no ANI/Caller ID info or a mismatch between the
account number and the info that is on file?

That depends on whether the account is configured to
expect ICLID data.  If so and the signal is a test, make
a phone call to determine why the number has changed.
If it's an alarm signal, why wasn't the system already
checked when the daily test came in with the same wrong
data or without any data?

> At best, it's a maintenance issue, but the signal is
> going to be handled as an alarm anyway...

You're missing half of the story.  You need ICLID data
*and* daily tests to be able to spot these problems before
an alarm comes in.  It's not enough just to monitor Caller
ID.  You need to do both.

> ANI doesn't really do any good in terms of false alarm
> reduction.

It will alert you to a moved panel.  It will alert you to a
premises that has been sold or rented without your
knowledge.  It will alert you to an improperly programmed
panel elsewhere sending on a previously assigned line /
account.  All of these things can indeed help you to reduce
false dispatches.

Not only that.  Doing it right will earn you major points
with your existing customers.  It will also give you an
almost immediate opportunity to introduce your company
to a new purchaser of a home you've been protecting.
That will give you the opportunity to sign on a new account
rather than piss off the new homeowner when he sets it
off (they invariably do) trying to figure out how to use it.

> So, even if account 246 is programmed as a Contact
> ID account...

Think about that for a few minutes.  Do you see what's
wrong?  :^)

> A close analysis of the signals received near the
> time of the one in question might shed some light
> on this, but it's too late now.

If they were recording Caller ID they could have called
the number, spoken to the person whose system sent the
signal and resolved it in less time than it took you to
type a 3-digit account number for a system using Contact
ID.

--

Regards,
Robert L Bass

=============================>
Bass Home Electronics
941-925-8650
4883 Fallcrest Circle
Sarasota · Florida · 34233
http://www.bassburglaralarms.com
=============================>