Who fixes the phones at 5 a.m. when a three-location business has no IT person?

This case study is an illustrative scenario. The business is a composite and the numbers are worked examples to show the method, not results from a named client.

What can break overnight at a three-location business with no IT person?

Almost everything customers touch before you open: the phones at each location, the shared online booking site, the email domain that sends confirmations, the card on file behind your ad accounts, and the social pages people check for hours. None of it waits for business hours to fail, and nobody is watching it at night.

Take a composite business: a dental group with three clinics in one region, about twenty-five staff, a shared booking site, one email domain and a phone system at the main clinic that the two smaller clinics route through. There is an office manager, no IT employee, and a local technician who comes when called. That is a common shape for a growing Canadian business, and it is exactly the shape the Canadian Centre for Cyber Security writes its baseline controls for: organizations should assume incidents will happen and plan how to respond and recover [1].

Here is the overnight exposure, site by site:

• Phones. Each clinic has a published number. If the phone system at the main clinic stops answering, all three go quiet at once.
• Booking site and domain. One website takes bookings for all three. If the domain lapses or the certificate expires, patients see an error, not a calendar.
• Email. Confirmations and reminders go out from the group's domain. Since February 2024, Gmail has required every sender to set up SPF or DKIM, with SPF, DKIM and DMARC for senders of more than 5,000 messages a day [2]. A DNS change that breaks authentication can quietly push reminders into spam.
• Ad balances and social accounts. A declined card pauses ads; a locked page stops answering messages.

What happens when all three clinics' phones go dead at 5:40 a.m.?

MapleMonitor's test call to the main clinic's published number fails, a second check confirms it, and a war room opens. The agent sets P0, because no clinic can take a call, and a P0 never drops a level at night. The on-call person works the runbook remotely and test-calls every line before opening.

Here is the timeline. The times are illustrative, not a response-time promise.

1. 5:40. The test call to the main clinic fails. A repeat check fails too. The war room opens: one timeline that will hold the priority, every message sent and every action taken, kept in a tamper-proof audit trail.
2. 5:42. The agent sets P0 Critical. Outside business hours, P1 to P3 drop one level; P0 does not. The agent pages the on-call person, opens the conference line and updates the public status page.
3. 5:50. The on-call person follows the runbook written for this group. Internet at the main clinic is up, so the likely cause is the phone system itself, which did not recover cleanly after a short power flicker overnight. It is restarted remotely through the access set up at onboarding.
4. 6:05. Test calls go to every published line. The main clinic and the second clinic answer. The third clinic's line connects but plays the wrong greeting. Customers can reach a person again, so the incident comes down to P2 and the all-hands response ends.
5. 7:30. The office manager arrives to a written outage summary and one open item: fix the third clinic's greeting during business hours.

Had the remote restart failed, the runbook says who gets the call next and who holds the key to the main clinic. That is the drive worth making. The one worth avoiding is the one where somebody drives in at 6 a.m. to press a button that could have been pressed from anywhere.

What does the lower-priority issue look like, and why can it wait until morning?

The same night, the domain check notices that the booking site's domain expires in twelve days and the renewal has not gone through. During business hours that is a P3. Overnight it drops to P4 and lands in the morning queue with its own war room record, because nothing is broken yet.

Waiting is fine for twelve days; ignoring it is not. Under ICANN's Expired Registration Recovery Policy, registrars must send at least two renewal notices, about a month and about a week before expiry, and after expiry the domain's DNS resolution must be interrupted for at least the last eight days it can still be renewed [3]. Interrupted DNS means the booking site and the email domain both go dark. After deletion, generic domains such as .com have a 30-day redemption grace period [3]; a .ca domain follows its own registry's rules, so check with your registrar.

The usual cause is dull: the renewal notices go to a web designer's old address and the card on file has expired. The fix is a morning phone call to update the card and the contact email. The value of catching it early is that it stays a P4 instead of becoming a P0 on a Monday.

What does Managed add over Watch and Respond for a multi-site business?

Watch alerts your team and leaves the response to you. Respond adds the agent: it sets priority, runs the runbook, sends pre-approved customer updates and writes the summary. Managed adds people: for each site, an after-hours team on call 24/7 behind the agent, remote repair before anyone drives in, test calls to your lines and runbooks written for your business.

• Watch: up to 60 checks, as often as every 60 seconds, SMS, email and voice alerts to your team, a war room timeline and one public status page.
• Respond: everything in Watch, plus the agent setting priority and running the runbook, customer updates by SMS, email or voice using only wording you approved at setup, a conference line per war room, business pulse, account balance and social checks, written outage summaries and a monthly uptime report.
• Managed: everything in Respond, per site, plus the people behind it.

