|
This guide walks ServiceNow administrators and incident management teams through implementing on-call scheduling—the automated, predictable mechanism for routing incidents to the right responder at the right time. The first section frames on-call scheduling and its core capabilities. Step-by-step configuration begins in Section 3.
On-call scheduling is the primary mechanism for applying exactly the right level of incident response rigor to each incident severity level. The implementation pattern activated in this guide demonstrates the full automation workflow: from schedule publication through escalation tracking.
|
In this guide
|
1. What Is On-Call Scheduling
2. Prerequisites, Plugins & Roles
3. Complete Implementation (Steps 0-7)
|
4. Success Metrics & KPIs
5. Validation Checklist
|
|
| 1 |
What Is On-Call Scheduling |
|
On-call scheduling is a ServiceNow capability that automatically routes incidents to the appropriate responder based on published schedules, rosters, and escalation policies. It provides a single source of truth—a published schedule that drives all automation, notification, and escalation workflows—eliminating manual "who's on-call?" hunting. Organizations implementing on-call scheduling reduce Mean Time to Acknowledgment (MTTA) from 15–30 minutes to under 5 minutes, improve SLA compliance to >95%, and achieve predictable 24/7 incident response coverage with zero coverage gaps. On-call scheduling is the foundation of zero-touch incident response: responders receive the right notification through the right channel at the right time, management sees real-time escalation logs and on-call health metrics, and the organization delivers consistent, predictable incident response.
Core On-Call Scheduling Features
Schedule: A schedule specifies the times that shifts are active. For example, a company that wants coverage of tasks around the clock would use a 24/7 schedule. Companies that provide support around the globe could use a follow-the-sun schedule to cover time zones across continents.
Shift: A shift defines the specific hours for a rotation, which determines which team member is on-call at a given time. A single schedule can contain multiple shifts to provide coverage for different times of the day or week. Each shift specifies the exact time of day (e.g., 9:00 AM to 5:00 PM) for which a roster is active.
Roster: A roster is a set of members that are on call for a shift. Because there is typically a roster for each escalation level (primary, secondary, tertiary, etc.), there are typically multiple rosters for a shift. The members of any roster are contacted in the order that is defined by the escalation policy.
Roster Members: The members of a roster are the users that have been added to a single roster. Roster members typically have the itil role. During an assigned shift, members must be available to act if notified of an escalation. Users must be members of the same group. The shift manager (rota_manager role) does not have to be a roster member.
Rotation: A rotation is created within a shift to determine the sequence in which team members are assigned the on-call duty.
On-call Trigger Rules: Defined conditions that will automatically trigger a workflow when conditions are met. Typically these are used to automatically assign a task record, such as an incident, to an on-call user or group.
Australia Release – Enhanced On-Call Capabilities
Enhanced Service Operations Workspace for improved visibility
Improved escalation tracking and comprehensive reporting
Refined notification delivery with better failover handling
Enhanced mobile app for on-call responders
|
| 2 |
Prerequisites, Plugins & Roles |
|
Required Plugins
Before starting, verify these plugins are installed:
| Plugin |
Plugin/App ID |
Purpose |
| ITSM Base |
com.snc.service_management |
Foundational ITIL framework |
| Incident Management |
com.snc.incident_management |
Incident creation & routing |
| Service Operations Workspace ITSM |
sn_sow_itsm_cont |
Modern incident workspace + on-call management |
| On-Call Scheduling |
com.snc.on_call_rotation |
On-call schedule & escalation |
Key Roles & Responsibilities
Assign appropriate roles to team members:
| Role |
Access Level |
Key Responsibilities |
Example Person |
| ITSM Admin |
rota_admin |
Configure plugins, escalations, tracking; manage system-wide settings |
Developer/Admin |
| Shift Manager |
rota_manager |
Manage schedules, rosters, coverage, approvals; monitor team on-call health |
Team Lead/Manager |
| On-Call Responder |
itil |
Acknowledge alerts, respond to incidents, set notification preferences |
Specialist/Engineer |
Prerequisites
Technical:
ServiceNow Australia release (or later)
ITSM Standard or higher license
All required plugins (see table above)
Email configured; optionally SMS via Notify or Twilio
Organizational:
Executive sponsor committed to adoption
ITSM Administrator (rota_admin role)
Shift Managers (rota_manager role)
On-Call Responders (itil role) with current contact info
Clear coverage requirements documented
|
| 3 |
Complete Implementation (Steps 0-7, 4 Weeks) |
|
The on-call scheduling implementation follows a 7-step process spanning 4 weeks. Each step builds on the previous, from schedule creation through production validation. Complete each step in sequence. Do not skip testing (STEP 6) before go-live.
|
STEP 0 Establish Foundation & Readiness Week 1
|
|
Before configuring, align on terminology and confirm prerequisites.
• Review terminology: Schedules → Shifts → Rosters → Rotations → Escalations
• Document coverage requirements (24/7 vs. business-hours)
• Verify technical prerequisites
• Confirm user data (email, phone, time zone) and get executive approval
|
|
STEP 1 Define and Publish On-Call Schedules Week 1-2
|
|
What This Step Accomplishes
You will create a published on-call schedule in ServiceNow that defines which team member is on-call at any given time. Responders must see this schedule in Service Operations Workspace (SOW).
Why This Matters
A schedule is the source of truth for who is on-call. Without it, responders don't know they're scheduled, and escalations don't know where to route incidents. Forgetting to publish the schedule is the #1 reason pilots fail.
How to Execute
• To validate that On-Call Scheduling is installed in Service Operations workspace, navigate to Service Operations Workspace > Configurations using the filter navigator
• Validate that On-Call Scheduling has a "Configure" button instead of "Install" under ITSM core configurations
• Navigate to Workspaces > Service Operations Workspace > Schedules
• In Schedules, click on the tab "On-call schedules"
• Select the group you want to create a shift for within the group reference field next to the "Create shift" button
• Click [Create shift] > [Create New] and configure: Shift Name, Timezone, Coverage Model (24/7/business hours/follow-the-sun)
• Define shifts: For 24/7, create Day (8am-4pm), Evening (4pm-midnight), Night (midnight-8am)
• Set correct timezone for each shift (critical for multi-timezone teams)
• Add holiday calendar entries (corporate holidays, planned maintenance windows, team PTO)
• Preview schedule to verify 100% coverage with no gaps
• Click [Publish] – without this, responders cannot see the schedule and automation fails
Common Pitfalls
• Forgetting to publish: Schedule exists but responders can't see it. Must click Publish.
• Wrong timezone: Midnight transitions happen at wrong time; escalations fire at 3am.
• Overlapping shifts: Two people on-call at once creates confusion about ownership.
Success Criteria
• Schedule created with correct name and assignment group
• All shifts defined with zero coverage gaps
• Timezones correct for each shift
• Holiday calendar populated
• Schedule published and visible in SOW
• Responders can see the schedule in Service Operations Workspace
|
|
STEP 2 Configure Rosters and Automation Week 2
|
|
What This Step Accomplishes
You will assign responders to shifts and set up rotation rules. A roster defines which specific team member is on-call for each shift; rotation rules automate advancing to the next responder.
Why This Matters
Without rosters, your schedule has shifts but no responders. Without rotations, you're manually reassigning people each week. Automating rotations prevents admin overhead and ensures fair distribution.
How to Execute
• In the schedule, navigate to the shift
• Select the shift (e.g., "Day Shift") and click on Members
• Add responders in priority order: primary first, then Secondary [backup(s)]
• Assign multiple users per shift for automatic rotation
• Verify each user has: email, mobile phone (for SMS), timezone preference set
• Configure rotation interval: Weekly (most common), bi-weekly, or monthly
• Set rotation start date 1-2 weeks out (allows testing before live)
Common Pitfalls
• Rotation never advances: Check: is rotation enabled? Is start date in past? Is auto-advance checked?
• No backup responders: If primary unavailable, no fallback. Always add secondaries.
• Wrong responder active: Verify current date matches rotation schedule; rotation math based on start date.
• Missing contact info: Notifications fail if email/phone missing. Update user records before assigning.
Success Criteria
• Rosters created for each shift
• Responders assigned in correct order (primary, then backups)
• Rotation intervals configured (weekly, bi-weekly, or custom)
• Start dates set to allow testing
• Auto-rotation enabled
• Coverage verified with zero gaps
|
|
STEP 3 Configure Notification Channels Week 2
|
|
What This Step Accomplishes
You will configure how responders are notified when on-call. Alerts can be delivered via email, SMS, Teams, Slack, or voice calls depending on severity and responder preference.
Why This Matters
Most on-call implementations fail at notification, not configuration. If responders aren't reliably notified, they miss incidents, escalations time out, and SLAs breach. Test every channel before go-live.
How to Execute
• Configure Notify integration: Notify > Administration > Notification Methods
• Verify Email is configured and working (test with your SMTP settings)
• For SMS: Configure SMS provider (Twilio, Bandwidth, etc.) and test with real phone numbers
• For Teams/Slack: Install ServiceNow app and connect workspace
• Define notification preferences per responder: primary channel, backups, quiet hours, contact info
• Have responders update preferences: System Users > [Their Name] > Notification Preferences
• Assign channels to incident priorities: P1 (email + SMS + Teams), P2 (email + SMS), P3 (email only)
• Test all channels: create test incident, verify notification delivery in < 1 minute
Resources:
Common Pitfalls
• Email-only notifications: Email can be missed. Always have SMS or Teams backup for critical incidents.
• SMS not working internationally: Test with actual responder phone numbers; Twilio/Bandwidth support varies by country.
• Notifications bypass escalation: Ensure incidents assigned via escalation policy, not hardcoded email.
• Responders ignore alerts: Set expectations: acknowledge within 5 min (P1), 15 min (P2). Make it SLA.
Success Criteria
• Email notifications working and tested
• SMS/Teams configured and tested (if applicable)
• Responders updated notification preferences
• Channels assigned to incident priorities
• All responders confirmed receipt during testing
|
|
STEP 4 Define Escalation Policies Week 3
|
|
What This Step Accomplishes
You will create escalation policies that automatically route unacknowledged incidents to a secondary responder, then to management, then to an on-call catch-all. Escalations ensure no incident gets ignored.
Why This Matters
Without escalations, if the primary responder is away, the incident sits unassigned. Escalations close this gap by automatically notifying backups and managers at defined intervals.
How to Execute
• Navigate: Service Operations Workspace > Schedules > Schedules > select a shift > Escalation Policy > Open Team Record
• Click [Escalation triggers and policies]
• Define escalation steps based on priority: Step 1 (0 min) notify primary → Step 2 (5 min) notify secondary → Step 3 (10 min) notify manager → Catch-all
• Configure escalation triggers: No acknowledgment after X minutes, specific incident priority, time-of-day rules
• Set notification channels for each step: Step 1 (Email + SMS), Step 2 (Email + Teams), Step 3 (Slack), Step 4 (broadcast)
• Assign policies to incident assignment groups (e.g., "Platform Team")
• Assign policies to incident categories (e.g., "Database Outage", "API Failure")
• Enable escalation tracking: glide.on_call.enable_escalation_tracking = true
Common Pitfalls
• Escalation not firing: Verify: 1) Policy linked to incident group, 2) Incident priority matches policy, 3) Tracking enabled
• Too many escalations: Responders get alert fatigue. Start with 2-3 levels, not 10.
• Escalations timing out: Catch-all recipient unavailable or misconfigured. Always have a fallback team.
Success Criteria
• Escalation policies created for each service
• Clear step-by-step escalation paths defined
• Escalation triggers set (acknowledgment timeout, priority-based)
• Notification channels assigned per step
• Policies linked to incident assignment groups
• Escalation logging enabled
|
|
STEP 5 Configure Responder Preferences & Dashboard Week 3
|
|
What This Step Accomplishes
Responders will customize their on-call experience: notification preferences, unavailable times, and dashboard visibility. Dashboards show your team's on-call health: MTTA, acknowledgment rates, coverage.
How to Execute
• Each responder logs into Service Operations Workspace > Schedule
• Go to: On-Call notification Preferences
• Set primary & backup notification channels (email, SMS, Teams, Slack)
• Set quiet hours (e.g., "Do not notify between 11pm-6am unless P1")
• Verify timezone matches their location
• Confirm mobile phone number for SMS notifications
• Mark unavailable time if on vacation/conference/leave
• Access On-Call Management Dashboard: Self-Service > Dashboards
Success Criteria
• All responders updated notification preferences
• Quiet hours configured where appropriate
• Unavailable/PTO periods marked
• Dashboard accessible and showing current on-call responder
• Shift Managers trained on dashboard navigation
|
|
STEP 6 Conduct UAT (User Acceptance Testing) Week 3
|
|
What This Step Accomplishes
Your team will run simulated incidents to validate the entire on-call workflow: incident creation → responder notification → acknowledgment → escalation → resolution.
Why This Matters
UAT catches configuration errors before production. Testing responders see problems early when they're easy to fix.
How to Execute
• Schedule a UAT window (2-4 hours) with pilot team
• Create a P1 test incident: Incident Management > Create > Set Priority=P1, Assignment Group=Pilot Team
• Observe: Did primary responder receive notification? How quickly? Did they acknowledge?
• If no acknowledgment: Did escalation fire after 5 minutes? Did secondary get notified?
• Create P2 and P3 scenarios to verify different escalation paths
• Create after-hours incident to verify escalation to after-hours team
• Run full incident-to-resolution workflow
• Review escalation logs: verify clean sequence with correct timestamps
Success Criteria
• P1, P2, P3 incidents created and routed correctly
• All responders received notifications
• Escalations fired as expected
• Acknowledgment and escalation logs accurate
• SLA tracking working
• Responders trained and confident in workflow
|
|
STEP 7 Go-Live & Monitor Week 4 and Beyond
|
|
What This Step Accomplishes
You will launch on-call scheduling for production incidents with your pilot team. You'll monitor KPIs, gather feedback, and optimize based on real incidents.
Pre-Go-Live Checklist
☐ All Steps 0-6 completed and validated
☐ Responders trained and tested
☐ Dashboard accessible to managers
☐ Escalation logs enabled and verified
☐ Incident Management assignment groups configured for on-call routing
☐ Executive sponsor approval to proceed
☐ Support contact identified and trained
Monitor These KPIs Daily (Week 1-4)
| Metric |
Target |
Action if Below Target |
| MTTA |
< 5 minutes |
Review notifications; test channels; ensure responders are actually on-call. |
| Escalation Ack Rate |
> 90% |
If low, responders may not receive alerts. Check Notify configuration. |
| Coverage Gaps |
Zero |
Rosters may need adjustment. Review on-call dashboard for unscheduled hours. |
| Incident Resolution |
On track |
Escalations shouldn't slow resolution. Monitor MTTR. |
| Responder Satisfaction |
Positive feedback |
Adjust quiet hours, notification volume, or escalation timing. |
Week-by-Week Optimization
Week 1: Monitor & Stabilize
Watch the system closely. Expect issues and be ready to adjust. Hold daily standups to review metrics and troubleshoot.
Week 2: Gather Feedback
Ask responders: "Are you getting alerts? Are escalations sensible? Anything too noisy?" Adjust notification quiet hours, escalation timing, or channels based on feedback.
Week 3-4: Optimize
Fine-tune escalation policies based on real incident data. If MTTA is 3 minutes (target is 5), you're good. If 12 minutes, escalation timeout is too long.
Post-Go-Live: Expand or Iterate
• Add new teams to on-call scheduling (repeat Steps 0-7 for each)
• Introduce advanced features (on-call override, incident suppression, AI routing)
• Expand to follow-the-sun model (multi-region teams)
• Integrate with other tools (Slack, Teams, PagerDuty sync)
|
|
| Metric |
Baseline |
Target |
Why It Matters |
| MTTA |
15–30 min |
< 5 min |
Faster triage reduces MTTR |
| MTTR |
Varies |
15–20% ↓ |
Escalation eliminates delays |
| SLA Compliance |
70–85% |
> 95% |
Meet commitments consistently |
| Escalation Ack Rate |
60–75% |
> 90% |
Notifications working |
| Coverage Gaps |
5–10/mo |
Zero |
Automated scheduling works |
|
|
Pre-Go-Live Validation Checklist
☐ All Steps 0-6 completed and validated
☐ Responders trained and tested
☐ Dashboard accessible to managers
☐ Escalation logs enabled and verified
☐ Incident Management assignment groups configured for on-call routing
☐ Executive sponsor approval to proceed
☐ Support contact identified and trained
4-Week Implementation Timeline
| Week |
Focus |
Deliverable |
| Week 1 |
STEP 0 (Coverage Model) + STEP 1 (Schedules) |
Published schedule, coverage model approved |
| Week 2 |
STEP 2 (Rosters) + STEP 3 (Notifications) |
Configured rosters, tested notification channels |
| Week 3 |
STEP 4 (Escalations) + STEP 5 (Preferences) + STEP 6 (UAT) |
Escalation policies, UAT passed |
| Week 4 |
STEP 7 (Go-Live) + Monitor |
Live with pilot team, KPIs tracked |
Next Steps
Week 1–2: Finalize schedules for pilot teams
Week 3–4: Configure escalations, run simulated incidents (3–5 tests)
Week 5: Go-live with pilot teams; monitor daily
Week 6: Retrospective with pilot teams
Weeks 7+: Roll out to remaining teams based on learnings
Support & Resources
ServiceNow Documentation · On-Call Scheduling Process Workshop · On-Call Scheduling Starter Stories · Your ServiceNow Account Manager
|
|
Ready for Production
On-Call Scheduling done well is not a constraint on operations—it is the mechanism that makes confident, high-velocity incident response possible. When all 7 steps are complete and validated through UAT, your on-call scheduling is ready for production activation. Go live with confidence.
|
ServiceNow On-Call Scheduling Adoption Guide | Zero Touch IT Support | Major Incident Management
All content from MIM Implementation Guide V1 | Updated July 2026
|
