Generate Shift Handovers and Incident Timelines

Tier: Foundation · Workflow area: Knowledge management · ~25 minutes

This playbook builds two recurring artifacts from exports you already have: a structured end-of-shift handover drafted from the shift's ticket activity, and a defensible major-incident timeline reconstructed from ticket work notes and chat logs — each reviewed by the person who owns it before it ships.

When to use

• Every shift boundary on a 24×7 or follow-the-sun deskanywhere "what's still hot" currently travels by memory and goodwill.
• Major-incident postmortemsthe timeline section of every PIR, where the raw material is hundreds of chat messages and work notes nobody wants to re-read.
• Coverage gapson-call ending, long weekends, or a colleague going on leave mid-incident; the same recipe produces the "state of play" brief.

When NOT to use

• As a replacement for the verbal handover on live P1s. A burning incident hands over voice-to-voice; the generated document is the supporting record, not the substitute.
• When the source data is not written down. If the shift worked from DMs and hallway chats, the export is empty and the summary will be fiction. Fix the write-it-down habit first.
• For blame narratives. A timeline for HR or legal purposes is an evidentiary document — assemble it manually from raw records with counsel's guidance, not via a summarizer.

The recipe

1. 1.

   Export the shift's activity. From your ITSM: tickets created, updated, escalated or resolved during the shift window — number, priority, subject, latest work note, status. One CSV or a copy-paste of the list view is enough.

   Copy

   curl -s -u "$SN_USER:$SN_PASS" \
     "https://yourinstance.service-now.com/api/now/table/incident?sysparm_query=sys_updated_on>=javascript:gs.hoursAgoStart(8)&sysparm_fields=number,priority,short_description,state,assignment_group,work_notes&sysparm_limit=200" \
     | jq -r '.result[] | [.number,.priority,.state,.short_description] | @tsv'
   

2. 2.

   Draft the handover.

   Copy

   Write a shift handover for an IT service desk. Incoming shift reads
   this in 3 minutes. Use ONLY the ticket data below — no invention.
   
   Sections:
   ## Hot — needs action this shift (P1/P2, breaching or near-SLA;
   for each: number, one-line state, the NEXT ACTION and any promised
   callback time)
   ## Watch — could escalate (why, and the trigger to act on)
   ## Resolved this shift — one line each, only items worth knowing
   ## Waiting on others — vendor / user / change window, with who and when
   ## Housekeeping — recurring alerts silenced, workarounds in place
   
   If the next action for a Hot item is not clear from the data, write
   "NEXT ACTION UNCLEAR — outgoing shift to state verbally."
   
   Shift window: [times]. Data: [paste]
   

3. 3.

   The outgoing human edits for two minutes. They know what the data does not say: the user who will call back angry, the vendor engineer's actual name, the hunch about the flapping switch. They resolve every "NEXT ACTION UNCLEAR", then post to the handover channel. The draft saves fifteen minutes; the edit is where handover quality lives.

4. 4.

   For incident timelines, gather all streams. Ticket work notes, the incident bridge chat export, monitoring alert timestamps, and change records around the window. Timestamps are the skeleton — include them raw.

5. 5.

   Run the timeline reconstruction.

   Copy

   Reconstruct a major-incident timeline from these sources. Rules:
   - Every entry: timestamp | event | source (ticket note / chat / alert).
   - Use ONLY events present in the sources; never infer an event.
   - Normalize timestamps to [timezone]; flag any ordering conflicts
     between sources instead of resolving them silently.
   - Mark the candidate key moments: first alert, detection, escalation,
     diagnosis, mitigation, resolution — as SUGGESTED, for human review.
   - List gaps: periods over 20 minutes with no recorded activity.
   
   Sources: [paste]
   

   Sample of the output shape you want:

   Copy

   02:31 | pg-pool timeout alerts begin (monitoring) — SUGGESTED: first alert
   02:47 | INC0051233 raised P1 (ticket)
   03:05 | "rolling back payment-svc to 3.7.4" (bridge chat, @rkumar)
   GAP: 03:05–03:40 no recorded activity — verify with responders
   

6. 6.

   The incident manager verifies the key moments. Detection and mitigation times drive MTTR numbers and postmortem conclusions; the human confirms each SUGGESTED marker against raw sources and fills the flagged gaps from responder memory now, while it exists.

7. 7.

   Standardize and template both. Save the two prompts in the team prompt library (pb-49); the handover section headings become the fixed team format so every shift reads the same way.

Make it yours

• ServiceNow shopschedule the export query; on-shift techs run one saved prompt against it. If you have Now Assist, its incident summarization covers single tickets — this playbook's value is the cross-ticket shift view it does not give you.
• MSP / multi-client deskgenerate one handover per client from filtered exports rather than one blended handover; blended "Hot" lists get ignored.
• Slack/Teams-centric incident responseexport the incident channel directly (Slack: channel export; Teams: Get-MgTeamChannelMessage via Graph) — chat timestamps are usually the richest timeline source you have.

Quality check

• Every Hot item names a next action. A handover listing states without actions transfers anxiety, not work.
• Timeline entries carry sources. Any entry that cannot point to a note, message or alert gets cut — the PIR will be challenged on exactly these.
• Numbers spot-checked. Ticket counts and SLA claims in the handover verified against the queue view before posting; summarizers miscount.
• Gaps stay visible. The recorded-activity gaps the model flags go into the PIR as gaps — filling them with plausible narrative is how postmortems become fiction.