Prompts for IT Work

A pattern that works for most IT tasks

The prompts on this page look different, but they share one shape. Each gives the model four things it cannot know on its own, and asks for an answer that is easy to check:

1. The facts: the ticket text, the log lines, the notes. A model has no access to your ticketing system or monitoring unless a tool connects it. Microsoft's documentation, for example, says that Microsoft Copilot Chat with a work account uses the web for grounding, and sees your organization's content only when you paste or upload it, use Copilot in an app such as Outlook, or use an agent connected to that data (as of October 2026).
2. The task, as a verb with an object: "summarize for the next shift", "rank the likely causes", "draft a reply".
3. The audience and format: who reads it, how long it may be, which headings or fields.
4. What to do with gaps: "write unknown", "mark it [CHECK]", "say which parts you cannot read". Without this, the model fills gaps with plausible text, because producing plausible text is what it does.

The building blocks behind this are explained on anatomy of a good prompt and giving context and reference material. For tasks you repeat, turn the prompt into a template.

Tickets

Ticket summarization is using a language model to condense a ticket's history (the description, notes, emails and status changes) into a short summary for a specific reader, such as the next shift, an escalation team or a manager. It is one of the most useful IT prompts, because long ticket histories are slow to read and the facts are all in the text. It is also easy to get subtly wrong: a summary can be fluent and still drop the one note that mattered.

Amara Okafor escalates a ticket to the network team and wants them to understand it without reading 23 notes:

Summarize this ticket.

[ticket history]

Below is the full history of ticket INC-40433. I am escalating it to the network team, who have not seen it.

Write an escalation summary with these headings:
- Problem: one sentence, in the user's terms
- Affected: who and how many, as stated in the notes
- Timeline: the five most important events, each with its time
- Already tried: each action and its result
- Open questions: what the notes do not answer

Use only facts from the history. If two notes contradict each other, mention both. Do not suggest causes or fixes.

<ticket_history>
[the ticket history, with customer names and contact details removed]
</ticket_history>

The specific version names the reader, so the model knows what to leave out; it gives fixed headings, so the network team finds the same things in the same place on every escalation; and it forbids guessing at causes, which is the network team's job. "Mention both" for contradictions matters more than it looks: a model tends to smooth contradictions away, and a contradiction in the notes is often the clue.

Classifying tickets (category, priority, assignment group) is a related task where examples help most; see zero-shot, one-shot and few-shot prompting, and for how service desks build this into their tooling, AI-assisted triage. Writing good ticket notes in the first place is covered in writing tickets and technical documentation.

Before you use the summary:

