# Ticket Status Update Drafter

Agent blueprint, validated with 6 team members · Task: Status update emails to users · IT Service Desk · readiness 72/100 · Standardize first

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.

**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).

**Inputs:** 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)

**Done when:** The requester is satisfied and the ticket is closed, with the update sent and a resolution note saved on the ticket.

## Steps

1. Detect new or changed ticket needing a requester update (ServiceNow, api): Power 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 (ServiceNow, api)
3. Look up status-update guidance and wording rules (Confluence, api): Use the KB article that governs status updates, once the team names it.
4. Flag sensitive or leadership-urgent tickets for the analyst to write (ServiceNow, ai): Rule 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 (Outlook, ai): Copilot 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 (Outlook, person): Policy bars unattended sending. The analyst approves every email before it goes out.
7. Send the approved email to the requester (Outlook, connector)
8. Save the update or resolution note on the ticket (ServiceNow, api): Writes to the record; runs only after the analyst's approval.
9. If the requester replies, re-read the ticket and redraft the update (ServiceNow, ai): Targets the roughly 19% of cases where new information forces a rewrite.

## Approvals

- 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.

## Prerequisites

- 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.

## Measure after launch

- 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

## Decisions

| 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). | team |
| Whether a standard template is used or each analyst words it themselves | Not known yet: team answers differed slightly. Ask the team. | unknown |
| 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. | unknown |
| 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 + 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. | team |
| Which KB article governs updates | Not known yet: team said to follow the KB but did not name the article. Ask the team. | unknown |
| 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. | team |

## 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?

## Exceptions

- When 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.
- When 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.
- When 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.
- When 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.
- When 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.

## Effort and return

- Size M, about 3-5 weeks (Copilot Studio, Power Automate, ServiceNow API integration, Prompt and template design, Pilot testing with analysts)
- Team time on this task now: 25 h/week; expected back: 4-11 h/week

## 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