How to Choose On-Call Software for a Small Team

Write the minimum job

For a seven-person team, a useful requirement might be: one primary and one backup, weekly changes, temporary cover, two tested contact channels, and a record of who acknowledged each incident. This is an illustrative scope, not a universal design. A 20-person team with several service owners may need distinct rotations and permissions.

Separate required behavior from convenience. Start with the escalation policy builder to define the steps you will ask each candidate to demonstrate.

Use a comparable worksheet

Do not count a roadmap answer as a trial pass. Record “not confirmed” beside anything you could not demonstrate.

Test Slack as three separate requirements

A message appearing in a channel is notification. An acknowledgement button that changes incident ownership is an action. A resolution action that updates the incident is another. PagerDuty's Slack guide (opens in a new tab) documents a concrete integration, but it is not evidence that another provider supports the same operations.

For each action you need, try it as an ordinary responder, inspect the incident audit trail, and check what happens if Slack is unavailable. An admin-only demo can conceal a permissions problem your on-call will encounter later.

Calculate the complete cost

Use your written quote and observed trial workload:

annual operating estimate =
  annual subscription for required roles and features
  + estimated usage charges at your expected volume
  + administration hours × your internal hourly planning rate
  + one-time migration and training effort

Keep one-time and recurring lines separate when comparing later years. Include minimum commitments, currency, taxes where applicable, required add-ons, SMS/voice geography and what happens at higher volume. This is a worksheet, not a statement about any provider's current prices or contract terms.

Run one realistic trial before choosing

Create a disposable service. Page the scheduled primary, change the temporary cover, repeat at a handoff boundary, withhold acknowledgement and observe the backup, then resolve. Time the setup work and ask a second teammate to perform the same operations from your notes.

Reject an option that fails a requirement you cannot safely operate without, even if it wins the cost column. If the remaining options differ mainly in administration effort, use that measured trial effort in the comparison rather than a vague “simpler UI” score.

The relationship disclosure below matters: oncall.fyi is made by the team behind MonoDuty. This worksheet does not assert that MonoDuty supplies every schedule, Slack action or management capability listed here.

Seven-person budget example

For seven responders, count seats by the permissions each person needs, not by the total number of employees. Then price the same notification countries, monthly usage, escalation behavior and administration access in every quote. An inexpensive plan that excludes a required backup action is not a complete candidate.

Use a fictional quote to check the arithmetic: seven required seats at 12 currency units per month is 84. Add a required 20-unit feature and an expected 15-unit usage line, and the recurring subtotal becomes 119 per month or 1,428 over twelve identical months. Those numbers are invented; substitute the dated written quote, applicable commitment, currency and taxes. Keep setup and training outside the recurring subtotal.

Calculate a second scenario with twice the expected delivery volume and an eighth responder. Ask which line changes and whether a minimum commitment or plan boundary applies. Leave unquoted usage as unknown rather than zero. The renewal worksheet explains how to compare commitment and billing frequency separately.

Test whether a new teammate can operate it

Give a teammate who did not configure the trial five tasks: identify who is on call, create temporary cover, acknowledge a demo incident, reach the backup and locate the incident history. Supply the vendor documentation and the short notes you expect a real responder to use. Observe the trial without explaining every step.

Record completion time, wrong turns, permission failures and whether the authoritative incident state matches the person's intention. In particular, check that temporary cover ends at the intended time and that an acknowledgement belongs to the intended responder. An interface that looks simple to its administrator may still require training for those operations.

Repeat a failed task after fixing the configuration or improving the operating note. Decide which tasks must be self-service and which can require an administrator. Keep those choices in the acceptance table so a broad incident-management suite and a focused pager are judged against the same required work.