IT Service Desk · Agent blueprint · validated with 6 team members
Ticket Status Update Drafter
When a ticket appears or changes in the queue, the agent reads the ServiceNow ticket and drafts a status or resolution email in the team's standard structure. The analyst approves or edits it in one step, then it is sent through Outlook and the note is saved on the ticket.
72readiness · Standardize first
4–11 hback per week, of 25 h now
$12K–31Ka year
3–5 wkto build · size M
Build this after the team follows one procedure (see the training guide). Today too many cases take different paths for an agent to follow reliably.
Trigger
A new item appears in the ServiceNow queue, or an existing ticket has a status or work-note change that needs a requester update (team trigger: new queue item; follow-up triggers still to be confirmed).
Done when: The requester is satisfied and the ticket is closed, with the update sent and a resolution note saved on the ticket.
Needs: ServiceNow ticket: number, requester, short description, status, work notes, resolution details; Requester's email address and any reply received on the ticket; Team's status-update guidance from the Confluence KB (article to be identified); Standard email wording/template (to be confirmed); Next-update timing (from ticket or analyst)
What the agent does
- 1
Detect new or changed ticket needing a requester update · ServiceNowapiPower Automate flow triggered by the new queue item; later also by status changes or requester replies.
- 2
Read ticket status, work notes, requester reply and resolution details · ServiceNowapi
- 3
Look up status-update guidance and wording rules · ConfluenceapiUse the KB article that governs status updates, once the team names it.
- 4
Flag sensitive or leadership-urgent tickets for the analyst to write · ServiceNowaiRule for what counts as urgent or sensitive is not yet defined; start by flagging only what the team specifies.
- 5
Draft email: greeting, what was done, next step, next update time, ticket number · OutlookaiCopilot Studio drafts in the team's structure; ticket number included so the requester can reply.
- 6
Show the draft to the analyst to approve, edit or reject · OutlookpersonPolicy bars unattended sending. The analyst approves every email before it goes out.
- 7
Send the approved email to the requester · Outlookconnector
- 8
Save the update or resolution note on the ticket · ServiceNowapiWrites to the record; runs only after the analyst's approval.
- 9
If the requester replies, re-read the ticket and redraft the update · ServiceNowaiTargets the roughly 19% of cases where new information forces a rewrite.
Decisions the agent makes
| Decide | Rule | Source |
|---|
| What the update says (content and structure) | Team's description: greeting, what was done (status and outcome), what happens next, when the requester will hear again, and the ticket number so they can reply. Same wording for every audience (project managers, field, office). | The team |
| Whether a standard template is used or each analyst words it themselves | Not known yet: team answers differed slightly. Ask the team. | Not known yet |
| Which tickets are urgent leadership requests and how they are handled differentl | Disputed: most said almost never (60%), the rest said often. No handling described. Ask the team. | Not known yet |
| Whether to approve and send each email | The analyst approves every email, as required by policy (no unattended actions). The team named no further approval checks or sender restrictions. | Team, confirmed by data |
| When to wait before sending or resuming | Pause when waiting on another team or on a requester reply. The team's split is 50/50, and the resume rule is not defined. | The team |
| Which KB article governs updates | Not known yet: team said to follow the KB but did not name the article. Ask the team. | Not known yet |
| Whether the ticket can be closed | Team: closed when the requester is satisfied. How this is checked is not defined. Company rule: every ticket needs a resolution note before closing. | The team |
Where a person signs off
- The analyst approves or edits every outgoing email before it is sent.
- The analyst confirms the resolution note before it is saved on the ticket, in the same approval step as the email.
Exceptions
| When | What the agent does |
|---|
| Waiting on another team or on a requester reply (about 16% of cases pause, median about 2.1 hours; the team splits 50/50 on the cause) | The agent holds the case and resumes when the ticket changes or the requester replies. It then redrafts with the new information and sends it to the analyst for approval. |
| Requester replies with new information, forcing a rewrite (about 19% of cases re-edit the message body) | The agent redrafts from the latest ticket state and shows the analyst what changed since the last update. |
| Urgent request from leadership (disputed: 60% say almost never, others say often) | Not described by the team. Until defined, the agent flags the ticket and passes it to the analyst to write without a draft. |
| Ticket is unusual or sensitive, or ticket data is missing or unclear | The agent hands the ticket to the analyst with what it found and does not draft. |
| Analyst rejects or heavily edits the draft | The agent logs the reason so the template and prompts can be improved during the pilot. |
Build with
- Copilot Studio: Agent that reads ticket context and drafts the update in the standard structure.
- Power Automate: Triggers on ServiceNow changes, calls the ServiceNow and Confluence APIs, manages the approval and sends through the Outlook connector.
- Microsoft 365 Copilot: Optional help for analysts editing drafts in Outlook.
- Outlook connector: Sends the approved email to the requester.
Skills: Copilot Studio, Power Automate, ServiceNow API integration, Prompt and template design, Pilot testing with analysts
Before building
- Service account for the agent with ServiceNow API read/write access to tickets and work notes
- Outlook connector licensed and permitted in Power Automate, with a shared mailbox or send-on-behalf setup
- Confluence API access to the status-update KB article
- Agreed standard template and wording, since the team is not fully consistent (readiness verdict: standardize first)
- Copilot Studio and Power Automate licenses for the builder and approvers
- Rule for flagging urgent or sensitive tickets
Risks
- Policy bars unattended sending, so every email needs an analyst approval and the time saved is limited to drafting.
- Requester replies cause rework in about 19% of cases, which could produce drafts that are stale or wrong.
- Inconsistent wording across the team may lower trust in the drafts if no template is agreed first.
- Leadership-urgent tickets are undefined and could get a wrong tone or delay.
- Sensitive ticket details could be exposed in the email if the agent includes work notes meant to be internal.
How we'll know it worked
- Median work time per update (baseline 4.2 min; 3.9 min on the main path)
- Team hours per week on status updates (baseline 24.9)
- Share of cases with message-body re-edits (baseline 18.6%) and redone after a pause (baseline 15.7%)
- Share of drafts the analyst sends unchanged versus edited or rewritten
Still to answer before building
- How are urgent leadership requests handled differently (priority, wording, speed, approval)?
- Which KB article or articles govern status updates, and what do they require?
- Is there a standard template, or does each person word the message themselves?
- What does 'requester is satisfied' mean in practice, and is there a check before closing?
- How are other teams chased or handed work during a wait?
- Why does the Outlook step take a median of about 220 seconds when editing takes about 10 seconds?
- Which ticket events beyond a new queue item should trigger an update (status change, requester reply, resolution)?
- Which ticket details are internal and must never appear in the email?
Where the team disagrees
Settle these first: an agent needs one rule, and new hires get mixed answers today.
- Wait reason is split evenly between another team and the requester's reply.
- Frequency of unusual (leadership-urgent) cases is split between almost never and fairly often.
Evidence
- too many different paths for an agent to follow reliably; the training guide comes first
- 83% of cases follow the same steps
- 25 team hours a week
- 34% of cases redo steps
Observed main path (83% of cases): Microsoft Outlook → Edit Message body
Handover spec for the builder (text) →
Designed by AI from how the team did this work (2026-10-19 to 2026-10-23), the company's tools and its rules. A starting point for the builder: confirm system access and approvals before building.