Better prompts at work: context, examples and a way to check.
A good prompt is a good brief: context, the goal, an example of what good looks like, the format you need and how the answer will be checked. There are no magic words, and the best prompts become shared templates.
veridive5 min read
“Summarize this thread.” The answer comes back in seconds: a tidy paragraph saying that the supplier and the buyer discussed a late delivery. It leaves out the two things you needed before the call, the new date the supplier committed to and the penalty they asked you to waive.
The tool did what it was asked. The prompt was a vague brief, and a vague brief gets the average answer. Good prompts at work are good briefs: context, the goal, an example of what good looks like, the format you need and how the answer will be checked. There are no magic words, and the prompts that work best end up as templates the whole team shares.
Why do vague prompts get vague answers?
Because the tool fills every gap with the most likely default. It doesn’t know who you are, what the summary is for, which details matter in your business or what “short” means to you. A colleague would ask. The tool usually guesses, and its guess is the average case.
That is also why magic phrases disappoint. Telling a tool to act as a world expert adds little; telling it the facts of your situation adds a lot.
What goes into a good brief for an AI tool?
Five parts, the same ones you would give a capable new colleague:
- Context: who you are, who the output is for, and the material to use.
- Goal: what the output is for, and the decision it supports.
- Example: what a good result looks like.
- Format: length, structure, language and tone.
- Check: how you will verify the answer.
Here is an illustrative example, a buyer preparing for a supplier call.
Before: “Summarize this email thread.”
After:
- Context: I’m a buyer at a furniture manufacturer. Below is a thread with our hinge supplier about a late delivery, partly in Turkish and partly in English.
- Goal: I have a call with them and need to know what they committed to and what they want from us.
- Example: Here is a summary from another thread that worked well: [pasted example].
- Format: English, at most eight bullet points, then a list of open questions. Copy dates and quantities exactly as written.
- Check: After each point, quote the sentence and the email it comes from. List any assumptions, and flag anything unclear or contradictory.
The second answer leads with the new delivery date and the penalty request, each with its source, and flags that two emails give different quantities. It took two minutes longer to write and saved the call.
Two habits help after the brief. Give one task per prompt: the summary first, then the reply draft, rather than both at once. And when an answer misses, say what was wrong, as you would to a colleague, instead of starting again from a blank prompt.
How do examples improve results?
One good example communicates length, tone, structure and level of detail at once, which is hard to do in a description. Use real past outputs you were happy with, with personal details masked where the data rules require it.
The risk is copying. With a single example, a tool may borrow its specifics, a name or a figure, along with its shape. Use two or three examples from different cases, say which parts are the pattern, and check that nothing from an example leaked into the answer.
How do you ask for an answer you can check?
Build the check into the request:
- Sources: ask it to quote the passage behind each claim and say where it came from.
- Assumptions: ask it to list what it assumed, such as a currency or a date format.
- Uncertainty: ask it to say what it couldn’t find or isn’t sure about, and allow “not in the text” as an answer.
Ask for an answer you can check, not one you have to trust.
Numbers deserve their own rule: ask the tool to copy figures from the source rather than calculate them, and do the arithmetic in a spreadsheet.
When should a prompt become a shared template?
When a task repeats, when several people do it, or when colleagues keep asking for your prompt. A team prompt library needs five fields per entry:
| Field | What it holds |
|---|---|
| Owner | The person who keeps the entry current |
| Use case | The task, and when not to use the template |
| Template | The brief, with blanks to fill |
| Example output | A result the team was happy with |
| Last review | When it was last checked against the current tool and policy |
Champions make natural curators: in a champions program such as the illustrative finance AI champions engagement, collecting good examples is already part of the role. When a template starts feeding a system rather than a person, it becomes code, with versions and tests of its own.
What should you never paste into a prompt?
Whatever your acceptable use policy excludes, and no work data at all in a personal account. The usual exclusions are personal data about customers and colleagues, contracts and confidential terms, passwords and access keys, and unpublished financial results, unless the approved tool is cleared for them. Anonymize the examples in shared templates, and never store a secret in one. The note on AI literacy covers the rest.
Rewrite one weekly prompt
Pick one task you do every week, write the five-part brief for it and compare the result with your usual prompt. If it is better, it is the first entry in your team’s library. Practice on real tasks, in Turkish and English, is part of the role-based training in our AI enablement work.
Ask an assistant about this note