Jump to content
Security Installer Community

Ademco Galaxy 16+ HELP !!


Guest Guest_Tim_*

Recommended Posts

Sorry but this calling an Engineer for reset's all the time is a joke, there's no need for it except upon a confirmed activation or a genuine system fault

As I said, there's no need for it except upon a confirmed activation or a genuine system fault.

Now I didn't emphasise what sort of system faults but in my book a system fault include's Tampers, excepting those caused by a user entering the code incorrectly too many times.

But simple things like the user resseting an un-confirmed alarm, or something like a user code alarm should be ressetable via his master code. Most users will still call out a company for persistant faults purely because of the nuisence factor to neighbours and them-selves.

Sorry guy's but in my books any company that insists on Engineer resets for every activation/fault is just after the extra revenue that it generates. If your at all worried that a customer won't notify you of a single activation user reset then all you need do is ask your ark to notify you and you can then contact the customer to see if they require assistance.

........................................................

Dave Partridge (Romec Service Engineer)

Link to comment
Share on other sites

Now, grade 3 (most commercial monitored) systems must have engineer reset on tamper and confirmed.

The only thing that should be user reset is an unconfirmed activation, although that appears to be optional.

Sensible policy I think.

If you don't know......ask.

Link to comment
Share on other sites

If an alarm company checks the ARC daily logs and the person who is collating data knows what he/she is doing then unconfirmed alarms will be picked up and the client should be contacted.

If a particular customer is having lots of unconfirmed alarms then the chances are high that they will get a confirmed alarm if no action is taken. As others have said, some clients will call you straight away if there is a perceived fault, while others will ignore it and suddenly call you when convenient or urgent for them, which will never be convenient for an alarm company.

I don't see the problem of having systems on anti-code/engineer reset for tamper and unconfirmed as long as the firm is ready to deal with all those additional calls, and is prepared to offer anti-code or remote resets FOC. It is a bit of catch 22 in my opinion.

Our problem is that our clients nearly always phone us instead of the ARC when needing an anti-code reset for a user-error activation. Or, they phone the ARC but think they will be charged if they admit liability so tell the ARC operator that they do not know why it went off, and then phone us complaining that the ARC wouldn't give them the code :no: .

Zak Tankel - Managing Director - Security First (UK) - www.securityfirst.uk.com

Disclaimer: Any comments or opinions expressed by me are my own as a member of the public and not of my employer or Company.

Link to comment
Share on other sites

Our problem is that our clients nearly always phone us instead of the ARC when needing an anti-code reset for a user-error activation. Or, they phone the ARC but think they will be charged if they admit liability so tell the ARC operator that they do not know why it went off, and then phone us complaining that the ARC wouldn't give them the code :no: .

Sounds like you need to train and explain more to you customer at the time of handover.

www.nova-security.co.uk

www.nsiapproved.co.uk

No PMs please unless i know you or you are using this board with your proper name.

Link to comment
Share on other sites

As I said, there's no need for it except upon a confirmed activation or a genuine system fault.

Now I didn't emphasise what sort of system faults but in my book a system fault include's Tampers, excepting those caused by a user entering the code incorrectly too many times.

But simple things like the user resseting an un-confirmed alarm, or something like a user code alarm should be ressetable via his master code. Most users will still call out a company for persistant faults purely because of the nuisence factor to neighbours and them-selves.

Sorry guy's but in my books any company that insists on Engineer resets for every activation/fault is just after the extra revenue that it generates. If your at all worried that a customer won't notify you of a single activation user reset then all you need do is ask your ark to notify you and you can then contact the customer to see if they require assistance.

Yes, but as I said previously, the remote reset and managed reset facility will negate the need for an engineers attendance through customer misoperations, but there are lots of cases where the customer has a problem either with the set up of the system (ie new entry route etc) or a fault that may lay undetected for 6 months, In my opinion this has the ability to become a confirmed knock and therefore engineer reset should be made compulsory on all activations where the customer cannot explain why. With reference to the tampers, as it says on the tin I would want to know when the customer is messing or has a problem with the alarm kit. The arc report should also be looked at and all activations rung up in the morning offering assistance, before the call gets booked in @ 1705hrs. It's the future, you know it makes sense.

Our problem is that our clients nearly always phone us instead of the ARC when needing an anti-code reset for a user-error activation. Or, they phone the ARC but think they will be charged if they admit liability so tell the ARC operator that they do not know why it went off, and then phone us complaining that the ARC wouldn't give them the code :no: .

When faced with the prospect of an invoice all customers will lie through their teeth, this is especially annoying when you spend time proving it to them, present them with the evidence and then they admit liability. :angry:

Nothing is foolproof to a sufficiently talented fool.


Link to comment
Share on other sites

When faced with the prospect of an invoice all customers will lie through their teeth, this is especially annoying when you spend time proving it to them, present them with the evidence and then they admit liability.

Oh so true, made me recall the days before full english text was available and trying to prove calls were chargable or operator error. Those were the days when a service engineer really earned his wage.

Link to comment
Share on other sites

the 16/16+ will either ask for a engineer reset if progd as bells only or a rr code if progd for remote reset when a tamper is activated...personally you should get afree reset if bells only as tamper reset is usually a manager code function on the bigger gals...

Link to comment
Share on other sites

Only speed read these posts so sorry if I missed the obvious. Im with Norman and bellman on this one. I believe that all systems should have tamper reset by engineer and monitored systems should be re-set after first alarm. Zack covered the anti code re-set which has only one problem, under the old BS 4737 code generators can only be issued by the ARC not the installer. This undoubtedly creates more work for the installer, but in our case this is not necessarily chargeable so I therefore refute Daves idea we do this to make money It costs us money but that

Customers!

Link to comment
Share on other sites

Only speed read these posts so sorry if I missed the obvious. Im with Norman and bellman on this one. I believe that all systems should have tamper reset by engineer and monitored systems should be re-set after first alarm. Zack covered the anti code re-set which has only one problem, under the old BS 4737 code generators can only be issued by the ARC not the installer. This undoubtedly creates more work for the installer, but in our case this is not necessarily chargeable so I therefore refute Daves idea we do this to make money It costs us money but that
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.