ConnectWise On-Call Scheduling: Why Manage Has No Real Rotation (and How MSPs Fix It)

It is 2:14 AM and a domain controller at your largest client has stopped responding. The monitor fired, the alert became a ticket, and the ticket landed on your "After Hours" service board exactly as designed. Then it sat there. No phone rang, because a service board is a queue, not a person — and ConnectWise Manage has no idea who is supposed to be awake right now. That gap is the whole problem with ConnectWise on-call scheduling: Manage can dispatch work brilliantly during business hours, but it was never built to decide who gets woken up at 2 AM, or to keep escalating until someone actually answers.

Most MSPs discover this the hard way, then paper over it with a service board, a shared spreadsheet and a group chat. This guide walks the real gap in Manage, shows exactly what breaks after hours, and lays out what a genuine on-call rotation needs — including how a bidirectional PSA sync closes the loop back into ConnectWise.

What ConnectWise Manage actually gives you for scheduling

Give ConnectWise credit first, because the baseline matters. Manage has a genuinely capable Dispatch Portal: a calendar where a dispatcher can see every resource's availability at once and drag service tickets into open slots. Member scheduling, schedule entries, office-hour capacity and round-robin assignment all work off that same calendar, and for weekday dispatch they work well. If your problem is "who has a free two-hour block to take this onsite," Manage answers it.

None of that is an on-call rotation. A dispatch calendar assigns planned work to people who are already at their desks. On-call is the opposite shape: unplanned work arriving outside office hours, where the only questions are who is responsible right now, how do we reach them fast, and what happens if they don't answer. Manage models none of those three. As one on-call integration vendor puts it, in Manage "there is not a mechanism to track notification and response" — which is precisely the mechanism on-call is made of.

The bodge every MSP ends up with

Absent a native feature, the standard workaround has three moving parts, and each one fails in a different way.

The spreadsheet that drifts

Somewhere there is a rota — a Google Sheet or an Outlook calendar — that says who is on-call this week. It was correct when it was written. Then someone swapped a shift for a wedding, someone took unplanned leave, and the sheet quietly stopped matching reality. The spreadsheet is not connected to anything, so nothing enforces it. At 2 AM the honest answer to "who is on-call?" is often "let me check three places and guess."

The service board that pages nobody

The "After Hours" board is where alerts and email-to-ticket land overnight. It is a good record and a terrible alarm. A board cannot be woken up; it waits to be looked at. During the day someone is watching, so it feels like it works. After hours everyone assumes someone else saw it, and the client discovers the outage before the on-call engineer does.

The group chat with no owner

So the team bolts on a Teams or WhatsApp group: paste the alert, tag the person you think is on-call, hope they have notifications on. This is the layer that actually pages someone — but it has no concept of ownership, no acknowledgement, no escalation, and no record. A message read and forgotten looks identical to a message never sent. When it is missed, there is nobody the process holds accountable, because the process was "hope."

What breaks at 2am

Trace the 2:14 AM domain-controller alert through that stack and watch every seam give way. The monitor fires and creates the ticket — the one part that works. The ticket routes to the After Hours board, where it sits, because the board pages no one. Fifteen minutes later the client's early-shift staff can't log in and start calling; the call hits an answering service or a diverted mobile. Whoever picks up checks the spreadsheet, which says Priya is on-call — but Priya swapped with Marcus on Tuesday and the sheet was never updated, so the first page goes to the wrong engineer entirely. Twenty more minutes gone. Marcus finally logs in, fixes it by 3:30, and updates the ticket. Nobody hands the context to the day shift, so at 8 AM someone reopens the same investigation from scratch, and the client's account manager first hears about a two-hour outage from the client.

None of those failures were technical. The monitoring did its job. Every breakage was an ownership and hand-off failure — the same class of problem that makes tickets get lost between engineers at every shift change, except an unresolved alert is usually attached to something that is actively on fire. And the stakes are not abstract: Uptime Institute's 2024 outage analysis found more than half of significant outages now cost over US$100,000, and 16% top US$1 million. Minutes lost to "who is on-call again?" are billed at that rate.

What real on-call scheduling needs

A working on-call layer replaces all three bodges with four properties the spreadsheet, the board and the chat can never have between them.

• Rotation as a first-class object. One authoritative schedule that knows who is on-call at any given minute, handles swaps and leave without a manual edit, and is the single source of truth every alert reads from.
• Routing to the person, not the place. An alert pages whoever the rotation says is responsible now — by SMS, push, voice call or chat — instead of landing in a queue and waiting to be noticed.
• Escalation until acknowledged.If the first engineer doesn't answer in a set number of minutes, it escalates — a second channel, then a backup engineer, then a manager — and it does not stop until a human explicitly acknowledges.
• A record that survives the shift. Who was paged, when they acknowledged, what they did, and what is still open at hand-off — captured automatically, not reconstructed from a group chat the next morning.

This is well-trodden ground for alerting tools in general; RMM alert managementcovers the routing and escalation mechanics in depth. Dedicated on-call add-ons for ConnectWise — AlertOps, OnPage and others — exist precisely because Manage doesn't do this natively, and they do the paging part well. What almost none of them do is close the loop back into the PSA and carry the unfinished work into the next shift.

Closing the loop with ConnectWise + Shiftctl

This is where an MSP-built tool separates from a general-purpose pager. On the Shiftctl Enterprise plan, the on-call rotation and the alerting layer are the same system, and it talks to ConnectWise Manage in both directions:

• An alert from your RMM or monitoring routes to whoever the rotation says is on-call, and escalates over SMS, voice call (press 1 to acknowledge), Slack, Teams, email and push until someone answers.
• Shiftctl creates or updates the matching ConnectWise ticket automatically — so the PSA stays the system of record without anyone re-keying it at 3 AM.
• Status syncs both ways: acknowledge or resolve in Shiftctl and the ConnectWise ticket moves with it; update the ticket in Manage and Shiftctl reflects it. No two-window reconciliation.
• Anything still open at sign-off carries into the next engineer's on-call handover brief instead of dying on a board — the day shift starts already knowing what is still burning.

For an MSP whose paging runs on SMS and chat, that is a standalone replacement for a general-purpose pager sitting beside ConnectWise: alert in, routed to the engineer on call, escalated until acknowledged, ticketed in Manage, and carried into the next handover — one loop, one bill. The two-setup choice is honest, though. If a client contract requires an inbound number people can dial, Shiftctl doesn't do that yet.

Getting from bodge to rotation

• Write down who is actually on-call for the next four weeks — the real answer, not the stale sheet
• Define your after-hours severity contract: what pages immediately, what waits for morning
• Pick one rotation as the single source of truth and retire the spreadsheet
• Point your RMM/monitoring alerts at the rotation and send a test page end-to-end
• Connect ConnectWise Manage so pages create and sync tickets automatically
• Make sign-off force a resolve-or-carry decision on every open alert before handover

Frequently asked questions