Emergency Call Protocol for IT Companies

Use this rule: it’s an emergency when business operations are stopped, security is actively at risk, or data loss is ongoing/likely within minutes to hours. If the issue affects one person and there’s a workaround, it’s usually urgent—but not an emergency. Emergency examples (respond immediately): - Entire network down (no internet, no LAN, no Wi‑Fi across office) - Server/VM host down (Hyper‑V/VMware host offline, domain controller down) - Ransomware indicators or confirmed breach (encrypting files, unusual logins, “your files are encrypted” note) - Email system down company-wide (Microsoft 365 outage at tenant level, Exchange failure) and no alternate comms - Payment/POS down across site (retail/restaurant can’t take payments) - Critical line-of-business app down for everyone (ERP, scheduling, EHR) - Active data loss (RAID failure alarms, storage full and services failing, backups failing during incident) Urgent but not emergency (same-day or next business day): - One user can’t print, can’t access one shared folder, single PC won’t boot (if others can work) - New user setup, password reset (unless locked out of MFA/admin during an incident) - “Computer is slow” with no outage - Non-critical alerts (one disk at 80% but stable) Non-urgent (schedule): - New Wi‑Fi setup, network refresh, migrations, cybersecurity audit ($2,000–$20,000), network setup ($1,000–$10,000) - Patch planning, documentation cleanup, device replacements

Run triage the same way every time so you don’t guess under stress. The goal is to determine: scope (one user vs whole company), severity (down vs degraded), security (breach vs bug), and time sensitivity. Decision Tree (ask in this order): 1) “Is the business down for multiple users or one person?” - Multiple users/site-wide/tenant-wide → go to #2 - One person/one device → usually urgent, not emergency (unless security) → go to #3 2) “What exactly is down?” - Internet/WAN, firewall, switch stack, Wi‑Fi controller, server/VM host, Microsoft 365/email, line-of-business app, POS/payment → likely emergency → go to #4 3) “Is there any sign of a security issue?” - Ransom note, unknown admin account, MFA prompts, antivirus alerts, unusual outbound traffic, bank/payment compromise, vendor email compromise (BEC) → emergency → go to #4 - No security signs → go to #5 4) “Is the impact immediate revenue/operations risk?” - Can’t take payments, phones down, dispatch can’t dispatch, clinic can’t access charts, manufacturing halted → emergency 5) “Is there a workaround?” - Workaround exists (hotspot, alternate device, OWA webmail, local login, paper process) → urgent but not emergency - No workaround and deadline within hours → treat as emergency Always capture: location, best callback number, on-site contact, and any recent changes (patches, firewall change, ISP work, Microsoft 365 migration, new switch, new VPN).

After-hours is where you win or lose emergency customers. Your policy must be simple: who answers, how quickly you respond, and what “response” means (call back vs on-site vs remote). Set clear response targets you can actually meet: - Emergency callback: within 10 minutes - Remote triage start: within 30 minutes - On-site dispatch (if needed): within 60–120 minutes depending on distance After-hours workflow: 1) Call is answered (live or AI receptionist) and tagged “Emergency – After Hours.” 2) On-call tech gets a text + email with: caller, company, issue summary, severity, and callback number. 3) On-call tech calls back within 10 minutes, confirms scope, and starts remote session (RMM/ScreenConnect/TeamViewer). 4) If remote can’t restore service quickly, escalate to: network engineer, security lead, or on-site dispatch. Patch-night reality: calls spike after Windows updates, firewall firmware, or Microsoft 365 changes. Add a temporary “patch window” rule: - If you just pushed patches to multiple clients, schedule a rotating on-call from 6pm–12am. - Prepare rollback steps for common failures (VPN down after firewall update, print spooler issues, domain trust errors). If you can’t reliably answer while you’re in a server room or on another emergency, a 24/7 answering layer like SkipCalls can capture the key questions, filter spam, and route true emergencies to your on-call tech—so you don’t lose the first responder advantage.

Most IT emergencies should start remote to save time and reduce cost for the client. Dispatch on-site only when physical access or hardware is required. Remote-first checklist (what you do in the first 15 minutes): - Confirm scope: “How many users affected?” “Which sites?” - Check monitoring/RMM alerts: WAN down, server offline, disk full, failed backups - Verify ISP status and modem/router lights (ask caller to read them) - Validate core services: DNS, DHCP, AD login, Microsoft 365 admin center status, VPN tunnels - Start containment if security suspected: isolate endpoints, disable accounts, block outbound traffic at firewall On-site dispatch triggers: - Firewall/switch stack physically down, power issues, UPS alarms, burnt smell - Server won’t boot, RAID/controller errors, storage enclosure failure - ISP handoff needs hands (fiber ONT, modem replacement) - Client has no technical contact to follow steps remotely Who you dispatch matters: - Network down → network engineer (firewalls, VLANs, VPN, switch stack) - Server/VM host down → systems engineer (Hyper‑V/VMware, AD/DNS, storage) - Security event → security lead (containment + evidence preservation) Dispatch pack list (keep it ready): console cable, spare Ethernet, USB NIC, small switch, laptop with admin tools, labeled MFA tokens (if used), basic hand tools, and a pre-made “ISP call” script with account numbers.

