ServiceNow ITSM and IT capacity planning: two jobs, two systems of record

ITSM and capacity planning are not the same job

Many 20–500 person IT departments already run ServiceNow for ITSM: incidents, changes, CMDB, catalog. They often have not bought ServiceNow Resource Management (the SPM module). The remaining gap: who is allocated for the next 8–12 weeks, planned vs actual, the capacity committee. That is not a second ITSM. It is a capacity system of record.

Canonical page: ServiceNow ITSM + Workload, capacity SoR. Workload does not replace ServiceNow. Workload does not ship a ServiceNow connector. Native timesheets are Jira Tempo, Azure DevOps, Toggl, Clockify, and CSV import.

The phrase “vs ServiceNow” attracts the wrong reader: an enterprise PMO comparing SPM Resource Management. The useful angle is “ITSM + capacity”: keep run where it is, finally give allocations a system of record.

Table: who is the system of record

IT job	ServiceNow ITSM	Workload
Incidents / changes / CMDB	System of record	Out of scope
Run / service queue	Yes	No — do not duplicate
Named allocation 8–12 weeks	No (unless SPM RM is paid)	Yes — Hard / Soft / Tentative
Planned vs actual (PVA)	No	Yes — dashboard and /ops pack
Capacity committee (cap 7)	No	Yes — one bell per week
SPM Resource Management	Enterprise add-on	Do not replace — not required for the tactical IT layer

What ServiceNow does well

ServiceNow ITSM is the right place for run: incident tickets, change workflow, CMDB, catalog, SLAs. Teams already know ITIL. Duplicating that queue in a capacity tool creates two queues and no SoR. The approved change stays in ServiceNow. Named allocation is planned elsewhere.

Same reflex as a heavy PPM: complementing Planview/Sciforma is not the same job as complementing ITSM. The PPM keeps portfolio governance. ServiceNow keeps run. Workload keeps allocations.

The CAB (Change Advisory Board) decides whether a change is safe to ship. It does not decide whether the network team still has 12 net days in the next six weeks. Mixing those meetings produces an ITSM “go” and a silent overload. Two committees, two questions, two systems of record.

What capacity planning must own

IT capacity planning answers “do we have enough net capacity for the portfolio?” It measures working days minus leave and run, allocates named people, detects conflicts, and compares the plan to timesheet actuals. See IT capacity planning and capacity vs resource planning.

Without that layer, IT still arbitrates in Excel beside ServiceNow. ITSM says the change is “go”. Excel says (too late) the team is at 140%. The committee gets 40 alert rows. Nobody has a single system of record for allocations.

Planned vs actual (PVA)

Actuals do not come from ServiceNow incidents. They come from timesheets: Jira Tempo, Azure DevOps, Toggl, Clockify, or CSV. Workload confronts those actuals with the plan. A large variance feeds the capacity pack — not the incident queue.

The /ops pack: a human decides

The HITL capacity pack lives at /dashboard/ops after sign-in. Cap 7 proposals, one bell per week, human vote. Silence at close = snoozed, not rejected. No action outside the pack. Workload does not write the CMDB and does not create incidents. There is no automatic write to ServiceNow, and no MCP write in this flow.

Anti-patterns: Excel, incident-projects, 40 alerts

The most common pattern: ServiceNow for tickets, Excel for “who is on what”. ITSM says the change is go. The spreadsheet, too late, says 140%. Nobody is the allocations SoR. Leave, run, and projects overlap with no conflict detection.

Second anti-pattern: turning every incident into a Workload project. The incident stays an ITSM ticket. A capacity project is planned work (evolution, migration, program) with named people allocated. Mixing the two recreates the queue in the wrong tool.

Third: 40 alert rows by email. The capacity committee votes a pack: at most 7 proposals, one bell, one Monday. That is not a second incident stream. See the weekly rhythm below.

Weekly rhythm: SN run, Workload pack

1. All week — incidents and changes in ServiceNow. The CMDB stays the asset truth.
2. Continuously — Hard / Soft / Tentative allocations in Workload. Conflicts visible before the committee.
3. Timesheet — Tempo, Azure DevOps, Toggl, Clockify, or CSV feed actuals. Not SN tickets.
4. Monday — /ops pack (cap 7). PMO or admin Approves, Edits, Not this week, or Mute.
5. Committee — RAG / freeze on capacity, not on the ITSM queue. Silence = snoozed, not rejected.

Who votes: PMO and admin. The CIO sees the pack, vote optional. Team managers do not get the queue. The ITSM owner does not arbitrate allocations in ServiceNow — and Workload does not arbitrate P1s.

Why this is not ServiceNow Resource Management

SPM Resource Management is an enterprise portfolio module: heavy rollout, mature PMO, SPM budget. For an internal IT department of 20–500, the tactical layer (8–12 week allocations, PVA, cap-7 committee) does not require buying SPM. This is not a feature-for-feature duel. It is “you do not need it for this layer”.

Same suite family as Sciforma / Planview: complement, do not replace ITSM. Details: Keep ServiceNow. Put capacity in Workload.

How ITSM and capacity connect day to day

1. The project or change is approved in ServiceNow — it stays there.
2. Named allocation (Hard / Soft / Tentative) is planned in Workload.
3. Timesheet actuals (Tempo, Azure, Toggl, Clockify, CSV) confront the plan.
4. The /ops pack proposes variances to the committee (max 7). A human Approves.
5. Incidents keep living in ServiceNow. The pack does not list them.

Optional later bridge: CSV, IntegrationHub, or REST v1 (members, allocations, timesheet). Not a Marketplace connector. No incidents → projects automatically. No CMDB → teams automatically.

FAQ

Does Workload replace ServiceNow?

No. ServiceNow stays the ITSM. Workload does not create incidents and does not write the CMDB. Run in ServiceNow, capacity in Workload.

Do you need to buy ServiceNow Resource Management?

Not for the tactical capacity layer of a 20–500 IT department. SPM RM remains an enterprise add-on. Workload carries allocations, PVA, and the committee.

Does Workload have a ServiceNow connector?

No. Native timesheet = Jira Tempo, Azure DevOps, Toggl, Clockify, CSV. A bridge uses CSV, IntegrationHub, or REST v1 — not a Marketplace connector.

Where to start

Read the landing ServiceNow ITSM + capacity. Import teams and allocations (CSV, ~30 min). Connect a timesheet (Professional). On Monday the /ops pack proposes variances — a human votes.

14-day trial, no credit card: create a Workload account. After sign-in, the capacity pack is at /dashboard/ops. SoR = Workload allocations. Run = ServiceNow.