Service request
Request Technical Service
Tell us what the system is doing. We work out the cause, then quote or dispatch. Repair, programming, server work and support for enterprise security systems in critical environments.
Before you send it
What a service request is for
A service request opens a technical file. It is not a sales enquiry and it does not commit you to anything.
Use this route for a system that is down, degraded, throwing faults, out of sync with its database, or behaving differently after a change on the network. Also use it for programming work, a server rebuild, a firmware or version migration, or a scheduled preventive maintenance visit.
We do not sell cameras, panels, readers or licences, and we do not run new cable, drill or install conduit. Our work starts where installation ends. If what you need is new construction wiring or hardware supply, we will say so and point you elsewhere rather than take the job.
If you are not sure whether a problem is ours to solve, describe it anyway. Sorting that out costs you one message.
Do not send sensitive system information
For security reasons, do not submit passwords, credentials, IP addresses, cardholder data, floor plans or other sensitive system information through this form.
A description of the symptom is enough to start. “Four OSDP readers on one panel went offline after a power event” or “the video client cannot authenticate to the directory since Tuesday” gives us everything we need for a first assessment.
System specifics such as addressing, account details, credential formats, drawings and remote access arrangements are handled once identity is verified and the correct people on your side have authorized the exchange. That happens through a channel you control, not through a web form.
Have this ready
Information to have ready
None of this is confidential. Having it to hand shortens the first exchange and often removes a round trip entirely.
You and your organization
So we know who we are dealing with and how to reach you.
- Name
- Organization
- Job title
- Email address
- Phone number
- Preferred contact method
Site and system
So we can judge access, travel and what platform knowledge the work needs.
- City or service location
- Facility type, for example hospital, data centre, correctional, school board, industrial
- System or platform, for example the access control or video management product in use
The request itself
So it reaches the right person in the right order.
- Type of service required, for example repair, programming, server work, maintenance, support
- Issue summary in plain description, no system detail needed
- Urgency, including whether the system is fully down or partially degraded
- Interest in a service agreement, if that is part of what you are exploring
What happens after a request
Four stages. You are told which one you are in.
- 01 Acknowledgement — We confirm receipt and tell you who is handling the file. Acknowledgement timing follows business hours, which are 8:00 AM – 5PM. Requests that arrive outside those hours are handled under 24/7/365.
- 02 Scoping — A short technical conversation. What changed, when it started, what has already been tried, what the system is doing now. This is where a repair is separated from a configuration fault, and a configuration fault from a network or infrastructure problem. Identity is verified before any system detail is discussed.
- 03 Remote review where access allows — If you have an approved remote access path and choose to use it, a large share of faults can be seen from the logs, the event history and the service state without anyone travelling. Remote work is done under your access rules, on your account, and only after you authorize it. Where remote access is not permitted, we skip this stage and scope for site attendance.
- 04 Quotation or dispatch — You get either a written scope and price, or a scheduled attendance under an existing agreement. Nothing is ordered, replaced or billed on assumption. See service agreements for how planned and reactive work is handled together.
Response targets and hours
We do not publish a universal response time, because a number that applies to every caller and every fault is a number that means nothing. A degraded camera stream on a quiet corridor and a failed controller on a secure perimeter are not the same event and should not carry the same promise.
Where a target belongs, it belongs in writing and attached to your site. Remote response targets are expressed as 1.5 Hour and on-site attendance targets as 3.5 Hours. Those targets are defined in each customer’s approved service agreement, along with coverage hours, escalation path and what counts as a priority fault.
Business hours are 8:00 AM – 5PM. Outside them, 24/7/365 applies. Service territory is Southern Ontario, CA.
Direct routes
Reach a technician directly
For anything urgent, use the phone. A system that is down is a phone call, not a form.
- Phone. +18664163566 during 8:00 AM – 5PM. Outside those hours, 24/7/365.
- Email. support@skyfalsecurity.com. Include the same information listed above and keep system specifics out of the message.
- General or partnership enquiries. Use the contact page instead. Requests that are not about an active technical problem move faster there.
The request form is being configured
The online request form is not live yet. It is being set up deliberately rather than quickly, so that submissions are handled and stored the way client information in this sector should be handled and stored.
Until it is live, send requests by phone on +18664163566 or by email to support@skyfalsecurity.com. Both routes reach the same people and follow the same four stages described above. Nothing about the handling of your request changes when the form appears.
Describe the fault. We will take it from there.
Phone +18664163566 or email support@skyfalsecurity.com with a plain description of what the system is doing.