• Check every time, number and name against the ticket. Models mix up who did what when several people appear in a thread.
• Look at the last two or three notes yourself. The newest information (the user's latest reply, a workaround that stopped working) is what a summary most often understates.
• Make sure nothing in "Already tried" was invented. A plausible step such as "cleared the browser cache" is easy to add and hard to notice.

Log analysis

Language models are good at reading a few hundred log lines and proposing what happened, and poor at reading a whole day's log. The useful input is a log excerpt: a deliberately selected part of a log, usually the lines from shortly before to shortly after the problem, from the relevant systems, with sensitive values removed, given to a model together with the system's name, version and time zone. Choosing the excerpt is your job, and it is the part that decides whether the answer is any good. How AI tools cluster and summarize logs at scale is on AI in IT operations; how to read logs yourself is on reading errors, logs and documentation.

What's wrong? [500 lines of firewall log]

Context: fw-edge-02 is a firewall at Kestrel Energy (firmware 7.4). It has a site-to-site VPN tunnel to a supplier at HOST-1. The tunnel dropped at 02:14 UTC and came back by itself at 02:31. Nothing was changed on our side that night. Addresses are replaced by placeholders.

<log>
[log lines 02:05 to 02:35 UTC from fw-edge-02]
</log>

Task: give the three most likely explanations for the drop, most likely first. For each one:
1. quote the log lines that support it, exactly as they appear
2. say what evidence would rule it out
If the log does not contain enough information, say what other log or command output would help.

Why each part is there:

• Context first, question last. The system, the version, the time zone and "nothing was changed" are facts the model cannot see in the log. Putting the long material before the question follows the placement advice of several vendors (see giving context).
• Ranked hypotheses instead of "the answer". A log rarely proves one cause. Asking for several, each with what would rule it out, gives you a short troubleshooting plan instead of a confident guess.
• Exact quotes. Quotes tie each claim to a line you can find with a search. A claim without a quote is a claim you cannot check quickly.

Before you act on the analysis:

• Search for each quoted line in the original log. Models sometimes "quote" a line that is not there, or merge two lines into one.
• Check time zones and the order of events. "A happened, then B failed" is only evidence if A really came first.
• Remember that lines appearing together are not proof that one caused the other.
• Do not run suggested commands on production because the analysis sounded right. Read them, and test anything that changes state (see working safely on production systems).

Replacing addresses with placeholders

Deleting every IP address from a log makes it useless for analysis: the model can no longer see that the peer in line 1 and the peer in line 4 are the same machine. Replacing each distinct address with its own stable placeholder (HOST-1, HOST-2) keeps those relationships while hiding the values, a simple form of pseudonymization. The script keeps the ticket numbers, because the model needs them, and checks that a candidate really is an IPv4 address, so a four-part version number such as 7.4.12.300, which looks like an address, stays as it is. The table at the end stays on your machine, so you can translate the model's answer back.

import ipaddress
import re

log = """\
02:13:50 INC-40455 fw-edge-02 firmware 7.4.12.300 loaded
02:13:58 INC-40455 fw-edge-02 IKE SA to 203.0.113.10 rekey started
02:14:02 INC-40455 fw-edge-02 no reply from 203.0.113.10, retry 1
02:14:07 INC-40455 fw-edge-02 DPD timeout for peer 203.0.113.10
02:14:07 INC-40455 fw-edge-02 tunnel to 203.0.113.10 down; 198.51.100.23 unreachable
02:14:31 admin j.devries@example.com logged in from 192.0.2.41"""

CANDIDATE = re.compile(r"\b\d{1,3}(?:\.\d{1,3}){3}\b")
EMAIL = re.compile(r"[\w.+-]+@[\w-]+(?:\.[\w-]+)+")

placeholders = {}


def stable_name(value, prefix):
    if value not in placeholders:
        count = sum(1 for name in placeholders.values() if name.startswith(prefix))
        placeholders[value] = f"{prefix}-{count + 1}"
    return placeholders[value]


def replace_ip(match):
    text = match.group()
    try:
        ipaddress.IPv4Address(text)
    except ValueError:
        return text  # looks like an address but is not one, e.g. a version number
    return stable_name(text, "HOST")


masked = EMAIL.sub(lambda m: stable_name(m.group(), "USER"), log)
masked = CANDIDATE.sub(replace_ip, masked)
print(masked)
print()
for original, name in sorted(placeholders.items(), key=lambda item: item[1]):
    print(f"{name:<7} = {original}")

02:13:50 INC-40455 fw-edge-02 firmware 7.4.12.300 loaded
02:13:58 INC-40455 fw-edge-02 IKE SA to HOST-1 rekey started
02:14:02 INC-40455 fw-edge-02 no reply from HOST-1, retry 1
02:14:07 INC-40455 fw-edge-02 DPD timeout for peer HOST-1
02:14:07 INC-40455 fw-edge-02 tunnel to HOST-1 down; HOST-2 unreachable
02:14:31 admin USER-1 logged in from HOST-3

HOST-1  = 203.0.113.10
HOST-2  = 198.51.100.23
HOST-3  = 192.0.2.41
USER-1  = j.devries@example.com

Pseudonymized data is still personal data under the GDPR, because you can reverse it with the table. The script reduces what leaves your machine; it does not make an unapproved tool acceptable. Hostnames such as fw-edge-02 stay visible here; decide per log whether they reveal too much. Like every pattern-based filter, this one misses formats it does not know, such as IPv6 addresses or names in free text, so read the result before you paste it.

When the excerpt is still too long

Sometimes the relevant period really is thousands of lines. Even if it fits in the model's context window, answers tend to get worse as the input grows, and details in the middle of a long input are more easily overlooked (see how a model reads your prompt). Two better options: filter first (only the error and warning lines, or only one component), or split the log into parts, ask the same question about each part, and then combine the partial answers in a final prompt. A small overlap between parts keeps an event that falls on a boundary visible in both:

log_lines = [f"02:{minute:02d}:10 fw-edge-02 message {minute + 1}" for minute in range(30)]


def chunks(lines, size, overlap):
    """Yield (first, last, lines) with line numbers counted from 1."""
    step = size - overlap
    start = 0
    while True:
        part = lines[start:start + size]
        yield start + 1, start + len(part), part
        if start + size >= len(lines):
            break
        start += step


parts = list(chunks(log_lines, size=12, overlap=2))
for number, (first, last, part) in enumerate(parts, start=1):
    print(f"Part {number} of {len(parts)}: log lines {first}-{last} "
          f"({part[0][:8]} to {part[-1][:8]})")

Part 1 of 3: log lines 1-12 (02:00:10 to 02:11:10)
Part 2 of 3: log lines 11-22 (02:10:10 to 02:21:10)
Part 3 of 3: log lines 21-30 (02:20:10 to 02:29:10)

Telling the model "this is part 2 of 3, log lines 11 to 22" helps it avoid treating the start of a part as the start of the incident. Splitting work into steps like this, and checking each step, is the subject of prompt chaining.

Runbooks

A runbook is where a wrong detail does real damage, because people follow it at night, under pressure, without questioning it. AI assistants are good at turning rough notes into a clear structure, and bad at knowing the exact commands for your devices. So let the model structure and word your knowledge, and forbid it to add its own.

Emeka Obi, the new network engineer, has Tomasz Nowak's notes from the last time the supplier tunnel dropped:

Turn the notes below into a runbook draft for NOC engineers: "Supplier VPN tunnel down on fw-edge-02".

Use these sections: Purpose; When to use this runbook; Access needed; Steps; How to verify it worked; Back-out; When to escalate and to whom.
In Steps, give each step a number, the exact command from the notes, and the expected result.

Use only commands and values that appear in the notes. Where the notes leave something out (a command, an expected result, a contact), write [CHECK: what is missing] instead of filling it in.

<notes>
tunnel to supplier down again. checked status first: show vpn status peer HOST-1 -> phase 1 down.
ping HOST-1 from fw-edge-02 ok, so path fine.
cleared SA: clear vpn sa peer HOST-1, came back after ~1 min.
if not back after 5 min call supplier NOC (number in the contacts list).
</notes>

The [CHECK: …] markers turn the model's gaps into a to-do list for the author instead of hiding them. The notes say nothing about access rights, a back-out step or who to escalate to internally; a good draft will show four or five markers.

Before the runbook is published:

• Compare every command, character by character, with the notes and the vendor's documentation. An invented option that "sounds right" is the most common and most dangerous error in generated runbooks.
• Walk through the runbook on a test device or in a lab, as someone who has never done the task.
• Have a second engineer review it, as you would any change to operational documentation (the four-eyes principle), and check that every step that changes something has a back-out plan.

Documentation and knowledge articles

Turning a resolved ticket into a knowledge article is a good fit for an AI assistant: the facts are in the resolution note, and the work is restructuring and rewriting for a different reader.

Write a knowledge article draft for Kestrel Energy service desk agents, based on the resolution note of INC-40417 below.

Audience: first-line agents who talk to customers by phone; they do not have admin rights.
Sections: Symptom (in the customer's words); Cause (one or two sentences, plain language); Steps for the agent (numbered); When to escalate.
Keep the steps the agent can do separate from the steps that need the portal team.
Use only what the note says; mark anything you had to assume with [ASSUMED].

<resolution_note>
[resolution note, without customer details]
</resolution_note>

The same pattern works for explaining unfamiliar material: paste a configuration excerpt or a section of vendor documentation and ask "Explain each line for a new engineer; say which lines you are unsure about". It works for rewriting too, for example the same article in plain language for customers (see plain language). Which kind of document you are writing, and how to keep it current, is covered in kinds of documentation.

Before you publish:

• Follow the steps yourself, in the current version of the system. Menu names and paths change between versions, and the model may describe a version it saw in training rather than yours.
• Remove internal details (hostnames, internal ticket links, names of colleagues) from anything customers can read.
• Resolve every [ASSUMED] marker, or delete the sentence.

Status updates and customer replies

Messages to people during an incident are where invented details cost the most trust. A model asked to "write a status update" produces something that looks like a status update, and status updates usually contain a cause and an expected fix time, so it supplies them, whether you know them or not.

Status updates

Sanne de Vries, the incident manager, needs the third internal update for a major incident. The format follows Kestrel's standard from what goes in an update:

Write an internal status update for INC-40500 (major incident), update 3, 10:45.

Facts:
- Impact: login to the customer portal fails for about 30% of users since 10:12. Meter readings and the app work normally.
- Workaround: none yet.
- Now: the portal team suspects an expired certificate on one load balancer node and is checking it. This is not confirmed.
- Next update: 11:15.

Format: the lines Status, Impact, Workaround, Now, Next update. At most 80 words.
Use only these facts. Keep "suspected" as suspected; do not give a fix time.

Write a status update about the outage of the Kestrel Energy customer portal.

Write a 60-word internal status update for INC-40500 (major incident) at Kestrel Energy, a fictional energy supplier.
Facts: impact — customer portal login fails for about 30% of users since 10:12; cause — under investigation, a certificate on the load balancer is suspected; next update 11:15.
Format: three lines, Impact / Cause / Next update.
No speculation beyond these facts.

Before you send an update:

• Compare every number, time and ticket ID with the incident record.
• Look for certainty that was not in your facts: "caused by" where you wrote "suspected", "will be fixed by" where you gave no time.
• Check that the next update time is there and is one you can keep.

Customer replies

A customer reply draft is a first version of a message to a customer or user, written by an AI assistant from facts and rules you supply, which a person then checks, completes and sends under their own name. The drafting saves time on wording and tone; the checking is not optional, because the customer will hold the organization to every word.

Draft a reply to a customer email for the Kestrel Energy service desk.

What the customer wrote: they submitted a meter reading in the portal this morning, got no confirmation, and want to know if it was saved.
Facts: readings submitted between 08:10 and 09:05 today were not saved because of a portal fault (INC-40217), which is fixed. The customer's reading is not in our system.
What we can offer: resubmitting the reading in the portal or by phone; the deadline for this month's readings is extended to Friday.

Tone: friendly and direct, no technical terms. At most 100 words. One short apology.
Offer only what is listed under "What we can offer". Leave [NAME] as a placeholder for the greeting.

The customer's name and account number are not in the prompt: the model does not need them to write the reply, so you add them later. That keeps personal data out of the tool, which matters most when you use a general chat assistant rather than one built into your ticketing system and approved for customer data. Listing what you can offer, instead of only forbidding promises, gives the model a positive rule to follow (see clear and specific instructions).

Before you send a reply:

• Read it as the customer: does it answer their question in the first two sentences?
• Check for promises you cannot keep: compensation, deadlines, "this will not happen again".
• Check facts and names once more, and follow your organization's policy on telling customers that a reply was drafted with AI (see disclosure).

Screenshots

Many assistants accept images, because the models behind them are multimodal. Screenshot analysis is giving a model a picture of a screen (an error dialog, a monitoring graph, a configuration page) and asking it to read, describe or interpret what it shows. Reading images has improved quickly: Anthropic, for example, says its Claude Opus 5.5 reads dense charts and screenshots much more precisely than earlier models (as of October 2026). But a model can still misread a character, guess at text that is too small, or describe what such screens usually show instead of what this one shows.

[screenshot] What's wrong?

[screenshot]
This is a screenshot of an error dialog in our internal portal admin tool, taken at 14:32 when saving a tariff change.

1. First, transcribe all text in the dialog exactly, including codes and numbers.
2. Then say which parts you cannot read clearly.
3. Then explain what the message most likely means. If the error code is specific to our software, say so rather than guessing its meaning.

Transcribing first separates seeing from interpreting. You can check the transcription against the image in seconds, and if it is wrong, the explanation built on it is worthless anyway.

• If you can copy the text, paste the text. An error message pasted as text is cheaper (images use many tokens), exact, and searchable. Use a screenshot for what has no text: a graph, a layout, a dialog that cannot be copied.
• Crop and redact before uploading. A full-screen screenshot shows much more than the error: other browser tabs, chat pop-ups, customer names in a list behind the dialog, IP addresses, the ticket queue. Cut it down to what the question needs and black out the rest.
• Check the transcription character by character, especially codes and numbers where 0 and O, 1, l and I, or 5 and S are easy to confuse.
• Do not trust values read off a graph beyond what you can read yourself. Ask for the shape ("when did the error rate rise?") rather than precise numbers, and check them in the monitoring tool.

Kestrel Portal Admin
Error KPA-0815: tariff record locked (node cache-02, 192.0.2.17)
Retry in 300 s or contact the portal team.

What's wrong here?

This is a screenshot of an error message from a fictional internal admin tool. First transcribe all text exactly, including codes and numbers. Then say which parts you cannot read clearly. Then explain what the message most likely means; if the error code is specific to this software, say that you cannot know its exact meaning.

Before you use the answer

Each task has its own typical failure. Knowing it tells you where to look first:

Asking the model for quotes, markers and "unknown" makes these checks fast, but it does not replace them. Models can mark the wrong things as certain, and a well-structured answer is easier to over-trust. The general habits for checking output are on using AI at work, and the techniques that reduce invented details in the first place on reducing hallucinations.