A practical prompt framework for IT support teams

Watch two engineers use the same AI assistant on the same ticket and you'll see the whole problem of AI adoption in one sitting.

The first types "write a reply to this customer" and pastes the ticket. She gets something generic, edits half of it, and concludes the tool is overrated. The second spends forty seconds setting up the request and gets a reply he sends with two small edits. Same tool, same model, same ticket.

The difference is structure. And structure can be taught, which is the part most teams skip. They roll out the tool, maybe run a lunch-and-learn, and then leave prompt quality to individual talent. That's how you end up with one enthusiast, three sceptics, and no consistency.

The five parts of a working prompt

Every reliable operational prompt we've seen does five things. Not always in this order, but always all five.

Role. Tell the model who it's being. "You are a senior service desk engineer at an MSP" produces measurably different output than nothing at all. It sets vocabulary, seriousness, and the kinds of mistakes the model avoids.

Context. What's true about this situation that the model can't know? The customer is non-technical. This is the third ticket about this issue. The system involved is business critical on Mondays. Two sentences of context routinely does more for quality than any other change.

Task. One task, stated plainly. "Summarise this ticket for escalation to tier 2" beats "help me with this ticket." When you catch yourself writing "and also" in the task line, you're usually asking for two prompts' worth of work and you'll get half quality on both.

Constraints. The rules the output has to obey. Maximum length. No promises about timelines. Never mention internal system names to customers. British spelling. Constraints are where company policy lives inside a prompt, and they're the part engineers forget most.

Format. What the answer should physically look like. Bullet points for a handover. A short paragraph for a customer. A table for comparing options. If you don't specify format you get the model's default, which is usually longer than anyone wants.

That's the whole framework. Role, context, task, constraints, format. It fits on a sticky note, and honestly, on a lot of desks it should live on one.

Before and after

Here's the difference on a real ticket type, the kind everyone recognises. A user reports their laptop is "slow again."

The lazy prompt: "Write troubleshooting steps for a slow laptop."

You'll get a generic list starting with "restart your computer" that reads like the first page of a search result. Technically correct, useless in practice, and your engineer now trusts the tool a little less.

The framework prompt: "You are an experienced desktop support engineer. A finance user on a managed Windows 11 laptop reports slowness that started this week, mainly in Excel with large files. Earlier tickets show no hardware issues. Write five troubleshooting steps in order of likelihood for this specific case, one line each, no generic advice like restarting, and end with what to collect before escalating."

Same model. A completely different tool.

Making it stick as a team

A framework only becomes a standard when people stop having to remember it, so the goal isn't training everyone to write prompts from scratch. It's building a small shared set of pre-structured prompts for your recurring work: triage, first response, escalation summary, closure notes, KB drafts. An engineer opens one, fills in the ticket specifics, done. Consistency stops depending on who's on shift.

That's the approach behind the prompt library in Opstimio: several hundred prompts for IT operations that already have the role, constraints, and format baked in, organised by the work they belong to. Whether you use ours or build your own set, the principle is the same. Prompts are operational assets, and they belong in a shared library with an owner, not in personal notes.

Where to start on Monday

Pick your single most repeated written task. For most service desks that's the first response on common ticket types. Write one framework prompt for it, test it on five real tickets, tighten the constraints where the output annoyed you, and share it with the team as the standard way to do that task.

One good shared prompt, adopted, beats a training session about prompting theory every single time. Then do the next one.