In IT emergencies, callers often say: “The internet is down,” “Email is dead,” “Our server crashed,” “We got hacked,” “Everyone is locked out,” or “Nothing works.” They’re stressed and will call three other MSPs if you sound unsure. Use clear, time-based language: - What you’ll do next - When you’ll call back - What you need from them Client-facing scripts you can use today: 1) Emergency acknowledgement + timer: “Thanks—this sounds like a business-down issue. I’m flagging this as an emergency. You’ll get a call back from the on-call tech within 10 minutes. Are multiple users affected, and what’s the best number to reach you right now?” 2) Remote-first expectation setting: “First we’ll try to restore service remotely, because it’s fastest. If we need hands on-site for the firewall, switch, or server, we’ll dispatch once we confirm what’s down.” 3) If you’re already on another incident: “We’re currently stabilizing another outage, but you are in the emergency queue. You will receive a call back by [time]. If anything changes—like ransom notes or payments failing—tell us immediately.” 4) If it’s not an emergency: “I can help. Based on what you described, it’s urgent but not business-down. We can start remote support today at [time window] at our normal rate.” Reduce repeat calls by sending a single status text/email every 30–60 minutes during active outages: what’s confirmed, what’s next, and the next update time.

Emergency work needs a premium because it breaks your schedule and often requires senior tech time. Keep pricing simple and consistent so you don’t negotiate during a crisis. Recommended pricing structure (aligns with typical break/fix rates): - Standard urgent/break-fix (business hours): $100–$200/hour - After-hours emergency rate (nights/weekends): 1.5x–2x standard (example: $175/hr becomes $260–$350/hr) - Emergency minimum: 1 hour minimum for after-hours response - On-site emergency dispatch fee: $150–$300 trip fee + hourly rate (waive fee for managed clients if your agreement covers it) Managed services clients: - Define what’s included in the $1,000–$10,000/month plan (e.g., 24/7 emergency triage + remote response) - Define billable exceptions: hardware replacement, third-party vendor coordination beyond X hours, incident response for breaches Security incident pricing note: If the caller reports ransomware or active compromise, treat it as incident response. Quote an emergency triage block (example: $750–$2,500) to contain and assess, then a larger project quote depending on scope. Script to introduce emergency pricing without friction: “This qualifies as after-hours emergency support. The emergency rate is $___/hour with a 1-hour minimum. We’ll start with remote triage to restore service as fast as possible.”

Emergency tickets must be clean because they become: your invoice backup, your post-incident report, and your playbook for next time. What to document every time (copy/paste into your ticket template): - Time received, time callback made, time triage started, time service restored - Who reported it and who approved emergency work - Scope: sites/users affected, critical systems impacted (AD, DNS, DHCP, firewall, M365) - Symptoms in client words (“email is dead,” “can’t take cards,” “files renamed .locked”) - What changed recently: patches, firewall rules, ISP work, password resets, new MFA policy - Actions taken (commands, settings changed, reboots, failovers) - Evidence saved for security events (logs, screenshots, affected hostnames) and what you intentionally did NOT do (e.g., “Did not reimage to preserve evidence until approved”) - Root cause (confirmed vs suspected) + prevention steps Post-incident deliverable (1 page): - What happened, when, impact, fix, and next steps (backup changes, UPS replacement, firewall firmware policy, MFA rollout) This is also how you turn emergencies into scheduled projects (network redesign, backup improvements, cybersecurity audit).

IT companies get “emergency” calls that are really convenience requests: password resets, one printer down, one mailbox issue, or “my computer is slow.” Your goal is to protect the on-call tech while still helping quickly. Set clear client rules (put these in onboarding + voicemail/answering script): - Emergency is for business-down, security, or widespread outage. - Single-user issues are handled during business hours unless the user is an executive with no workaround (define this clearly). Practical filters that work: - Require two data points to classify business-down: “How many users?” + “What system?” - Ask for proof of scope: “Can you confirm if others can log in/send email?” - Add a “workaround check”: hotspot, OWA webmail, alternate workstation Use a short “false emergency redirect” script: “I can help. This doesn’t sound like the whole business is down, so it’s not classified as an emergency. I can book you the next available urgent remote slot today, or we can schedule it for tomorrow.” Tools to reduce noise: - Monitoring/RMM alerts for servers, WAN, backups, and disk space so you know what’s real before you roll a truck - A 24/7 answering workflow that asks the same triage questions every time and routes only true emergencies to your on-call tech (SkipCalls can handle this with call transcription and spam filtering). Finally, review false emergencies monthly: who called, what it was, what rule would have prevented it, and whether your client training needs updates.