Most ServiceNow ITSM implementations don’t fail at go-live. They fail in discovery — when the planner asked five questions about incident and zero about change, when the major incident scope was assumed instead of confirmed, when the catalog item story shipped without its variables, UI policies, and fulfilment stages folded in.
This post is a walkthrough of how Phyllis runs an end-to-end ITSM implementation — at the altitude of what arrives in your Agile backlog, not the altitude of the demo.
If you’re scoping an ITSM rollout, recovering a stalled one, or trying to understand what AI-assisted ServiceNow delivery should actually feel like, this is the shape of the work.
Discovery runs against the live instance
Phyllis’s planning loop is built around a single rule: never invent what you can look up. Before discovery questions begin, Phyllis reads the target instance — tables, flows, business rules, plugins, scan posture — and grounds the conversation in what’s actually there.
For ITSM specifically, the planner walks the customer through every essential implementation area, in order, with informed discovery questions for each:
- Incident Management
- Major Incident Management (when in scope)
- Problem Management
- Change Management
- Service Catalog & Request Management
- Service Operations Workspace
- SLA Management
- Knowledge Management
- Notifications & Communication
- Reporting & Dashboards
- Self-Service & Portal
- Groups, Roles & Access
- Integrations & Data
If an area hasn’t been mentioned, Phyllis asks — it does not skip silently. An ITSM rollout scoped to only incident management is the most common failure mode in the industry, and the planner is built to refuse it.
Plugin verification, not plugin assumption
Phyllis doesn’t guess what’s installed. The plugin baseline for the engagement is verified against the live instance before any story that depends on it is proposed. If a required module isn’t active, the first Configuration story in the plan is the plugin activation — staged, ordered, and explicit.
This sounds boring. It’s the difference between a plan that builds in week two and a plan that stalls in week one because someone assumed a plugin was on.
Discovery has the right depth
To show what informed discovery actually looks like, take Major Incident Management. When MIM is in scope, Phyllis doesn’t ask “do you want major incidents?” and move on. It walks the customer through the actual business decisions a MIM rollout encodes:
- Does the candidate incident survive elevation, or is a new MI record created with the candidate as a child? This is a business decision that has to be asked, never defaulted.
- Which group reviews candidates and can promote or reject them? The group has to exist first; the configuration follows.
- Which fields carry over from the candidate to the new MI?
- Should MIM notification links open in Service Operations Workspace or classic UI? Only meaningful if SOW is in scope — Phyllis threads that dependency through automatically.
- Should communication task emails default to direct, cc, or bcc recipients? The out-of-box default is almost always wrong for customer-facing updates.
And Phyllis gets the terminology right. MIM promotion is implemented via Major Incident Trigger Rules — not Business Rules. Most planning tools we’ve seen describe MIM promotion as a “Business Rule” and ship the engagement with a misnamed artefact in the design document. Phyllis won’t.
Every essential implementation area has the same depth of discovery underneath it.
Story consolidation is enforced, not optional
The most common backlog pathology in ServiceNow Agile is the over-split catalog item: one story for the item, one for its variables, one for UI policies, one for fulfilment, one for approvals — five stories where there should be one.
Phyllis enforces consolidation. One story per catalog item, with variables, UI policies, fulfilment stages, and approvals as acceptance criteria. One story per form layout. One story per notification. SLAs grouped by process. Workspace and classic UI as separate workstreams.
The result is a backlog where each story is a unit of reviewable work, sized against actual system complexity. Not a pile of half-cards that have to be re-stitched at implementation time.
Epics before stories — and the human approves the grouping
Before any story lands in your backlog, Phyllis groups them into epics by feature area — “Incident Intake”, “MIM Automation”, “SLA Breach Notifications” — and presents the grouping for approval. Stories landing in a backlog without epic structure are unworkable for the downstream developer, so this step is blocking.
You see the proposed epic list, with story counts per epic, and you approve or revise before anything is committed to the backlog. The candidate stories are shown alongside, in full, so there are no surprises when they appear in your Agile board.
Dedup discipline — listing before proposing
The other backlog pathology is the duplicate notification. Every engagement creates a “Major Incident — Stakeholder Update” notification because the planner assumed one didn’t exist. Three engagements later, the customer has four of them.
Phyllis does the inverse. Before proposing any new notification, email layout, template, flow, or schedule, the existing matches are surfaced to the user with the option to reuse, create new, or compare. Only after an explicit “create new” does the proposed configuration land in the plan.
The same discipline applies to changes. Before any story that renames, deprecates, or removes an existing artefact, every dependent is listed and called out as a Blast Radius on the change story. The most expensive defect class in ServiceNow delivery is “we changed X and forgot Y also uses X.” The fix is one rule: list before you change.
Implementation runs the same loop in reverse
Once the backlog is in your Agile board, each story flows through a four-phase implementation loop:
-
Requirement analysis — parse the story, identify affected tables, list dependencies, clarify ambiguities. Crucially, Phyllis validates every table and field name against the live instance before referencing it. If a planner shipped a wrong scope-prefixed name or a hallucinated field, it surfaces as a blocking question rather than silently swapping.
-
Technical design — the full list of artefacts to create or modify, in execution order, with rollback considerations. Presented for approval before any write hits the instance.
-
Implementation — the approved plan executed with ServiceNow best practices enforced inline. Proper logging. Null checks. No hardcoded sys_ids. Script includes for reusable code. Correct naming for custom and scoped artefacts.
-
Verification — every created record is verified against the approved plan. If mismatches are found, Phyllis fixes them and re-verifies. Only after the verification passes does the story close out.
The architect at the gate sees the plan, the diff, the verification result, and the design notes in the same record. Sign-off is a judgment call, not a scavenger hunt.
Documentation is sourced, not narrated
Every implementation closes with a Requirements Document that consolidates the business context, scope, discovery findings, story summary, dependencies, assumptions, risks, and non-functional requirements. Every claim is cited back to the record or finding that produced it.
When the auditor asks “why does the change approval flow skip CAB for standard changes?” the answer is in the design document, with the change model cited. When the architect asks “why did we configure MIM creation mode the way we did?” the answer is in the discovery findings, with the rationale captured at the moment the decision was made.
This is what CMA-grade means in practice. Not “thorough” — sourced.
What you actually get at the end
For a mid-sized ITSM rollout — incident, problem, change, request, knowledge, plus SLAs, notifications, portal branding, and reporting — Phyllis produces:
- A backlog of epics and stories, properly consolidated, with acceptance criteria written against the real system
- Each story arriving at the architect’s desk with the diff, the verification result, and per-story design notes attached
- A consolidated Requirements Document with sourced citations for every decision
- A Portal Branding epic delivered early (mandatory for ITSM, never silently skipped — gated on brand-team approval)
- A clean dedup posture across notifications, layouts, templates, flows, and schedules
The team shape doesn’t have to grow with the scope. The senior architect owns the gate. Phyllis runs the loop. The bar on what arrives at the gate goes up.
What to plan for if you’re scoping this
Three things have to be in place for Phyllis to run an end-to-end ITSM implementation cleanly:
- A target instance Phyllis can read. Read-only access is enough for the planning phase. Scoped write access is required for implementation.
- A named architect who owns the gate. Phyllis stages every change for review. The model breaks if there’s no architect to sign.
- An update set strategy. One per story, named consistently, scoped to the module. Phyllis follows the strategy you set; it doesn’t pick one for you.
If those three are in place, the rest is the work itself — and that’s what Phyllis is in the loop to do.
Where this lands
A clean ITSM implementation is not a heroic engagement. It is an engagement where discovery covered every essential area, plugins were verified before stories that depended on them, the MIM business decisions were asked rather than assumed, catalog items were consolidated into single stories, the backlog was approved before stories were created, dedup ran before any new artefact was proposed, table and field names were validated before being referenced, every story was verified against the live instance before sign-off, and the design document was sourced citation by citation.
Phyllis is in the loop to make that the default, not the exception. The senior judgment that ServiceNow delivery depends on stays where it belongs — with the architect, signing reviewable changes, with the evidence already in the record.
If you’re scoping an ITSM rollout — or a stalled one you need to recover — book a session. We’ll walk a real story end-to-end against a real instance, and you’ll see exactly what arrives in your Agile backlog at the end of it.
— Regan
w.
