Week one is loud and week two is quiet
Hypercare catches the failures that announce themselves. The login that does not work, the catalog item that errors on submit. Those surface in the first five days because thirty people are watching one system and each of them has a direct line to somebody who can fix it. Week two is when the room empties.
I ran the data and integration side of an ITSM go-live for a distribution business last year. Nine hundred internal users, four assignment groups off a legacy tool over a weekend in March, hypercare staffed for five working days with the partner beside the service desk. On day six the partner went back to their own office. On day nine we worked out that nobody had been paged for a P2 since cutover.
The failures that survive hypercare share a shape. They need elapsed time, real volume, or a calendar boundary before they appear, and week one supplies none of those. A structured review in week two finds them while the project still has budget and the people who built the configuration answer their phones.
Notifications that only fire for a state nobody reaches
The paging gap was a notification condition. The rule sent to the on-call group when priority was 1 or 2 and the state moved to a value the legacy process used and the new one skipped. In testing somebody set that state by hand to prove the notification worked, and it did. Live, the work arrived through a group queue and went from new to in progress without ever touching that state.
Notification conditions are written against states, and states get adjusted late in a build without anyone circling back. The condition that shipped was right for the process as drawn in February and wrong for the process as trained in March. Nothing throws an error. The rule evaluates, the condition returns false, and the log records that it did what it was told.
Check by counting rather than by testing. Pull the notification log for the first ten working days, group it by rule, and list every active rule that sent zero messages. Put it in front of whoever owns the process and ask whether zero is right. The rule that should have fired forty times shows up the moment its count is on screen, which is worth pinning down while scoping a ServiceNow ITSM implementation.
Assignment groups with one name in them
Four groups moved and one had a single member. It covered field engineering for two depots, built from a legacy queue three people used to watch, two of whom had left during the project. Nobody flagged it, because through hypercare the remaining engineer picked up everything inside the hour. He took a week off from day eleven. Nine records sat in the queue unassigned, the group record had no manager, and escalation had nowhere to go.
The service desk saw those tickets as assigned to a group and stopped chasing. One depot rang the mobile of an engineer who left in January. Run a membership count over every active assignment group, treat anything under three members as a finding, and record the named cover plus a manager who still works there. The runbook for the week you are away makes the same case for platform admins.
Service level clocks that pause on the wrong calendar
Every SLA definition carries a schedule, and the schedule decides when the clock runs. Point it at working hours by mistake and a P1 raised at 18:40 pauses overnight, then breaches at lunchtime with the customer already furious. Point it at twenty-four seven by mistake and a Friday afternoon request burns through the weekend and breaches before anyone could touch it.
We had both, in one instance, for the same reason. The P1 definition had been cloned from the request definition during build and kept the eight to six schedule. For nine days no P1 arrived outside working hours, so nothing showed. The first evening one came in on a Tuesday and the clock stopped at 18:00 while two people worked until half past ten.
The check needs closed records rather than theory. Take one completed record per SLA definition, open its task SLA record, and read business elapsed time against actual wall clock duration. Where they differ, make somebody say out loud why that is correct. Then confirm the schedule holds this year's public holidays, because one carrying last year's dates looks normal in a list view and is wrong on the first bank holiday.
Inbound email and scheduled jobs meet real volume
Inbound email actions behave differently at twenty messages a day than at four hundred. The action that creates a record keys on the watermark or the subject line, and anything arriving without a clean match creates a second record instead of updating the first. Automatic replies do it. Threads forwarded in from a distribution list do it. So does a mailbox rule that rewrites the subject line.
Week one volume is artificially low, because the desk is pushing everyone to the portal. In week two the mailbox goes back to normal and the duplicates start. Count records created by the email user across the first ten days, group them by short description, and look at anything appearing twice in an hour. We found nineteen pairs and one thread that had spawned six incidents.
Scheduled jobs get tested by clicking execute now, which proves the script runs and proves nothing about the schedule. Our job for reassigning stale records was set weekly on a Sunday in a timezone nobody checked, and its first real execution landed after the project closed. Open the scheduled job list, sort by next action, and confirm every active job has completed a run on its own trigger with a log entry you can point at.
Test data that was too polite
Integrations pass testing because the test data is clean. The records that break them are the ones no tester would build by hand. A user with no manager. A cost centre closed two years ago that still sits on forty active assets. A configuration item whose owning group was deleted during the migration.
Our nightly HR feed set the manager reference from an employee number. Eleven people in the source had a blank manager because they report to the board. The integration logged a clean success, wrote the user, and left the reference empty, so every approval routing to the requester's manager sat unrouted with no error raised anywhere. Error handling that actually pages someone is the longer argument for why a silent success costs more than a failure.
Reconcile counts instead of reading logs. For each integration, compare source rows against records created and updated for the same window, then account for the difference record by record. A gap of eleven is a finding even when every log line says success.
Who runs the review and what closes each check
The platform owner runs the review, not the implementation partner, and the date goes in diaries before go-live. Ninety minutes, one room, the service desk lead, the integration developer and the process owner for every group that moved. The partner attends to answer questions and does not hold the pen. Anyone negotiating support after go-live should write this meeting into the arrangement.
Each check closes against evidence rather than opinion. A notification rule closes on a message count from the log. An assignment group closes on a named second member and a manager who still has a badge. An SLA definition closes on one completed record where business elapsed time matches the wall clock. A scheduled job closes on a log entry from an automatic run. An integration closes on a reconciliation that balances.
Book the review while you still have a project manager to put it in calendars and a contract covering the partner's attendance. Name an owner for each check and write the one sentence of evidence that closes it. If the answer is that somebody tested it during build and it worked, the check is still open.