For a group whose phones go down, the optional outage status line add-on matters: callers to your number hear about the outage and can get a live update from a receptionist rather than ringing out. For a dental or other healthcare group, one rule holds at every tier: no patient information is ever sent by SMS or email, and alerts describe service status only. Security monitoring, such as sign-ins from outside Canada, is a separate product, MapleSIEM.

How do you work out whether Managed is worth it for your locations?

Count three things in hours: drives to a site you would no longer make, opening hours of downtime you would no longer lose, and the staff hours idle during those opening hours. Multiply lost opening hours by your own revenue per hour. Then compare the total with the Managed price per site on the pricing page.

The logic behind the second row is simple. Without anyone watching, a phone outage that starts at 5:40 is usually found when the first person arrives and notices the phones are quiet, then chases the technician. The hours between opening and the fix are the expensive ones. Be honest with your inputs: count only incidents that would have been found late, and if your outages are rare, the table will say so.

Should a small business just hire an on-call IT person instead?

Run the hours first. A business open about 60 hours a week has about 108 hours a week, or roughly 5,600 hours a year, when nobody is on site. One person cannot be on call for all of that and still sleep, take holidays or be sick, so true 24/7 cover usually means a rotation of several people.

Statistics Canada's survey of businesses with ten or more employees found that half had cyber security employees in 2023, down from 61% in 2021, and that the most common reason for not having them was using consultants or contractors instead (47%) [4]. Outsourcing is the normal answer, not a shortcut.

What does not get outsourced is accountability. The Cyber Centre recommends that someone in a leadership role be specifically responsible for IT security, and that if you cannot manage a type of incident on your own, you plan for what you will do [1]. With Managed, that person is still yours. They approve the runbooks and the customer wording, and they read the outage summaries. They just stop being the one who answers the phone at 5:40 a.m.

To compare fairly, write both options in hours. An on-call rotation needs enough people to cover every overnight and weekend hour in the year, plus the hours to train them on three sites. Managed needs the hours your responsible person spends approving runbooks at setup and reading summaries afterwards.

What should the runbook for each location contain?

Each location needs a short written runbook: its published numbers, where its phone system and internet equipment live, the provider account numbers, how to reach it remotely, who can open the building, and who decides when to drive in. Keep an up-to-date printed copy at each site, because the outage may take out the digital one.

The printed copy is the Cyber Centre's own advice: a written incident response plan that names who is responsible, includes contact details for outside parties, and exists as an up-to-date hard copy for when soft copies are not available [1]. NIST's current incident response guidance, SP 800-61 Revision 3, treats response as part of everyday risk management rather than a separate emergency binder, with the aim of reducing both the number and the impact of incidents [5]. BDC's advice to small businesses is plainer: write down what you would do to get back in operation, where the backups are, and who would set up your IT again [6].

For a multi-site business, add the dependencies between sites. In this scenario, the two smaller clinics depend on the main clinic's phone system. That single line in the runbook is why a failure at one site is correctly treated as a failure at all three.

Who does not need Managed?

A single-location business with an owner who is comfortable fixing things is usually better served by Watch or Respond. Watch tells you within minutes that something is down, and Respond runs the playbook and customer updates for you. If your mornings do not depend on phones and bookings, you may not need after-hours people at all.

Managed also makes little sense if you already pay an IT provider for true 24/7 cover, or if nothing that fails at night costs you anything before you open. BDC notes that many entrepreneurs do not think about technology risk until something bad happens [6]; the fix for that is a plan, and a plan can be as small as a Watch alert to the owner's phone.

A useful test: look back over the last twelve months and count the mornings a location opened with something broken that had failed overnight. If the answer is zero or one, and the fix each time took minutes, start with Watch and revisit the question after a season of alerts. The war room timelines will tell you whether overnight failures are real for your business or rare enough to leave with the owner. If the count is higher, or the fixes needed someone who knew the phone system, that is the pattern Managed is built for.

What should you do this week?

Pick one early morning this week and, before anyone arrives, call each location's published number from a mobile phone. Write down what happens. Then list, per location, the three things that would stop the day if they failed at 5 a.m., who would find out first, and whose email receives your domain renewal notices.

That list is the start of your runbook. If any line on it reads "nobody would know until we opened", put the hours from the worked example against it and compare the result with the tier prices on the pricing page.

If a test call rang out or reached the wrong greeting, you have already found your first incident, in daylight and at no cost. Fix it, add it to the list, and repeat the test after any change to your phones, internet or website.

Finally, print the list and leave a copy at each location, next to the phone system if you can. When something does fail before opening, the first person in will know who to call, what to check and which failures are worth a drive.